From owner-freebsd-current@freebsd.org Sun Jun 24 01:41: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 22FAD100EA78 for ; Sun, 24 Jun 2018 01:41:05 +0000 (UTC) (envelope-from mqudsi@neosmart.net) Received: from mail-oi0-x242.google.com (mail-oi0-x242.google.com [IPv6:2607:f8b0:4003:c06::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 BAD357201B for ; Sun, 24 Jun 2018 01:41:04 +0000 (UTC) (envelope-from mqudsi@neosmart.net) Received: by mail-oi0-x242.google.com with SMTP id l22-v6so9415355oib.4 for ; Sat, 23 Jun 2018 18:41:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neosmart.net; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3jSLZ+rjNr7GQyiBYBJjzSwAmQ8+zvXx93wcFaK6bmM=; b=sdaa1XBArJxFu495X3LAv1YDdPlyz3IEnDlN21+4GhfMcY5G76KCYWqzGvvYrl3vQ3 gSXZddWjbQLu9jbr2zZisCsTD/r+QtyshjOvy+O/H3l2w3F+4edGzpb6ber0iIORxtIh 7Pdo/bzvP1D9i5HMT6H6rjJb4pZPHL0Zo1rhc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3jSLZ+rjNr7GQyiBYBJjzSwAmQ8+zvXx93wcFaK6bmM=; b=Q4fsW3QLWhONN3NdUmsvp+4ZGa+Hztl6R3r3JlseD0u+vwOvN9MhHFtrGSqzHkBvDj CLCIP7eEEkRFpwlfXfT7vcXCCHflBN+wt2ln8ojDkDUwbYo3kI3s3Wm6Tr1XWRCpxfOQ V04VEWerD3Zlzn81Vqg/l+Fy9ivEWC0D1lelX+RA/1TQ8hnnwe8vUqb4b1ir93Tdl4mu OlAiZwJQ8Ae7A4hD0ZCfw71VJtufK98yfjiWWp11pMI9aKJeUDlKhw9vFvzrgnufjOR0 Wdoakg33rTCcEr/BcTIBbPG4p+UFOJy55b2UjUGLpKlTLjyAb6kcMz8sd9H8NtApTw8A TbeA== X-Gm-Message-State: APt69E0F9pGEae5kM+oMCJfI7J+KNkLkaa+cs1h9z//v+ocaTX+dq+4u kK907BtZHrg9pEGq52EHbbtCVBEn6mY6m9pi852PTn6l X-Google-Smtp-Source: ADUXVKLngQzuJIZIFRweYTBoLut8jGBgPps1arUYdpZnQl6BFUs3xOHaeqPM3HmqNcKSNorqaRkOiave/3KlKYRCXmY= X-Received: by 2002:aca:dd83:: with SMTP id u125-v6mr4153738oig.39.1529804463926; Sat, 23 Jun 2018 18:41:03 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:e8f:0:0:0:0:0 with HTTP; Sat, 23 Jun 2018 18:40:43 -0700 (PDT) In-Reply-To: <1ded7c55df9a77fd690959b375435b12@udns.ultimatedns.net> References: <1ded7c55df9a77fd690959b375435b12@udns.ultimatedns.net> From: Mahmoud Al-Qudsi Date: Sat, 23 Jun 2018 20:40:43 -0500 Message-ID: Subject: Re: Lack of /dev/vtvga0? To: bsd-lists@bsdforge.com Cc: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 24 Jun 2018 01:41:05 -0000 On Sat, Jun 23, 2018 at 12:11 AM, Chris H wrote: > I'm not clear if you're already possibly referring to this. But have > you tried sc(4) ( SysCons ). If you haven't tried already; > adding the following to your loader.conf(5) should give it to you: > > kern.vty=sc > > You can also include it in your custom kernel by adding this to your > KERNCONF > > device sc > options SC_PIXEL_MODE # adds support for the raster text mode > > Hope this helps. Hi Chris, thanks for responding. Yup, I'm aware of using kern.vty to fall back to syscons, and SC_PIXEL_MODE to get framebuffer support via /dev/tty* devices. I actually have a port of the xf86-video-wsfb driver for scfb [0]. My question is actually specifically in regards to newcons/vt. By checking `dmesg` I can see that the libvt driver device vtvga0 is instantiated, but it's not mapped to any file in /dev/ which means I can't send it an IOCTL as I normally would. Or perhaps the problem is that with vt_vga loaded, IOCTLs to /dev/tty* devices only respond to CONSIO IOCTLs and not libvt or FBIO IOCTLs, which is how they would respond with SC_PIXEL_MODE and kern.vty=sc. Note that this is with hw.vga.textmode=0, which afaict per vt(4) is not the default, but at the same time does not seem to actually change anything. I believe the entire point of libvt was to abstract away the KMS drivers from the API framebuffer API and allow for dynamic switching of the backend driver without needing to switch to a different graphics provider or change the graphics library/framework/environment configuration, and indeed when loading the binary blobs for the test GPUs I have in the system, a /dev/fb0 magically appears, but there is no framebuffer device for the basic in-kernel VGA driver that is used until a more appropriate KMS driver has been loaded (if ever). [0]: https://github.com/neosmart/xf86-video-scfb/ Thanks, Mahmoud Al-Qudsi NeoSmart Technologies From owner-freebsd-current@freebsd.org Sun Jun 24 07:57:52 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 0565B101D60F for ; Sun, 24 Jun 2018 07:57:52 +0000 (UTC) (envelope-from gljennjohn@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 869A57DFCB for ; Sun, 24 Jun 2018 07:57:51 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 457C9101D60C; Sun, 24 Jun 2018 07:57:51 +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 084E8101D60B for ; Sun, 24 Jun 2018 07:57:51 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::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 70B1D7DFC8; Sun, 24 Jun 2018 07:57:50 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wr0-x233.google.com with SMTP id c13-v6so548266wrq.2; Sun, 24 Jun 2018 00:57:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=tUGHjDHpJVccJ4Qx/F9nJNZ3ILRoT2jgYwKrwAb9iRA=; b=rEOqbBW7xryOiGHN1nQUT6tgnIam2jIz9sscnwwONoA+aya58kyMywspp8rPxqg8if ERJjY4p/0r273FQ6/3h6VuzRcxebniAnwcXGAFlVcKNBOF3wR61IcVWSUfrnelSky7/+ C0qAJO/pvcsPLlrrrAuc11xrg1YNBm69+p5ts8l38dwU3d6c8wj3ZQkkccRQ5UsmdlRl 6tpeADooWXd05oGDC2iJTPYH60BlsZ0+Xu/cWslFdbJh20BAP4IP3CMHnGuJOgYHIxnw hOXrOPQc9F4Em4CPGpdujCBIXZd7540lWlIRy837+Zx3sJUroJJ2IsL6aum/Id6uwoM8 F8xQ== 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:reply-to:mime-version:content-transfer-encoding; bh=tUGHjDHpJVccJ4Qx/F9nJNZ3ILRoT2jgYwKrwAb9iRA=; b=ehlCa0OeEBx5XI+BKv3xk7WSJPPcvIV+BV4RPpvEibRta92gSdlRK8x/lrQMg4n2Vr mrws6lRNGOe6xsUUBaOBqt3kxbVM8eBooP6py27QFwMDE85GZ3H+jv7I68urG57JY+LK /Ci9hXVtYlRbMC9N2FQmMbAEIiYreZC34Ur9lLsHuxqP44NwGiYfy2myX6DRIs6uLgrB 7a5x6rCYgDnGWqNIww2c+SFUscC2c3AdJDJwxMcEdVMykPLT6BXEv+t6FIQDa5u8Hfzp hUJ3on6FiDf0Aajfj6zSTmWsoWunKhksx01bZSb00RcqwncM23GzD1eKQjVYV936IszQ NM3g== X-Gm-Message-State: APt69E3SZeQvFI9DXTM6lwv4yRgeYQQcZtTV/p9ZfG4qULB0La13m5lJ dB+xf1976jKyiphA8d4BfWuVSg== X-Google-Smtp-Source: AAOMgpe6t+JhTFZiB87m3lsbnyqIlrdrqw2hxznc6xRi8ewqi9n38Ow1Rn2CCPvf9SHYbmDDIxw5Tg== X-Received: by 2002:adf:8227:: with SMTP id 36-v6mr3318618wrb.144.1529827069318; Sun, 24 Jun 2018 00:57:49 -0700 (PDT) Received: from ernst.home (p5B02381D.dip0.t-ipconnect.de. [91.2.56.29]) by smtp.gmail.com with ESMTPSA id s191-v6sm11155061wmd.27.2018.06.24.00.57.48 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 24 Jun 2018 00:57:48 -0700 (PDT) Date: Sun, 24 Jun 2018 09:57:47 +0200 From: Gary Jennejohn To: Dimitry Andric Cc: current@freebsd.org Subject: Re: error building clang in HEAD Message-ID: <20180624095747.7384f5bf@ernst.home> In-Reply-To: <196E84B3-B58F-4296-B6EA-84D0DE3230EF@FreeBSD.org> References: <20180623154048.1b228df0@ernst.home> <196E84B3-B58F-4296-B6EA-84D0DE3230EF@FreeBSD.org> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.16.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.26 Precedence: 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, 24 Jun 2018 07:57:52 -0000 On Sat, 23 Jun 2018 17:05:16 +0200 Dimitry Andric wrote: > On 23 Jun 2018, at 15:40, Gary Jennejohn wrote: > > > > There is a strange error building clang with this use case: > > > > cd /usr/src > > make -j10 makeworld > > What's the "makeworld" target? I've not heard of this. > A typo. I meant buildowrld. > > which produces this error output: > > > > ===> lib/clang/libclang (all) > > error: unable to rename temporary 'Sema/SemaTemplate-12ad7e30.o.tmp' to output file 'Sema/SemaTemplate.o': 'No such file or directory' > > 1 error generated. > > --- Sema/SemaTemplate.o --- > > *** [Sema/SemaTemplate.o] Error code 1 > > This typically happens if "make obj" was not run before the rest of the > make targets. Normally, the order is: make obj, then make depend, then > make (a.k.a. make all). > > Is there a directory /usr/obj/usr/src/lib/libclang/Sema ? > Well, I would hope/expect that make buildworld does make obj. Yes, the directory was there. -- Gary Jennejohn From owner-freebsd-current@freebsd.org Sun Jun 24 08:42: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 39AA4101F2C7 for ; Sun, 24 Jun 2018 08:42:26 +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 A3D507FC25; Sun, 24 Jun 2018 08:42:25 +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 ESMTP id w5O8gEmH026894; Sun, 24 Jun 2018 11:42:17 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w5O8gEmH026894 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w5O8gEX1026893; Sun, 24 Jun 2018 11:42:14 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 24 Jun 2018 11:42:14 +0300 From: Konstantin Belousov To: Matthew Macy Cc: Adrian Chadd , John Baldwin , "br@freebsd.org" , freebsd-current , marius@freebsd.org Subject: Re: atomic_testandclear_, atomic_testandset_ Message-ID: <20180624084214.GW2430@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.0 (2018-05-17) 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.26 Precedence: 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, 24 Jun 2018 08:42:26 -0000 On Sat, Jun 23, 2018 at 01:38:07PM -0700, Matthew Macy wrote: > It turns out ck already has equivalent primitives. Pardon the noise. Why not to add trivial cmpset-based implementations to the lacking arches ? If maintainers prefer proper ll/cs assembly, they would have the time to do it properly without ultimatum. It is useful to utilize consistent atomic(9) KPI across kernel. > > -M > > On Sat, Jun 23, 2018 at 12:18 Matthew Macy wrote: > > > The functions in the subject are both documented in atomic(9) and are > > implemented by every arch except sparc64 and MIPS. I have some code in > > review that uses them that I intend to commit once the various design > > issues are addressed. Please implement them so that those targets can > > remain part of universe. > > > > Thanks in advance. > > -M > > > _______________________________________________ > 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 Sun Jun 24 09:33:42 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 AFC7D1020CAC for ; Sun, 24 Jun 2018 09:33:42 +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 07EAC816F0; Sun, 24 Jun 2018 09:33:41 +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 ESMTP id w5O9XVWK038149; Sun, 24 Jun 2018 12:33:34 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w5O9XVWK038149 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w5O9XUtg038148; Sun, 24 Jun 2018 12:33:30 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 24 Jun 2018 12:33:30 +0300 From: Konstantin Belousov To: Rick Macklem Cc: "freebsd-current@freebsd.org" , Alexander Motin Subject: Re: nfsd kernel threads won't die via SIGKILL Message-ID: <20180624093330.GX2430@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.0 (2018-05-17) 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.26 Precedence: 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, 24 Jun 2018 09:33:42 -0000 On Sat, Jun 23, 2018 at 09:03:02PM +0000, Rick Macklem wrote: > During testing of the pNFS server I have been frequently killing/restarting the nfsd. > Once in a while, the "slave" nfsd process doesn't terminate and a "ps axHl" shows: > 0 48889 1 0 20 0 5884 812 svcexit D - 0:00.01 nfsd: server > 0 48889 1 0 40 0 5884 812 rpcsvc I - 0:00.00 nfsd: server > ... more of the same > 0 48889 1 0 40 0 5884 812 rpcsvc I - 0:00.00 nfsd: server > 0 48889 1 0 -8 0 5884 812 rpcsvc I - 1:51.78 nfsd: server > 0 48889 1 0 -8 0 5884 812 rpcsvc I - 2:27.75 nfsd: server > > You can see that the top thread (the one that was created with the process) is > stuck in "D" on "svcexit". > The rest of the threads are still servicing NFS RPCs. If you still have an NFS mount on > the server, the mount continues to work and the CPU time for the last two threads > slowly climbs, due to NFS RPC activity. A SIGKILL was posted for the process and > these threads (created by kthread_add) are here, but the > cv_wait_sig/cv_timedwait_sig never seems to return EINTR for these other threads. > > if (ismaster || (!ismaster && > 1207 grp->sg_threadcount > grp->sg_minthreads)) > 1208 error = cv_timedwait_sig(&st->st_cond, > 1209 &grp->sg_lock, 5 * hz); > 1210 else > 1211 error = cv_wait_sig(&st->st_cond, > 1212 &grp->sg_lock); > > The top thread (referred to in svc.c as "ismaster" did return from here with EINTR > and has now done an msleep() here, waiting for the other threads to terminate. > > /* Waiting for threads to stop. */ > 1387 for (g = 0; g < pool->sp_groupcount; g++) { > 1388 grp = &pool->sp_groups[g]; > 1389 mtx_lock(&grp->sg_lock); > 1390 while (grp->sg_threadcount > 0) > 1391 msleep(grp, &grp->sg_lock, 0, "svcexit", 0); > 1392 mtx_unlock(&grp->sg_lock); > 1393 } > > Although I can't be sure if this patch has fixed the problem because it happens > intermittently, I have not seen the problem since applying this patch: > --- rpc/svc.c.sav 2018-06-21 22:52:11.623955000 -0400 > +++ rpc/svc.c 2018-06-22 09:01:40.271803000 -0400 > @@ -1388,7 +1388,7 @@ svc_run(SVCPOOL *pool) > grp = &pool->sp_groups[g]; > mtx_lock(&grp->sg_lock); > while (grp->sg_threadcount > 0) > - msleep(grp, &grp->sg_lock, 0, "svcexit", 0); > + msleep(grp, &grp->sg_lock, 0, "svcexit", 1); > mtx_unlock(&grp->sg_lock); > } > } > > As you can see, all it does is add a timeout to the msleep(). > I am not familiar with the signal delivery code in sleepqeue, so it probably > isn't correct, but my theory is alonge the lines of... > > Since the msleep() doesn't have PCATCH, it does not set TDF_SINTR > and if that happens before the other threads return EINTR from cv_wait_sig(), > they no longer do so? > And I thought that waking up from the msleep() via timeouts would maybe allow > the other threads to return EINTR from cv_wait_sig()? > > Does this make sense? rick > ps: I'll post if I see the problem again with the patch applied. > pss: This is a single core i386 system, just in case that might affect this. No, the patch does not make sense. I think it was just coincidental that with the patch you did not get the hang. Signals are delivered to a thread, which should take the appropriate actions. For the kernel process like rpc pool, the signals are never delivered, they are queued in the randomly selected thread' signal queue and sit there. The interruptible sleeps are aborted in the context of that thread, but nothing else happens. So if you need to make svc pools properly killable, all threads must check at least for EINTR and instruct other threads to exit as well. Your description at the start of the message of the behaviour after SIGKILL, where other threads continued to serve RPCs, exactly matches above explanation. You need to add some global 'stop' flag, if it is not yet present, and recheck it after each RPC handled. Any thread which notes EINTR or does a direct check for the pending signal, should set the flag and wake up every other thread in the pool. From owner-freebsd-current@freebsd.org Sun Jun 24 10:03: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 DE9D710222A5 for ; Sun, 24 Jun 2018 10:03:48 +0000 (UTC) (envelope-from Alexander@leidinger.net) 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 72DE282A2C for ; Sun, 24 Jun 2018 10:03:48 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: by mailman.ysv.freebsd.org (Postfix) id 31B9F10222A4; Sun, 24 Jun 2018 10:03:48 +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 0CEBB10222A3 for ; Sun, 24 Jun 2018 10:03:48 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:375::1:5]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7360A82A2B for ; Sun, 24 Jun 2018 10:03:47 +0000 (UTC) (envelope-from Alexander@leidinger.net) Date: Sun, 24 Jun 2018 12:03:29 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1529834625; bh=J12K+ljpS13a2c3sc19LShDJma4CcW8zYiPZf0niG8k=; h=Date:From:To:Subject; b=df72j7WpasR9PXZ7m8uNTwq2hKw3El7idoixpcJbgrTv95inI1tzeTfhIwoRHBSOb tiG5sTq2CLbfaHn8+JxSJSSK/mu6xcVyfTXpaPrx/48wV8k8CYJdU1ttkr31TjMhCz j2oLDphXWhszwPD7vD0St45hSHwX15IhKQzm8PDemaVVbC9x9B5YRja9gWip2fMXM2 qgG7PBEpenlsn6ehtPieQ93rfIo5tyIynBIpE0uEX1vs4NBfWgUTrtEm45V+eIqRdz ZDuA32fOonrwb5ADFb4EcOP7N18gUiE1lyd67Wk8Jr6keWwvSWARxOeaDNNt8u9HZZ SDqEg9mJHY8jA== Message-ID: <20180624120329.Horde.HWORumQ7Ng1KAUeviJNtoc3@webmail.leidinger.net> From: Alexander Leidinger To: current@freebsd.org Subject: numa involved in instability and swap usage despite RAM free? User-Agent: Horde Application Framework 5 Content-Type: multipart/signed; boundary="=_-oBR2oHEOll7in8gWqzLcvA"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 24 Jun 2018 10:03:49 -0000 This message is in MIME format and has been PGP signed. --=_-oBR2oHEOll7in8gWqzLcvA Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I don't have hard evidence, but there is enough "smell" to open up a=20=20 discussion... Short: Can=20it be that enabling numa in the kernel is the reason why some=20=20 people=20see instability with zfs and usage of swap while a lot of free=20= =20 RAM=20is available? Long: I have a dual-socket Xeon system (E5620 + L5630... yes, not the same,=20=20 but=20compatible enough to be able to run together) with 64 GB RAM. I=20=20 run=20-current on it (currently it's at r333966 and it was for all the=20= =20 tests=20below). What I see with numa enabled and no zfs patches is, that at some point=20= =20 I=20have half the RAM free, swap is in use, and after a lot of compiling=20= =20 ports=20in different jails ZFS comes to a halt (sometimes I can unblock=20= =20 by=20killing a compile, sometimes I can't even kill, only way out is=20=20 power-cycle).=20I've seen this around twice a week. When I keep numa enabled and have applied this ZFS patch=20=20 https://reviews.freebsd.org/D7538=20the bahavior changes. AFter a while=20= =20 half=20of the RAM is free, swap is in use, and after enough compiling=20=20 ports=20in jails I get a panic (unfortunately not enough debug info in=20= =20 the=20textdump to know exactly what he problem is). Since 2 weeks I have numa compiled out of the kernel (and still the=20=20 ZFS=20patch inside). The system is down to 17 GB free and NO swap in=20=20 use.=20I'm compiling ports in 16 jails (one of them with parts of KDE5 =3D= =20=20 currently=20about 700 ports compiled) and not a single issue like the=20=20 above. For=20everyone with swap issues or ZFS issues similar to the ones I=20=20 see...=20do you have numa enabled and can you please try without and=20=20 report=20back? Can it be that if memory request can not be fulfilled from one numa=20=20 domain,=20there is no fallback to another numa domain for all the=20=20 various=20kinds of memory allocation we have in the kernel=20=20 (contigmem/no-sleep/...)? Bye, Alexander. --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_-oBR2oHEOll7in8gWqzLcvA Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJbL2xxAAoJEKrxQhqFIICEVcsP/jVTtyEtb92DPBitIacgUk1F 3xzRc+0SfWYqyU8PAHsIRkJQFdvQ7rvLqwNznqvkLdi3FvmT+6PKJcORhHrNBMEo KhJGByGFPAdpnAoA7ZVJY7r6RWJsNU61AvPdgn0ZORPX73cbuo5zeCfwpIiYPGEH oja29zNA7XLnh9AZ5NJMl3zmvCEUOOONkENoUE/tDi4YMVy1m8EVmtSFAsdtBYHU G9incSchNzRx3tkK8kojknLjZCFQn44yOKYhANKwgMSECR5sZuvAcQaSLUNUvdcr 6OpjCFcHWsTFIr5vJvEqml+rSSnvt89q5JZBsP9T8/6dXs1rUuBKKLkVWR2A/bT9 d7c5WX4xFlk6vRRfcZ6pQ6GQQOs06IaxxPvRXDAdJcFCMj1gKatKumg55+IXxbwQ ovxuHay+YfmQxi/DuO0HAeh5JNd1NL3u2Dpb9Xs+xey0yKQXorFTU4ADiqcWXp/v kAiz0Cyf3gnaYuRA6bRZdUdTThj/3NDKKWztcX6pe+VGepSBBRsskEcfIns6oNgG n+CnkUIp5sjos+kG0iXD7d+ZqVPiHsdiWdvLzOuJD1bjagDbMD23eoA+m3uYLcKn buf/DJoW8VthcvlKPsh9Lxh2ChfiT3C1MVS0BTGeN6tfOWsPpg9E5c0e1mouWV9+ nMgw+XE0WfA2UDrP0X8k =ckNr -----END PGP SIGNATURE----- --=_-oBR2oHEOll7in8gWqzLcvA-- From owner-freebsd-current@freebsd.org Sun Jun 24 17:50:44 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 F292A1006AE6 for ; Sun, 24 Jun 2018 17:50:43 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A35A270E76; Sun, 24 Jun 2018 17:50:43 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from mail-it0-f41.google.com (mail-it0-f41.google.com [209.85.214.41]) (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)) (Authenticated sender: mmacy) by smtp.freebsd.org (Postfix) with ESMTPSA id 6B24623CE9; Sun, 24 Jun 2018 17:50:43 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: by mail-it0-f41.google.com with SMTP id p185-v6so9193005itp.4; Sun, 24 Jun 2018 10:50:43 -0700 (PDT) X-Gm-Message-State: APt69E2V0s0cALPJUzPsJizpiXQQ0C79+0h/DpND5ubqUQ/zTcneMc6p LONuCyr6+0/j1y1YUjjmQzEvneu/9yrzBWJjqXc= X-Google-Smtp-Source: ADUXVKLe/gOBwCXdgg13KU4i2dBZ5hHPthdMmD3OA7as/62RSqGwaK/dx5WaglYqiabMbb5vjV8H7Pyl1JpWDHMrbOA= X-Received: by 2002:a02:4c9b:: with SMTP id q27-v6mr2329680jad.38.1529862642996; Sun, 24 Jun 2018 10:50:42 -0700 (PDT) MIME-Version: 1.0 References: <20180624084214.GW2430@kib.kiev.ua> In-Reply-To: <20180624084214.GW2430@kib.kiev.ua> From: Matthew Macy Date: Sun, 24 Jun 2018 10:50:32 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: atomic_testandclear_, atomic_testandset_ To: Konstantin Belousov Cc: Adrian Chadd , John Baldwin , "br@freebsd.org" , freebsd-current , marius@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 24 Jun 2018 17:50:44 -0000 On Sun, Jun 24, 2018 at 01:42 Konstantin Belousov wrote: > On Sat, Jun 23, 2018 at 01:38:07PM -0700, Matthew Macy wrote: > > It turns out ck already has equivalent primitives. Pardon the noise. > Why not to add trivial cmpset-based implementations to the lacking > arches ? If maintainers prefer proper ll/cs assembly, they would > have the time to do it properly without ultimatum. Good point. > > > It is useful to utilize consistent atomic(9) KPI across kernel. > Agreed > > > > > -M > > > > On Sat, Jun 23, 2018 at 12:18 Matthew Macy wrote: > > > > > The functions in the subject are both documented in atomic(9) and are > > > implemented by every arch except sparc64 and MIPS. I have some code in > > > review that uses them that I intend to commit once the various design > > > issues are addressed. Please implement them so that those targets can > > > remain part of universe. > > > > > > Thanks in advance. > > > -M > > > > > _______________________________________________ > > 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 Sun Jun 24 20:07:14 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 D6EAB100C7CB for ; Sun, 24 Jun 2018 20:07:13 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic302-4.consmr.mail.bf2.yahoo.com (sonic302-4.consmr.mail.bf2.yahoo.com [74.6.135.43]) (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 6A93475103 for ; Sun, 24 Jun 2018 20:07:13 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: G7mIGs0VM1lmUMpe_iB8gW4DbxHAPRsNd8uUEJOUUVSbPOAVwRffDFw3TnggecL 0ZypAZOgZo6FzbVpzNRKzZPYAn1IWwGuxDIEdo9_tgKIMdMzyVLZ1.SWdIDjRodk9uOXxy136EtH IN2El16qyAttF0RALEy2Q2LaNZjf28L2E6JjtjpSmDZxQzpqE1TkWqIbincYvMeeLgYIai.D5lgL tS0rE3g1eCKE6HcI0gLXGA2fYtAz21_U3snTvlZ.vt7Svv_1kqScaOtadI5nsqJZEf4J7xEz2ZeA L9KtYz2v.e8g9Ln3uedfrE7T.l_qApgXgrTzc8Dv4iEk.jxcCSVI8rXrj2tzHz6OZt9X6pb0hG18 KjQkw1QWpybu90PG5RQaf.61UKWfV6DYKbKkkqDsTUVd8c3Oz7hqbiCw_wOF3JnZkTM_PU4sb03c rNQyndiq9R8zBoceOWBTOL69O7y1j_GeMu4EYAzUzU1MR33KfErlFquCs.G.NqXRlGmtEcQXRjvR soIMCJmjz9ch4ScQ1rzskG_kHEpmhDhuToPlnN0U0U20Svq7kLGtZUZ1mGzo52vaD5zX6UKglRML fVN6lNJE1LsheBDF4BgoPitvkEnaAdyY641dF1IPV3McL4cmFKh3Pmwkpv0Krj_.PquR6qrO0ibx b8vnbpXg0ksEf3RuNuTwDOutseltFHuO3WOwevqcDC.HLys_XMXQFD3g- Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.bf2.yahoo.com with HTTP; Sun, 24 Jun 2018 20:07:06 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp430.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 318736ef42c27f6b42c945aefdb6cb32; Sun, 24 Jun 2018 20:07:03 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: numa involved in instability and swap usage despite RAM free? Message-Id: <14F2E7C6-4094-4EF5-A1D7-0D56B43ACE62@yahoo.com> Date: Sun, 24 Jun 2018 13:07:00 -0700 To: Alexander@leidinger.net, FreeBSD Current X-Mailer: Apple Mail (2.3445.8.2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 24 Jun 2018 20:07:14 -0000 Alexander Leidinger Alexander at leidinger.net wrote on Sun Jun 24 10:03:49 UTC 2018 : > Short: > Can it be that enabling numa in the kernel is the reason why some > people see instability with zfs and usage of swap while a lot of free > RAM is available? [It will likely be a few months before I again have access to the environment these notes are based on. It has been about a month since I last had access.] On a AMD Ryzen Threadripper 1950X (16 cores, 2 HW threads per core) I enabled: options NUMA options MAXMEMDOM=2 in fairly recent times. This is a UFS context, not a ZFS one. I'd not been explicitly controlling how things run (so using defaults). This is head with debugging disabled (via including GENERIC and overriding). I did not have the swap usage problem with doing many buildworld buildkernel (self hosted and the cross builds for several targets). Nor when did a poudriere bulk -a (with ALLOW_MAKE_JOBS=yes ). This was a FreeBSD native boot context at the time. (I usually have run the same drives under Hyper-V but have not seen the problem there either.) For native FreeBSD I used -j32 (in buildworld/buildkernel terms but also for the bulk -a) and for under-Hyper-V I used -j28 . 96 GiBytes of ECC RAM total (48 GiBytes/NUMA-node). I'm not sure how common NUMA being enabled is, nor how common various MAXMEMDOM settings are. I'd not be surprised if various folks reporting problems had not explicitly enabled NUMA, nor set some explicit MAXMEMDOM figure. It may be that they all have ZFS in common in fairly recent times. (I'm ignoring examples of long-latency I/O on the same device as some swap partitions that are in use: this gets into Out Of Memory process killing without the swap being mostly used. Some reports of swap problems have this sort of issue involved on small systems unlikely to be using ZFS.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Mon Jun 25 02:04: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 2609B101F1EC for ; Mon, 25 Jun 2018 02:04:35 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660074.outbound.protection.outlook.com [40.107.66.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT TLS CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 71C6C85CD1; Mon, 25 Jun 2018 02:04:34 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM (52.132.44.24) by YTOPR0101MB1564.CANPRD01.PROD.OUTLOOK.COM (52.132.50.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.884.24; Mon, 25 Jun 2018 02:04:32 +0000 Received: from YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM ([fe80::d0eb:3783:7c99:2802]) by YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM ([fe80::d0eb:3783:7c99:2802%4]) with mapi id 15.20.0884.023; Mon, 25 Jun 2018 02:04:32 +0000 From: Rick Macklem To: Konstantin Belousov CC: "freebsd-current@freebsd.org" , Alexander Motin , Doug Rabson Subject: Re: nfsd kernel threads won't die via SIGKILL Thread-Topic: nfsd kernel threads won't die via SIGKILL Thread-Index: AQHUCzMbOoi8yQKY7UygDXm1hs0B0KRvJmwAgAESAI8= Date: Mon, 25 Jun 2018 02:04:32 +0000 Message-ID: References: , <20180624093330.GX2430@kib.kiev.ua> In-Reply-To: <20180624093330.GX2430@kib.kiev.ua> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YTOPR0101MB1564; 7:brXuicSweFWNNqIQmOjLI8GAzAzshh5Unb8pijvapsU+gSSgTZ9k+r6BHdX6qgh6QG3xoNLx0xNhmEsUrd9QEMelzrkeQQkaJ8MhlzPT5UArrjNmQaxl9JDhQZNgn7NIpLXC7wi/QEBBHEqOwAqwx4Hhs+29tb7dcYgHOeF1fMhoZFF8qArnQ6WSQgIgJERRS9lX/YUA6FqqvsU41x1x26SEXGj4AlftxsK/jGpOmSoerRJQSYoqSv1LrWNVWEab x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 446d1d13-a381-4c90-7bd1-08d5da3ffe02 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600026)(711020)(2017052603328)(7153060)(7193020); SRVR:YTOPR0101MB1564; x-ms-traffictypediagnostic: YTOPR0101MB1564: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231254)(944501410)(52105095)(149027)(150027)(6041310)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123564045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:YTOPR0101MB1564; BCL:0; PCL:0; RULEID:; SRVR:YTOPR0101MB1564; x-forefront-prvs: 0714841678 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(396003)(366004)(376002)(39380400002)(199004)(189003)(74316002)(54906003)(6506007)(3280700002)(8676002)(81156014)(74482002)(59450400001)(186003)(6916009)(26005)(102836004)(8936002)(81166006)(5660300001)(7696005)(2906002)(68736007)(2900100001)(76176011)(786003)(99286004)(105586002)(25786009)(3660700001)(106356001)(305945005)(5250100002)(316002)(55016002)(86362001)(229853002)(6436002)(4326008)(39060400002)(1411001)(14454004)(53936002)(6246003)(11346002)(478600001)(446003)(33656002)(97736004)(9686003)(486006)(476003); DIR:OUT; SFP:1101; SCL:1; SRVR:YTOPR0101MB1564; H:YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-microsoft-antispam-message-info: nGydpW4wvgInn01n0waepQMOdzhA50U/TQpfJSCIZ1tKZHdKQy7B1iCPQnun/cIZC1po2gg7FJtxk2gTfL9aPTBypFaV4zULxQaY0d5jqHVy+pqOpnUe8/UJEn5wqGVkWriCQTE4mU+nJoFEsBBjvkGp0u/EHuL7nkcWU0xafIHEiXLGaZ+D4fgD0kkRKCf6h8VvKkAvN92mmpPYhYAOBvS5OPXN/tPr6n6V3GW3+6ush1DjSqANx18t2p4nSBIWKqIBwv4QiuLJrR3EqPg8jjXcuwYz8GZ5nfYaZ1zdf0mu7mNGR96aS93WyYlOLMN2fSkr9wSsfq8H9kvOf6cFiNGKb3XnwfMNS/EGJtY3Av8= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-Network-Message-Id: 446d1d13-a381-4c90-7bd1-08d5da3ffe02 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jun 2018 02:04:32.1152 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTOPR0101MB1564 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 25 Jun 2018 02:04:35 -0000 Konstantin Belousov wrote: >On Sat, Jun 23, 2018 at 09:03:02PM +0000, Rick Macklem wrote: >> During testing of the pNFS server I have been frequently killing/restart= ing the nfsd. >> Once in a while, the "slave" nfsd process doesn't terminate and a "ps ax= Hl" shows: >> 0 48889 1 0 20 0 5884 812 svcexit D - 0:00.01 nfsd: = server >> 0 48889 1 0 40 0 5884 812 rpcsvc I - 0:00.00 nfsd: = server >> ... more of the same >> 0 48889 1 0 40 0 5884 812 rpcsvc I - 0:00.00 nfsd: = server >> 0 48889 1 0 -8 0 5884 812 rpcsvc I - 1:51.78 nfsd: = server >> 0 48889 1 0 -8 0 5884 812 rpcsvc I - 2:27.75 nfsd: = server >> >> You can see that the top thread (the one that was created with the proce= ss) is >> stuck in "D" on "svcexit". >> The rest of the threads are still servicing NFS RPCs. If you still have = an NFS mount >>on >> the server, the mount continues to work and the CPU time for the last tw= o threads >> slowly climbs, due to NFS RPC activity. A SIGKILL was posted for the pro= cess and >> these threads (created by kthread_add) are here, but the >> cv_wait_sig/cv_timedwait_sig never seems to return EINTR for these other= >>threads. >> >> if (ismaster || (!ismaster && >> 1207 grp->sg_threadcount > grp->sg_minthrea= ds)) >> 1208 error =3D cv_timedwait_sig(&st->st= _cond, >> 1209 &grp->sg_lock, 5 * hz); >> 1210 else >> 1211 error =3D cv_wait_sig(&st->st_cond= , >> 1212 &grp->sg_lock); >> >> The top thread (referred to in svc.c as "ismaster" did return from here = with EINTR >> and has now done an msleep() here, waiting for the other threads to term= inate. >> >> /* Waiting for threads to stop. */ >> 1387 for (g =3D 0; g < pool->sp_groupcount; g++) { >> 1388 grp =3D &pool->sp_groups[g]; >> 1389 mtx_lock(&grp->sg_lock); >> 1390 while (grp->sg_threadcount > 0) >> 1391 msleep(grp, &grp->sg_lock, 0, "svcexit", 0= ); >> 1392 mtx_unlock(&grp->sg_lock); >> 1393 } >> >> Although I can't be sure if this patch has fixed the problem because it = happens >> intermittently, I have not seen the problem since applying this patch: >> --- rpc/svc.c.sav 2018-06-21 22:52:11.623955000 -0400 >> +++ rpc/svc.c 2018-06-22 09:01:40.271803000 -0400 >> @@ -1388,7 +1388,7 @@ svc_run(SVCPOOL *pool) >> grp =3D &pool->sp_groups[g]; >> mtx_lock(&grp->sg_lock); >> while (grp->sg_threadcount > 0) >> - msleep(grp, &grp->sg_lock, 0, "svcexit", 0); >> + msleep(grp, &grp->sg_lock, 0, "svcexit", 1); >> mtx_unlock(&grp->sg_lock); >> } >> } >> >> As you can see, all it does is add a timeout to the msleep(). >> I am not familiar with the signal delivery code in sleepqeue, so it prob= ably >> isn't correct, but my theory is alonge the lines of... >> >> Since the msleep() doesn't have PCATCH, it does not set TDF_SINTR >> and if that happens before the other threads return EINTR from cv_wait_s= ig(), >> they no longer do so? >> And I thought that waking up from the msleep() via timeouts would maybe = allow >> the other threads to return EINTR from cv_wait_sig()? >> >> Does this make sense? rick >> ps: I'll post if I see the problem again with the patch applied. >> pss: This is a single core i386 system, just in case that might affect t= his. > >No, the patch does not make sense. I think it was just coincidental that >with the patch you did not get the hang. > >Signals are delivered to a thread, which should take the appropriate >actions. For the kernel process like rpc pool, the signals are never >delivered, they are queued in the randomly selected thread' signal queue >and sit there. The interruptible sleeps are aborted in the context >of that thread, but nothing else happens. So if you need to make svc >pools properly killable, all threads must check at least for EINTR and >instruct other threads to exit as well. I'm not sure I understand what the "randomly selected thread signal queue" = means, but it seems strange that this usually works. (The code is at least 10years= old. Originally committed by dfr@. I've added him to the cc list in case he unde= rstands this? Is it that, usually, the threads will all return EINTR before the master on= e gets to where the msleep() happens if the count is > 0? >Your description at the start of the message of the behaviour after >SIGKILL, where other threads continued to serve RPCs, exactly matches >above explanation. You need to add some global 'stop' flag, if it is not >yet present, and recheck it after each RPC handled. Any thread which >notes EINTR or does a direct check for the pending signal, should set >the flag and wake up every other thread in the pool. Ok, I'll code up a patch with a global "stop" flag and test it for a while. If it seems ok, I'll put it up in phabricator and ask you to review it. Thanks, rick From owner-freebsd-current@freebsd.org Mon Jun 25 09:23: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 0F0AB10033B7 for ; Mon, 25 Jun 2018 09:23:39 +0000 (UTC) (envelope-from alexvpetrov@gmail.com) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::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 57BC974052 for ; Mon, 25 Jun 2018 09:23:38 +0000 (UTC) (envelope-from alexvpetrov@gmail.com) Received: by mail-lf0-x235.google.com with SMTP id q11-v6so13860522lfc.7 for ; Mon, 25 Jun 2018 02:23:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:openpgp:autocrypt:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=CjfaBH17ViGJtZPeNj4Z922Q/YuLxxfqFsL5DRwMolA=; b=ocy/3VQtvVS/icE0sZ9GMG8a063kzLmutAFWDc07it3yd3aeahD0yHXfYcmioO7FZR 82SdEJkRXgYuaV6O/OHujZg9SN1lOMCjDsT+B5Fmj6JIb3zyJ35GuKh5UlLP+J57BPeF BkJU2DHOd24krfF/wiMu4XFEliMBnYyWVNm4avmmxq2Nq3h2SLQw/l4uVYw2xPwSTvrj /6bJkJutbsusKDRGAr6OKHZPsc65MxGcQojuDc4rUsbiolT3I4Sn6rKeZ0xSs6dKFRwF JcGGaVSfEgI+Exei8KdYnR9o1e3PtDpf7cz2aJPpSkRS4LU7rQq/bIMRxVCChtXhw0Xg arQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:openpgp:autocrypt:message-id :date:user-agent:mime-version:content-language :content-transfer-encoding; bh=CjfaBH17ViGJtZPeNj4Z922Q/YuLxxfqFsL5DRwMolA=; b=eIHq3ycvYw4pDxTn1OVSKtEhIO1ew+fKeDrc5yTfVDdcyL+09toa5X6N/L68albkrH ZaR4jc/F2/MMV1XkoTN6Mekk2ossSPdqx37WDXEcE7a+scLqpRKDZHEdZvjPU728YbhG 0X+lN0IiukEZjhYTC/UjbtAljb4EXBTGugecLGkpZSUGQUtYVu29LVZgYJXlQ5MrGOXs 0BQDBCKHQikuxx2KD3739HNZQpYZPqQVvBXsu12fG9NuWdBiKjRZ2N3pTvIJyBAAHgW+ oE5glBOlS2xsTfqOs74civJJ1ZIP70SBUSrM5YxvhhS5TkDEDpkmsb8r7FMbsJGdmA1k flRA== X-Gm-Message-State: APt69E2yIDbNkQl7Qgt+unhNR3qKQDOo2mc5bYjR4blAw0EGgyhIdvL7 gfKbLhBV7laHOQSCr8yASPG9lQ== X-Google-Smtp-Source: ADUXVKKqCZxoRhSjW//N7e5eCwgYv+R9U1XWuo8ESaoLjLlSRn//tYxNONAJHt+/7WK8Y9LC8jQOog== X-Received: by 2002:a19:cc0f:: with SMTP id c15-v6mr5692341lfg.145.1529918616731; Mon, 25 Jun 2018 02:23:36 -0700 (PDT) Received: from alex.super (stone.g-service.ru. [84.22.141.217]) by smtp.googlemail.com with ESMTPSA id t84-v6sm3085163lfi.55.2018.06.25.02.23.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Jun 2018 02:23:35 -0700 (PDT) To: freebsd-current From: "Alex V. Petrov" Subject: top (r335596) units of memory measurements Openpgp: preference=signencrypt Autocrypt: addr=alexvpetrov@gmail.com; prefer-encrypt=mutual; keydata= xsFNBFr3oA0BEADMSXiVd/IwYhJPMQ6LXbZ7jTA/RXuzrGYaR++UENx5QJ6/HJ/3myTeMnZE nNa0Zme+oKw/9s5x7rBTP6mL5ta7VSYpnPX932mAjT9J4nS7iW/wWNBqcXn7wDCog2TV8Ww3 13SUP2YaKoJKJLxddiZD6AJrkafB9EE/AycMQ8XxMao1lVS+/KAo0yciOsnSlIJCWhF00b3j xDlHLvehrDa4S3EB13bF6uE0XU5nFfMNHtBav2mwD9t01hNioCNTV1hXwmsS/L1n5PR5FyJJ yYtjeohrAUiGKGJU9lJJ6tROBhzV/k3OsOGPyajFOVsW0vUueYfgw+IAPYdOZIAONgNdxkvs tRLQxYPCBMN1FvQ7GlIhq7ob+mxuA1imXx3xzlYy5tu4QzB383qZtLqQnZpysjYooAbHl+eN vB2ldvH9TZxm3fxxNL6zgYAXE/pNgFoqg/ILmhDwvvHzApHqVCKU3g6yii0KPxD7susaUWcL JYgrmt2BIE0RuiQRGWyS0L277D/YGmVnPNHxPi58DBs2iexDm7jw7PhlmfOw44N9w+O09D2S gqmBHySAtsq9Z5LoM81F+LrOoVmpYczZWErS917Gua1X7K3wrXoqQC8qcSiHZpEcBl/Uohii QWzjQJot5LT7rvfFHpnSOXAKgN7enVM7KxTJAYK1U343GGdepQARAQABzTZBbGV4VlBldHJv diAoZmlyc3QgZ2xvYmFsIGtleSkgPGFsZXh2cGV0cm92QGdtYWlsLmNvbT7CwY4EEwEIADgW IQRvKPTT2TJuh37ANx313p8aVpVkcAUCWvegDQIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIX gAAKCRD13p8aVpVkcLLeEADClYAElEInGGjtLfH4jdjvTDaQTsrwT5/1E5/h8yxI4yn7hCt1 Dh+iCSUNLdPO88nZV2jP8bMQXFBKSbC0nAJXd8O+8t9AfSWoUC6IMzncxKTK/jZuJTCToCUR XZ+47+uJaBp51rpw3pFX8UrFlYSF6Dz97dI2cGHfx3xAOnowKxyHfthxS8waKWgbMOceds78 BP2+Q0iLCpoC9rO4KDc+w+h8z21eHIE9VHadTHpnKVF82voPH8XWvznTOCpYrdBwUtIyD/DV XRb0xcFsOSkvmReYX7u4QuOPLSc86sEWh4hXTFLAOdfeTjrDTDmBcmFpltmW1j+5t4mI1dK8 gptREM8gMJVJw3jjcO6jADeXX9q5C8/lX0sEGz9uC4oU5nkOMyfzd9Anb+9bCs7pMxhqAKjA 8tqJPPkmJU8WzMCs+uudIiQ8W9qIETwUJWxizQ3kvlzLfWRz5n93Y9kzSmjw81aiIJK/HFY8 wsW5zNo6JBn57cMPx8nBC4E2zM09ffmqSpjDwXfvZF2IIR8L4VTiKi3ovwLglJP+Qbs5HXNn 6K40cPNqfnHzPLwXwd/co04B/VVr+cKZuE58kYGty9Xs9q/SEpObDnxnLxMNHUNJJuRgOiti TKDkteHuKm6NA8v05o3TDQ5HU9szEoE5uoi/3pQ1ktfA/K3LkDwbotXL+87BTQRa96ANARAA w5+/xcaCP6iwsi2CFQ4pAWksdmPBEHA2VPn1ym3C6opjbyWUp6sn25eTWppdhA9rUqbM/zV/ hAFRT67oZJKBYNRaMoDdO8BsVZsg/u76QF/GuhbUjIk0tFFdpddMXl0zKAJJMCfDRxURRWv7 NW6sY/EZ4Dal5s4xOT+UrWGag3qoaIRdzw5bJRP+o75L90cE8pd7+Pd9cVJOOtTAwx0E4bPq dPSa6CPDSvzd9D3mw37dPzXysyQkQTy0OM7255E2wjYz3RbJxB3utybPVN3XJBD5EyA8IYeS ic1/03UrkRNv4XrLnlg7xLv96ZeCrf/BDNQW23iVwbISUAk4TXL7xs2TGYOmowZ89mMEcbfW ChX3YLAuAeWzgpMcrDC00izOxG0spkkrHL7/i1iSu2MKhv5qMTVgchlSktdd+KTba5keleHv ULQ3feGUKf9eTkKgES6q4rKrae0tIwByTLhhDVbkXqR6v8zrpJSscrvJ3tMNgquJKy5ATIUB nvUE2hMkSwtnJ2vQ/Z0zGt6c5KxI57/hsb148tXp1v3gAq9d6i8c8ChxSR/kUlqAvzl2QGcn CFVN6nfOzyNfBPZ61abNzkzjzyhOK4Gq4gQvx4QXhDp3jEME7rPM0Tqf0venb1Dp7SIHwggV yJglGApwoUvD4kKNIC7KDr+s/UjbBp4ExFMAEQEAAcLBdgQYAQgAIBYhBG8o9NPZMm6HfsA3 HfXenxpWlWRwBQJa96ANAhsMAAoJEPXenxpWlWRwAaEQAKm0imG5Fm37JZi+5faXJv/ZLZGl r4TVg4u1kMktdTQRrTXa3Qs0i3wTtOZe1p3xCCzPx+97iYETHragDTdAFUO+v+Llin26L1Zl z4huyIqgGSuTuekQfn6eoMZbcF+wzah4j/mvXQVpJBF2qQi1YdHSapWDlweuiuk01y8C3eHv 3qfFB/OJwXhwj0HKhkGkB2dLXuLtIk4GCXh4/g22tWz/SB0gsSXU7WhJFb0CyxETGR9YKxM8 CNl5tVRLqsBC6yQLvcAJgJci73PfMiHKnjxrz//+0xQO1TPeruWsd8nLYvziT38CyX42Mbaj 01WpvB0qOeTGtwGFmyyrnE8fYpd3CE0uAl9BnHqafAabl9+09x3wf+lEkkO2bK59akZz3BPU 8Lz2BAgskyS81WZCthQYUrUozFEx/31x8JJ95EQFNW9t8HBa51r4QhedSNKxLbT3Sx8hH0iq Z8wYkGw0og9U1DqgFzxE2HSGZSDG3I1DrPDqhcM/6Y0V98wS+XreuS88DYYck37+L7bTGiyZ WYFNZk1ChcIBk8hgKn5nFOCWO2rX06RI9zorzSpEg6lB2STae1Up5oEj8QqfYmfO3cp2Qhvj F3c2/i8KpWkJQkAgNrv428FIlx9SiPu9gvNTTYuLIOdZLQvInTmKs2uCoB6JDAW75axDhBbR FvM3Vpv/ Message-ID: Date: Mon, 25 Jun 2018 16:23:33 +0700 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-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 25 Jun 2018 09:23:39 -0000 In the last version of the top, units of memory measurements in GB. I only have 16GB of memory. And now I do not see the dynamics of treason. -- ----- Alex. From owner-freebsd-current@freebsd.org Mon Jun 25 12:40: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 3AC89100D519 for ; Mon, 25 Jun 2018 12:40:15 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (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 DC96B7AFBD for ; Mon, 25 Jun 2018 12:40:14 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 58DB12193A for ; Mon, 25 Jun 2018 08:40:13 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Mon, 25 Jun 2018 08:40:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=qX9TYoRVjddKoZj5Qnb41IP2qa6lJ821OepL/w7489Q=; b=Z43VWpBV S6tw0+hj44BaGCRaJRnJFzn0Mkr412MAoSxQFlRwhADc6qSCEkQ5JT92EyryBo7F 1tqavGGEHS9iJptpjaKRs+xPIAV77uabmFZTJyIslQgXB/m6vr/cmp395eBHtd+8 OCFzVoGu/TmMLR3r5AdgHn+bBky6hc0cKMkRjqWOyGqIBBc2+g8dC7ckxE0JU7jE HawBagZroJ8yT6mVBz8jgRkg09ztINCSTRM71d6Lt5hSEur4MacKJLHxnotN6Te4 JRYplWyZNcLLYeyTzNxPC1X0MNS10W3XUwfvtbQbwaNsK+6NoMSu+AqqpyLKmlRH UWhtklmotzPg/g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=qX9TYoRVjddKoZj5Qnb41IP2qa6lJ 821OepL/w7489Q=; b=qI0Wy92pvTzsLwzGAn5fqfTQilCK+VUh1+CBXh+LlZF0H LRqeKXBBPaPWeRHvcnOO/erEoDj/hKA6u8TnkPBtGm7Dl2pJvnRoZSUgzyScYI3N zNI/OnDMfa+SAB3U0FvVz2nVAXBCCG/xlccWvJ7/1KEbiBOV+QQsZOLxcOWzUXaE QruLP5mL0kxbwoaRtQUL2fTnGOAY+bJBvWRcnhJ+CE8qIR1i9cWFZ7GXHLcOTuc9 4mw9DgT/p25Skpct6hTUNArMbg8wifxpbxxUeVti9QdgPACv0X4XBddXOriZzpyb UhGkRRXvnrVwZuKKaw7camHGaG0qWJOKb8gBHR/bg== X-ME-Proxy: X-ME-Sender: Received: from desktop.local (parsley.growveg.org [82.70.91.97]) by mail.messagingengine.com (Postfix) with ESMTPA id D2DF610428 for ; Mon, 25 Jun 2018 08:40:12 -0400 (EDT) To: freebsd-current@freebsd.org From: tech-lists Subject: ino64 Organization: none Message-ID: <68667907-4698-c2f0-3d97-bb7f75ff6bbf@zyxst.net> Date: Mon, 25 Jun 2018 13:40:11 +0100 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; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 25 Jun 2018 12:40:15 -0000 Hello, When upgrading an old-ish 12-current (r317212), as per: > 20170523: > The "ino64" 64-bit inode project has been committed, which extends > a number of types to 64 bits. In order to upgrade, carefully follow > the full procedure documented below under the heading "To rebuild > everything and install it on the current system." Specifically, a > reboot is required after installing the new kernel before installing > world. is there anything more specific I need to do as well, like rebuild all installed ports? The system runs ZFS. It is *not* root-on-ZFS though. Is there anything more I need to consider for this? The system also runs bhyve. Are there any special considerations I need to bear in mind for the guest VMs? thanks, -- J. From owner-freebsd-current@freebsd.org Mon Jun 25 14:03:42 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 BA8991010020 for ; Mon, 25 Jun 2018 14:03:42 +0000 (UTC) (envelope-from dim@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 542B97D957 for ; Mon, 25 Jun 2018 14:03:42 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 10AB1101001F; Mon, 25 Jun 2018 14:03:42 +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 DFD38101001E for ; Mon, 25 Jun 2018 14:03:41 +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 776247D955; Mon, 25 Jun 2018 14:03:41 +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 86880D238; Mon, 25 Jun 2018 16:03:34 +0200 (CEST) From: Dimitry Andric Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_F0B0D016-5D71-4473-BF0E-DFB2A8AE3798"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: clang on 12-CURRENT traps on its internal assertion when build kernel under nanobsd.sh control Date: Mon, 25 Jun 2018 16:03:30 +0200 In-Reply-To: <740aad56-4fed-d3a0-7f18-8c7c11d7ff07@FreeBSD.org> Cc: current@freebsd.org To: lev@FreeBSD.org References: <740aad56-4fed-d3a0-7f18-8c7c11d7ff07@FreeBSD.org> X-Mailer: Apple Mail (2.3445.8.2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 25 Jun 2018 14:03:43 -0000 --Apple-Mail=_F0B0D016-5D71-4473-BF0E-DFB2A8AE3798 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 22 Jun 2018, at 16:18, Lev Serebryakov wrote: >=20 > I tripped over very strange, but repeateable (in my conditions) bug in > clang on 12-CURRENT. This message will be rather long, as I need to > describe all details. ... > /usr/bin/cc -target x86_64-unknown-freebsd12.0 > --sysroot=3D/usr/obj/nanobsd/data/src/amd64.amd64/tmp > -B/usr/obj/nanobsd/data/src/amd64.amd64/tmp/usr/bin -O2 -pipe > -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc > -I/data/src/sys/netgraph/bluetooth/include > -I/data/src/sys/netgraph/bluetooth/drivers/ubtbcmfw > -DHAVE_KERNEL_OPTION_HEADERS -include > /usr/obj/nanobsd/data/src/amd64.amd64/sys/D2500CC/opt_global.h -I. > -I/data/src/sys -I/data/src/sys/contrib/ck/include -fno-common -g > -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer > -I/usr/obj/nanobsd/data/src/amd64.amd64/sys/D2500CC -MD > -MF.depend.ubtbcmfw.o -MTubtbcmfw.o -mcmodel=3Dkernel -mno-red-zone > -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables > -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall > -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef > -Wno-pointer-sign -D__printf__=3D__freebsd_kprintf__ > -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas > -Wno-error-tautological-compare -Wno-error-empty-body > -Wno-error-parentheses-equality -Wno-error-unused-function > -Wno-error-pointer-sign -Wno-error-shift-negative-value > -Wno-address-of-packed-member -mno-aes -mno-avx -std=3Diso9899:1999 = -c > /data/src/sys/netgraph/bluetooth/drivers/ubtbcmfw/ubtbcmfw.c -o = ubtbcmfw.o >=20 > ***** > Assertion failed: ((!RequiresNullTerminator || BufEnd[0] =3D=3D 0) && > "Buffer is not null terminated!"), function init, file > /data/src/contrib/llvm/lib/Support/MemoryBuffer.cpp, line 48. > ***** Which file system is = /data/src/sys/netgraph/bluetooth/drivers/ubtbcmfw/ubtbcmfw.c on? Is your obj directory on another file system? I'm roughly guessing there is some sort of problem with memory mapping, or the file system itself, since the assertion is similar to what was reported here: http://lists.llvm.org/pipermail/cfe-dev/2014-May/037059.html -Dimitry --Apple-Mail=_F0B0D016-5D71-4473-BF0E-DFB2A8AE3798 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 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCWzD2MgAKCRCwXqMKLiCW o1a7AKDDEi1vOdy2yLiHNaLLdECFWBQCUACgj8sXDBBHZ7TYahtXK6sfT5VA2Qo= =m+t4 -----END PGP SIGNATURE----- --Apple-Mail=_F0B0D016-5D71-4473-BF0E-DFB2A8AE3798-- From owner-freebsd-current@freebsd.org Mon Jun 25 14:28: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 7459F1010C38 for ; Mon, 25 Jun 2018 14:28:11 +0000 (UTC) (envelope-from lev@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 E277F7E5CF for ; Mon, 25 Jun 2018 14:28:10 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id A60771010C36; Mon, 25 Jun 2018 14:28:10 +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 837A51010C32 for ; Mon, 25 Jun 2018 14:28:10 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.not-for.work (onlyone.not-for.work [IPv6:2a01:4f8:201:6350::2]) by mx1.freebsd.org (Postfix) with ESMTP id EC60D7E5CC; Mon, 25 Jun 2018 14:28:09 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [192.168.23.186] (unknown [89.113.128.32]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.not-for.work (Postfix) with ESMTPSA id 30179E7D; Mon, 25 Jun 2018 17:28:08 +0300 (MSK) Reply-To: lev@FreeBSD.org Subject: Re: clang on 12-CURRENT traps on its internal assertion when build kernel under nanobsd.sh control To: Dimitry Andric Cc: current@freebsd.org References: <740aad56-4fed-d3a0-7f18-8c7c11d7ff07@FreeBSD.org> From: Lev Serebryakov Openpgp: preference=signencrypt Autocrypt: addr=lev@FreeBSD.org; prefer-encrypt=mutual; keydata= xsFNBFKbGksBEADeguVs+XyJc3mL3iiOBqDd16wSk97YTJYOi4VsHsINzJr09oFvNDiaDBIi fLn2p8XcJvehcsF2GSgrfXfw+uK4O1jyNIKJmiYA0EtE+ZbRtvDrrE0w6Q8+SDeKA21SWh3Y vSQ0DJUontbgW55ER2CbEiIUTIn34uQ0kmESAaw/v5p/9ue8yPTmURvv130FqPFz8VPzltqL NxyGt54TxPfKAzAHEIwxlEZ63JOwzloKh1UDBExcsf9nJO08/TAVgR5UZ5njFBPzaaquhRoP qPJLEQQDqxPIlvMNtHKf7iIebE4BHeqgCdJA0BoiR6gpa0wlsZtdrTPK3n4wYSphLvGbhfOZ YW/hbcu7HYS/FImkVxB3iY17kcC1UTnx4ZaYeASPBGOOPbXky1lLfmDGWIFT//70yx+G17qD OZzF1SvJJhGvh6ilFYaWMX7T+nIp6Mcafc4D7AakXM+XdubNXOMlCJhzPcZ0skgAEnYV587w V7em5fDVwQccwvtfezzqKeJAU5TGiywBHSR5Svzk2FwRNf6M//hWkpq0SRR63iOhkHGOAEBi 69GfEIwH2/w24rLxP0E+Hqq8n+EWNkPatw1Mhcl5PKkdvGCjJUaGNMkpBffjyYo254JXRscR eEnwdIkJt4ErDvjb2/UrOFq31wWMOiLzJeVchAgvTHBMRfP9aQARAQABzShMZXYgU2VyZWJy eWFrb3YgPGxldkBzZXJlYnJ5YWtvdi5zcGIucnU+wsGCBBMBCAAsAhsDBwsJCAcDAgEGFQgC CQoLBBYCAwECHgECF4ACGQEFAlKbP8wFCQlmJwEACgkQ6rA8WL/cR4/6VBAAjRMyyX3PBFx/ HxyiIZ698EfwlWUua8Ft4crtrdK52m0qNkbBB9BH8xQgBHG32A1CwyzQnzxHgZuoOWMjh+Qq WJv7dmpM/q/c1GCJHhlPgewXrciTwpAamZILN071u+1GCPWwGRPzfQ/U+k63KJWx9ozf4doM WTTom6Cqcssi4J1u5kkt52a5ZRhsCK9pEVGilk36XTP9BakGrnMSIxF/NK4xeZVX2q+Nuqvf RchyofKXVgLEDLwb1cd/baLtBpDzy0PTN2Zl2lX4kOA6jwTKsqRya9A1Vui1KXwPh2XViTQ1 7Y3l5qg/M+sR73DohezP6bO6huOnLhty17jAqHPNlD6RonDo+j8uIlEg4iMSTN3MhzkBAu0Q pe3ucQ0o1767JiXN3fsNvRzSFhLVNDqPLce4uKlMogsbreXWvdgHGTN1ybOHGbybZnP77yHz uNBacbmG3vL/OLXMqwLdL2JXoiec4DmXjjCdhTBl5xLV9Hz/6VWKqElteg8QFVvHB3tHWzJ4 /rpiVEixytCIII6DS33BXZ0h2EOkK/6AYA2SJxy1vgOH4SZBtDBHoezmHV2nFnq5O0c7AuAB 7WPWgQG0sEwHQPZmg/baRGitRJnaxf/Gvf1DeD1x1VrcoVke2vwBcgDM3kugP8L9hsqic2D3 dI+gP76haeuvNNZr3y9L9zvOwU0EUpsaSwEQALRr3B+OjY/cnJPstz5CVsVWyEZtJtrNviZr tBgbkhlkPm98sEWR4+gbpyeufdYJengDjeGzMDKcLB7h5fICS/j6A8XdlJ40TlbPfNgb6OHa ebaIYKTJpXKR9sD7ZyGivYMofm0em40wGUX7BIkdkomaWj+wUiS0CdXU0FWDj9wv73+Eim+X zZyXeFgIPv97v+pET7DfwKkADOfrkW9s4OfvGVjd+wm35wc8EngQEz0qdPBxx74X7vZFAxlA SXu8gDBJGYt2Bkc3QwULnfeXrZJWgqNPR5o44gGu96yaiOFaN/C6CJtev5ZEX+0ZxbvsHHB7 Z5AtsRURKpZ4w5HFHGhzHtDtoAKgeZ/gbhTVXPHvNQR818eN+Nl5BV8BRF/8yhR6VlJb8GYw h8oKDeVGVYC34+raHZQAM9WoBnN7jlt4T9zzPwtmw5mIahGFgvw1KDr7OItN2ZgtZ20UYC5m Go602nmHq0aPbU6SwGi1xohrliNsKaaciYiMaVIGRQq8iGr9Fe2HlvaA3BpB275i/gCVlUdG y5XLAv+yQMUvn5Z7XVsMroxDk/O+ae1ElyBvKiKyfWGJXTg5XUukkkyQmfWPxWUGoNA1P/P4 GMHSu7/Rqe/7m4uPu/RyTTqsSjjKJdP9kBwEzvqPtXsVoZuShtrptRQJDYflhgE4qmKSMKen ABEBAAHCwWUEGAECAA8FAlKbGksCGwwFCRLMAwAACgkQ6rA8WL/cR48RkA//SNzeW3CI8KHx rA0aeHW6Nb5ieoqVRBGLyjBM06RX6vHB9v4dJL6Z+yV2jGN2s+XZX2HILbuTOwcTxGkI3xTT e0cDXVaF5K8R/liigUjtwuC2v/sWgoWyUmK1Cy9CPYdcXmFq6nESfkUe8DYiGOUULdHq5w63 F53yOZ72iXRBQBZgkhPtRFu4lPYIzOsMag9DIJ9CthR1r0ziqU/keb94Qt3l+aXK7CwGdY7X T4zUIMHNYsuAuyX+NJIXfsN68TT6m7QmlUwxPs13nxmoVQzm4ruV+hlQKh1MtbsjWRkNgPxF IPiqoAEhy8QoddlSvRTwL5Z7zFQiwMdiXU7toL8pfzj/zJR1jELXKMipijrt5MLrV8XX3OPN yZZvh95VIl8mv+iAqwSZUufd2EJnvj5TObB0eH+a+34NWf/XqA3fPjE6KHzmdnw9PZjPEjlx JCPECSs+6gse1+GaEfKYuXzB/ENe2ctlcfx5iQJXFc+/+zG/uU/JX/pXJHA12CUfB5g7lH6X BZIHvRo3VTCDjXgbF5xxDAe5V4exf8d4oSNjQIFLYxxN7zkvH89EN6RPfRgsWN7bYArCwfS9 MOgs9pFeCOewR6qieK150aoqNENGfKFXJup+5VVl6I0mU+j0rgVDZDht2/QgP/Tb4lGBe+ai pOGaK/GYNR+Ad6bUmokKsx4= Organization: FreeBSD Message-ID: <0cade4c6-7191-4f68-74b0-83e88c6740fc@FreeBSD.org> Date: Mon, 25 Jun 2018 17:28:01 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ktLmpmPv0bDXr3ANKvBbLnjqFD3nvym6J" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 25 Jun 2018 14:28:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ktLmpmPv0bDXr3ANKvBbLnjqFD3nvym6J Content-Type: multipart/mixed; boundary="3yAb9aw9eUuiOWPiN0fafSZWZyiTSqWNQ"; protected-headers="v1" From: Lev Serebryakov Reply-To: lev@FreeBSD.org To: Dimitry Andric Cc: current@freebsd.org Message-ID: <0cade4c6-7191-4f68-74b0-83e88c6740fc@FreeBSD.org> Subject: Re: clang on 12-CURRENT traps on its internal assertion when build kernel under nanobsd.sh control References: <740aad56-4fed-d3a0-7f18-8c7c11d7ff07@FreeBSD.org> In-Reply-To: --3yAb9aw9eUuiOWPiN0fafSZWZyiTSqWNQ Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 25.06.2018 17:03, Dimitry Andric wrote: > Which file system is /data/src/sys/netgraph/bluetooth/drivers/ubtbcmfw/= ubtbcmfw.c > on? Is your obj directory on another file system? It is two different local ZFS FSes on the same pool zpool/usr/obj 4.83G 109G 4.83G /usr/obj zpool/data 2.62G 109G 26K /data --=20 // Lev Serebryakov --3yAb9aw9eUuiOWPiN0fafSZWZyiTSqWNQ-- --ktLmpmPv0bDXr3ANKvBbLnjqFD3nvym6J Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEE+W0coLX0MYtnSzMK6rA8WL/cR48FAlsw+/FfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEY5 NkQxQ0EwQjVGNDMxOEI2NzRCMzMwQUVBQjAzQzU4QkZEQzQ3OEYACgkQ6rA8WL/c R49gyg//QJhhF3Zo7hetLF9PKXKaYd/hEYh63BmjcN8Km0Addn4pqR2O9tJ4S1Nh hKpZrSurV+pZEN0LxhVogMVEh56zm2a/W1nY+qoRXIWUi6lPfBQl52TCmG+e91jx K9It1bh08OcsRKW7jh8BhePeoSkFRAPkbzDiCbenkm00NMw+AZ6mZhiSM/T+x+Ko X4ZjhQJ5DkV4IMyBRSBJpkyexpi9c3OuaPISuRlgGlXlRV2dTkKzIztNtM/NRxs4 rfynO8pF+D+Fo4Rh24sN76RfHZFbDv3FPAFZS33A551SWHEyh2KSqs4o8Yooz8Dx G7flFtUd2WkqzwwiFxU/gDf6ZRDjc+/ytiNFCHD+N0vuxeHtfz+Pptk6NKFBAtli 5eMgEEOnA3iZKCuFXnbHEFdw2xj5O0O6oXWvPKmK5ASCyozZdfX8NRBu5EMBfJ5d 0fyXIaBae1zqHjNz6IOxE3fqbBPqpePchHOh3NdgM9Ihj2JotMMUwliIbcoCkj6g RKS7X8lIj4zx/CAr/x+KvVIFAmV9+3hbIEICN7HNRW9jDYh4kvdwHPx4MJCv9V+z q1Y64vWk8SRv0NZyDBqsB7l2cXS+pk6pfrE1Zv5T1bj84AhemmccnWe3nx3EFREh ZY0t/3liSR0XKT8E5AYlUCd1diV+Lg8rsKNgf/g8X+z/KjQWXqQ= =UHdn -----END PGP SIGNATURE----- --ktLmpmPv0bDXr3ANKvBbLnjqFD3nvym6J-- From owner-freebsd-current@freebsd.org Mon Jun 25 15:37: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 A10CA1013AAC for ; Mon, 25 Jun 2018 15:37:22 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1203681C6D for ; Mon, 25 Jun 2018 15:37:22 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x229.google.com with SMTP id 128-v6so7056393itf.1 for ; Mon, 25 Jun 2018 08:37:22 -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=6UOpTS1CxKDnJmfPKZ0QslDIYVCF/fR7SIfXssP89Fo=; b=Cm/r9oWjwF0aZiz+FaiqLhtNhF/MKzgNhzGY8X4lhKWEBEz/Q5N7w5IUPO/GxmhIXc IYgYBoJQY3M+ZdjDieydtLy33lgI1I4g5ZOKfMPGtf9YsX0f1hHDUWxHXPrNePOgDbfi US2AxKiDU4VC7VQPPmag7ufeRqi7kR26R5OCMGHsGuQ2heQdirYRkR0RBYb0TA654QOV 4rqCguqP5LnR94Cqllu6hjfaWebvbVesYjAeMesdzsRoNO99Zm0J1JQ+sLft3iyOnQIQ l+tBmBChd2yzH4vd54M54Q+TA87li/jfniqLQDA5JUavYegiOQfsdOM4ONnQyLGxOjtC R01g== 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=6UOpTS1CxKDnJmfPKZ0QslDIYVCF/fR7SIfXssP89Fo=; b=toXD4Utsf0xXFzeuw1EyYPvFqz/ufa1P1B2L9nzoLtSUcow8F33jtEZ9Etu+H+R5lx hlLBdnZqcaIDeH1lEBnI74Ou1AmepGVNl0R8LiC4MZtjko8ptMXUrTi/N4EnMHe8h89g nS3yKieT+HJvt6vBT/7bmkqL0APYmmB8G0WEVLZ9/X1JRWVLiaWNIG05RNHdKzVWPAzX C+coUEUxDPqg5xy9oTfeUc35SJ3XvH+55WaTVND+9UhofW6K+59n5a+3x3+wyHNjYqd8 Y5o6SJalYZSqXtfEDH6rSzwASZnnqBYp4H4bmh34IJ0mLsCIL3yU048J2pxVtu9EekXH Q5ow== X-Gm-Message-State: APt69E3dGxqVUyifyDaWRzfJmsn2mB2MfaI7ekfw/EKAN7afAoJRARe/ SsrfYYIJ7JaoB5g+Sj85K7bhWuiM3pHgsnRqkprNhQ== X-Google-Smtp-Source: AAOMgpdVyNdZAMt5auRURhPj01V6PnsPLittqxinubt/AtJgodCs4w8wLVkFineL6X3/3Bsk8UpBD9eEHAAfWE/9eqo= X-Received: by 2002:a24:64ce:: with SMTP id t197-v6mr1336283itc.36.1529941041389; Mon, 25 Jun 2018 08:37:21 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:5945:0:0:0:0:0 with HTTP; Mon, 25 Jun 2018 08:37:20 -0700 (PDT) X-Originating-IP: [50.227.106.226] In-Reply-To: <68667907-4698-c2f0-3d97-bb7f75ff6bbf@zyxst.net> References: <68667907-4698-c2f0-3d97-bb7f75ff6bbf@zyxst.net> From: Warner Losh Date: Mon, 25 Jun 2018 09:37:20 -0600 X-Google-Sender-Auth: EgakfG52YJ23ACE-ov6QxKzVis8 Message-ID: Subject: Re: ino64 To: tech-lists Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 25 Jun 2018 15:37:23 -0000 On Mon, Jun 25, 2018 at 6:40 AM, tech-lists wrote: > Hello, > > When upgrading an old-ish 12-current (r317212), as per: > > 20170523: >> The "ino64" 64-bit inode project has been committed, which extends >> a number of types to 64 bits. In order to upgrade, carefully >> follow >> the full procedure documented below under the heading "To rebuild >> everything and install it on the current system." Specifically, a >> reboot is required after installing the new kernel before >> installing >> world. >> > > is there anything more specific I need to do as well, like rebuild all > installed ports? > While the compat stuff generally works, there are edge cases where it will fail when you have a mixed environment. You're best bet is to reinstall all ports. If you do just a few, you'll hit the edge cases. > The system runs ZFS. It is *not* root-on-ZFS though. Is there anything > more I need to consider for this? > No, the change is agnostic to that. > The system also runs bhyve. Are there any special considerations I need to > bear in mind for the guest VMs? > No, unless they too are upgrade across the barrier. Warner From owner-freebsd-current@freebsd.org Mon Jun 25 17:40: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 4DCCB10182D5 for ; Mon, 25 Jun 2018 17:40:09 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (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 E57A8862E1 for ; Mon, 25 Jun 2018 17:40:08 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 66FC621D27; Mon, 25 Jun 2018 13:40:08 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Mon, 25 Jun 2018 13:40:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; 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=fm2; bh=XEhLCI1xjwhKtonid4zaemKYu2brX m+HW62qxNm0wfM=; b=fAIHZQNi/4l6txF0k1MiVAot39bEM5yT1HGoIK/gvhR3l hEv1AteVDCUe5wb3kniPZ8st0k4buJcNyr2fcPQueiQIHxwXsnkYK58vE6C7bIZV CtnyPsNbL31XV0bT7LwdWm8ZX4GI5XtJ1g8kk/w3RreUHY8O7q7HoFobA45EizzL vYSLWPEXChqqSBdZ4zKeMmILJQ2EpnCaNU7+N3sHtuoHg4GftyZ6zAH7LP1AaRAP ig1Vg1zBSwAa4KhpWLDTGnne6dreN6s4po2WOpTeUeRKrlSmMxJzSBFnQGJlDo2I klAqS5KVwCWzvFbMWNNe10WpW/v/xhm1N8pDlc+1Q== 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=XEhLCI 1xjwhKtonid4zaemKYu2brXm+HW62qxNm0wfM=; b=DENyA8+Na73SLT85Lroq4+ KWn6A5lFTJMZ4bOGlpHtMxhbfSYHs9j95qYh/I/vz4TYWud2VIw0KXDP0UulK8Xz uNnxsl/6qxYEGuBiVuyZCrKWxiHuoDxkE8momtvhlZCS2XoHlRdpqJuDnEp0cs56 HtANZ9Kpdk4ADJ6ZbQSNfAebDUvSjkeik50o4+kOqb9Uuq2J2Nb9vpyM7CLTYUmz ZZ3e0GDiXJpIYyj9gIpdhu2BD2I/q9zLDzJyW1NFbWSEoVqQjhQnwBBAFCbKl9A6 iIABHGUlh/zQlnctJ8Vl8+Y2Tr37FGtmLPfKU1pXm5Ekse/lBR4wRJndj0a1Z9gw == X-ME-Proxy: X-ME-Sender: Received: from desktop.local (parsley.growveg.org [82.70.91.97]) by mail.messagingengine.com (Postfix) with ESMTPA id C6D8810262; Mon, 25 Jun 2018 13:40:07 -0400 (EDT) Subject: Re: ino64 To: Warner Losh Cc: FreeBSD Current References: <68667907-4698-c2f0-3d97-bb7f75ff6bbf@zyxst.net> From: tech-lists Organization: none Message-ID: <95bc106f-cd0f-c163-3fc3-7b3d02047eb5@zyxst.net> Date: Mon, 25 Jun 2018 18:40:06 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 25 Jun 2018 17:40:09 -0000 On 25/06/2018 16:37, Warner Losh wrote: > While the compat stuff generally works, there are edge cases where it > will fail when you have a mixed environment. You're best bet is to > reinstall all ports. If you do just a few, you'll hit the edge cases. Hi, What do you mean by "mixed environment"? for context, this is a remote server that runs sshd abd bhyve, and that's it. I expected to have to rebuild everything. I guess portupgrade -af will do it? thanks, -- J. From owner-freebsd-current@freebsd.org Mon Jun 25 18:22: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 524E6101A261 for ; Mon, 25 Jun 2018 18:22:59 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) 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 E00C5883F1 for ; Mon, 25 Jun 2018 18:22:58 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: by mailman.ysv.freebsd.org (Postfix) id A402A101A258; Mon, 25 Jun 2018 18:22:58 +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 8E060101A257 for ; Mon, 25 Jun 2018 18:22:58 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 18172883F0 for ; Mon, 25 Jun 2018 18:22:58 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id w5PIMoaW040778 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 25 Jun 2018 11:22:50 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id w5PIMoSo040777; Mon, 25 Jun 2018 11:22:50 -0700 (PDT) (envelope-from sgk) Date: Mon, 25 Jun 2018 11:22:50 -0700 From: Steve Kargl To: Alexander Leidinger Cc: current@freebsd.org Subject: Re: numa involved in instability and swap usage despite RAM free? Message-ID: <20180625182250.GA40651@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20180624120329.Horde.HWORumQ7Ng1KAUeviJNtoc3@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180624120329.Horde.HWORumQ7Ng1KAUeviJNtoc3@webmail.leidinger.net> User-Agent: Mutt/1.9.2 (2017-12-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 25 Jun 2018 18:22:59 -0000 On Sun, Jun 24, 2018 at 12:03:29PM +0200, Alexander Leidinger wrote: > > I don't have hard evidence, but there is enough "smell" to open up a > discussion... > > Short: > Can it be that enabling numa in the kernel is the reason why some > people see instability with zfs and usage of swap while a lot of free > RAM is available? Interesting observation. I do have NUMA in my kernel, and swap seems to be used instead of recycling freeing inactive memory. Top shows Mem: 506M Active, 27G Inact, 98M Laundry, 2735M Wired, 1474M Buf, 1536M Free Swap: 16G Total, 120M Used, 16G Free Perhaps, I don't understand what is meant by inactive memory. I thought that this means memory is still available in the buffer cache, but nothing is current using what is there. -- Steve From owner-freebsd-current@freebsd.org Mon Jun 25 18:28: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 3387E101A581 for ; Mon, 25 Jun 2018 18:28:32 +0000 (UTC) (envelope-from bdrewery@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 B4058886BF for ; Mon, 25 Jun 2018 18:28:31 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 71460101A57D; Mon, 25 Jun 2018 18:28:31 +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 49A99101A577 for ; Mon, 25 Jun 2018 18:28:31 +0000 (UTC) (envelope-from bdrewery@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 B3C7B886BC; Mon, 25 Jun 2018 18:28:30 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (unknown [127.0.1.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 7A7B118A55; Mon, 25 Jun 2018 18:28:30 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 682409DB6; Mon, 25 Jun 2018 18:28:29 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id myX0EHL3B16S; Mon, 25 Jun 2018 18:28:27 +0000 (UTC) Subject: Re: error building clang in HEAD DKIM-Filter: OpenDKIM Filter v2.10.3 mail.xzibition.com C7CA19D9B To: gljennjohn@gmail.com, Dimitry Andric Cc: current@freebsd.org References: <20180623154048.1b228df0@ernst.home> <196E84B3-B58F-4296-B6EA-84D0DE3230EF@FreeBSD.org> <20180624095747.7384f5bf@ernst.home> From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Autocrypt: addr=bdrewery@FreeBSD.org; prefer-encrypt=mutual; keydata= xsBNBFJphmsBCADiFgmS4bIzwZijrS31SjEMzg+n5zNellgM+HkShwehpqCiyhXdWrvH6dTZ a6u50pbUIX7doTR7W7PQHCjCTqtpwvcj0eulZva+iHFp+XrbgSFHn+VVXgkYP2MFySyZRFab D2qqzJBEJofhpv4HvY6uQI5K99pMqKr1Z/lHqsijYYu4RH2OfwB5PinId7xeldzWEonVoCr+ rfxzO/UrgA6v/3layGZcKNHFjmc3NqoN1DXtdaEHqtjIozzbndVkH6lkFvIpIrI6i5ox8pwp VxsxLCr/4Musd5CWgHiet5kSw2SzNeA8FbxdLYCpXNVu+uBACEbCUP+CSNy3NVfEUxsBABEB AAHNJEJyeWFuIERyZXdlcnkgPGJkcmV3ZXJ5QEZyZWVCU0Qub3JnPsLAgAQTAQoAKgIbAwUL CQgHAwUVCgkICwUWAwIBAAIeAQIXgAIZAQUCWujOIgUJCmB7NwAKCRA113G7bkaXz/xpB/9b /UWIPbieY1IeIuHF2pyYPE7Hytkh3HVsxMA0F5Ma2AYQsXZZeKNKWrF7RPyDyDwUklLHJkhm k3EfClBbHxf08kMIm1vWCJRtgxic9knY/bzYGiWMpHjg3cSd1XfrYH1autYqTZAjDwIkgOjU dR//Tbn4V36sY7y2jz+kdMVWvK53U32aZqiwBbCn4DPe1wSZcUs17mV/0uZdIoGdj74B1orN A/0py5vHYo6HcbBNoaR8pKRLf5VZNRsxqGIMhTucx4SJWcHpuRBWYyvJSFzwvxdK4ZD4Yqoc kFGPVtOXktVMai9exrLvP3G77fKMu8DI6j4QRU4wCesnHuIfRPFuzsBNBFJphmsBCACiVFPf kNfaFtUSuY0395ueo/rMyHPGPQ2iwvERFCpeFGSQSgagpenNHLpFQKTg/dl6FOoST5tqyxMq fyHGHDzzU51bvA/IfaGoNi/BIhTe/toZNMRvpcI3PLjiGcnJnuwCCbAVOAGdb+t5cZtpNdOI cKYmrYG3u9RiBpe6dTF+qLrD/8Bs1wjhduQ8fcNNgnkXu8xDH4ZxY0lIc3QgvYWp9vimlQe6 iKjUd2/DX28ETZcD5h6pYV331KMPTrEI0p0yvFijUZce8c1XHFyL1j9sBAha5qpszJl6Uq5i LolhKRcGfcdmtD72vHQjUYglUyudSJUVyo2gMYjdbiFKzJulABEBAAHCwGUEGAEKAA8CGwwF AlrozigFCQpgez0ACgkQNddxu25Gl8+m5Af/R3VEdxNMAcDIes9ADhQyofj20SPV3eCJ3HYR OebTSuNdOudGt4AAyA8Ks94u9hiIp5IGsc6RDsT9W7O2vgXhd6eV3eiY5Oif5xLIYrIDVu1Y 1GyRxRrPEn/QOqDN6uFZCPwK1aOapGcYCrO9lB0gMuTVfgHanU61rgC9tMX0OoAOyRd+V3/M 8lDNhjJdF/IpO3SdYzKfkwduy4qamw4Gphcx/RfYQvYLq/eDkP8d50PphWdboqWBwNRHayro W/07OGzfxM5fJ5mBsXPQcO2QcRjkyHf6xCM6Hi1qQL4OnXMNE/ZTX0lnOj1/pH93TlzSHZMP TaiiA/MBD3vGsXBmBg== Organization: FreeBSD Message-ID: Date: Mon, 25 Jun 2018 11:28:18 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180624095747.7384f5bf@ernst.home> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="u8haGejsYgX11Yd2agzfeg389C3VaUjSH" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 25 Jun 2018 18:28:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --u8haGejsYgX11Yd2agzfeg389C3VaUjSH Content-Type: multipart/mixed; boundary="8ZePhTlcODSAlICFcfxdVUjAbWEkAMysI"; protected-headers="v1" From: Bryan Drewery To: gljennjohn@gmail.com, Dimitry Andric Cc: current@freebsd.org Message-ID: Subject: Re: error building clang in HEAD References: <20180623154048.1b228df0@ernst.home> <196E84B3-B58F-4296-B6EA-84D0DE3230EF@FreeBSD.org> <20180624095747.7384f5bf@ernst.home> In-Reply-To: <20180624095747.7384f5bf@ernst.home> --8ZePhTlcODSAlICFcfxdVUjAbWEkAMysI Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 6/24/2018 12:57 AM, Gary Jennejohn wrote: > On Sat, 23 Jun 2018 17:05:16 +0200 > Dimitry Andric wrote: >=20 >> On 23 Jun 2018, at 15:40, Gary Jennejohn wrote:= >>> >>> There is a strange error building clang with this use case: >>> >>> cd /usr/src >>> make -j10 makeworld =20 >> >> What's the "makeworld" target? I've not heard of this. >> >=20 > A typo. I meant buildowrld. >=20 >>> which produces this error output: >>> =20 >>> =3D=3D=3D> lib/clang/libclang (all) =20 >>> error: unable to rename temporary 'Sema/SemaTemplate-12ad7e30.o.tmp' = to output file 'Sema/SemaTemplate.o': 'No such file or directory' >>> 1 error generated. >>> --- Sema/SemaTemplate.o --- >>> *** [Sema/SemaTemplate.o] Error code 1 =20 >> >> This typically happens if "make obj" was not run before the rest of th= e >> make targets. Normally, the order is: make obj, then make depend, the= n >> make (a.k.a. make all). >> >> Is there a directory /usr/obj/usr/src/lib/libclang/Sema ? >> >=20 > Well, I would hope/expect that make buildworld does make obj. >=20 > Yes, the directory was there. >=20 Actually neither 'make obj' nor 'make depend' is done or needed anymore in buildworld. The directory above is incorrect, please check for /usr/obj/usr/src/amd64.amd64/lib/clang/libclang/Sema Do you have another Makefile or script that is executing buildworld for y= ou? What's in your src.conf and make.conf? --=20 Regards, Bryan Drewery --8ZePhTlcODSAlICFcfxdVUjAbWEkAMysI-- --u8haGejsYgX11Yd2agzfeg389C3VaUjSH 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 iQEcBAEBAgAGBQJbMTRKAAoJEDXXcbtuRpfP130H/AnBKnQMKnArnS5hMZ6e6Roy 4KOI+KnbA0774lFoLor6W9KdzJVbIAfxqQUAVUPQC+muWchgiPBvhPNfiNoOhk6z tcMTCLBI+zV60LCciaJECopSVqaro/sIAd/cAuJqclJkunj+jclRasObFJdJtOS3 hgJbf6z9HSu2PYIthMXFEXWAy7Eqqpo087xOtHenUu222oFa2/xZvnfr1bRDs0CC JcfzEB2vSMhXyW3cbqvu1Aba+j6HvvJUn6J0CCVS8N2Z09Hysz6qip3uLs0VrKgo SjgCSeKgh7BtIfHGMLQ71fEHoW0z6+jap5UQ9xD4Djxdh/8co2Kr97hIVP11cAs= =17Kn -----END PGP SIGNATURE----- --u8haGejsYgX11Yd2agzfeg389C3VaUjSH-- From owner-freebsd-current@freebsd.org Mon Jun 25 18:52:42 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 6E523101B1BE for ; Mon, 25 Jun 2018 18:52:42 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F38B489490 for ; Mon, 25 Jun 2018 18:52:41 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x229.google.com with SMTP id m194-v6so13976173itg.2 for ; Mon, 25 Jun 2018 11:52:41 -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=2jQSr4l08Ckh396n9R1+hHc8mkzS8GY8E+HpaIXIG7w=; b=zzVPpWD6hLWeALA4ofA6wwxe+XPL83Eko3tuq+aT9sCsy85WIY4GjOh/5sZMXhD/49 0UtZmoL3ZtupdxBDIUOuUCvqsS39hePJwZjYu0PUNGEb6IwGnXlOPwmmyvLjO629K4fP uXvhCqewMypMRWqQqsJvq3xYoVx3AHTv35oY3LERXn6CJK4iHE1cLdyRvvEDIhzcnph6 3HsGuDX4JrRY8eGAC6/nuMXUZwwxTN1lA4CcNr/r0+uKYmD5O/ABQkxU806zUrA/sJhS 2OzkCT2855gwvAS1FO+Sxi+BS6eKaFoqk5D7A2xfVQ14lF5bq5NTo/X1XNt+zn46WQEk Yqig== 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=2jQSr4l08Ckh396n9R1+hHc8mkzS8GY8E+HpaIXIG7w=; b=AbIoQvw3cQA8RvmNFlMKexZCLaf6N+LioVaI10oTEuNYWETCH8IAVgu+eSoc/soAt7 QqL/1FDcbnh+igjzbvKttG+oJQGPSAZfYSG8Kl2xYe/+SFCNCyB2yXG/rYes1I+b/o87 +8SkAmn/FO7ldfeToxLV0WwsMAfXeHlYDhRQsrz2RgZNTazxy7dY0ApaZiSMnvYW0QMr LKHzGeit6c8aQhO1QLOBSUcP9as7+WSIeBMQF+37wkD9VEz9lw6VKe/6J5Gwy+E8R+3u nPFw7ufLSvr9Su5YgXrKbLNbNfXGj+Qzbz3JOZ4xwYwTwW0rBsbqjakXrAzSArfyzvKa H9rA== X-Gm-Message-State: APt69E2S41E+PRjmhczyOdnc7xOzBgRy4WIWtDTCQzV138phH71mlxQ5 BxTTvSayIwjqdsd6wci4w637coU1l6rtAKl4Cggkbg== X-Google-Smtp-Source: ADUXVKIpOqrma9uOWcvuPoAQLhIz6PBjttQ8oISsGWr8q8BuQEGaaPxgj7M2WI1sb5WMNbGryexBef6TD4XFzNoGuds= X-Received: by 2002:a24:7c8d:: with SMTP id a135-v6mr1896493itd.73.1529952761330; Mon, 25 Jun 2018 11:52:41 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:5945:0:0:0:0:0 with HTTP; Mon, 25 Jun 2018 11:52:40 -0700 (PDT) X-Originating-IP: [50.227.106.226] In-Reply-To: <95bc106f-cd0f-c163-3fc3-7b3d02047eb5@zyxst.net> References: <68667907-4698-c2f0-3d97-bb7f75ff6bbf@zyxst.net> <95bc106f-cd0f-c163-3fc3-7b3d02047eb5@zyxst.net> From: Warner Losh Date: Mon, 25 Jun 2018 12:52:40 -0600 X-Google-Sender-Auth: 5EtNxx3lSHH4b3VxmYuNqDdsNLw Message-ID: Subject: Re: ino64 To: tech-lists Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 25 Jun 2018 18:52:42 -0000 On Mon, Jun 25, 2018 at 11:40 AM, tech-lists wrote: > On 25/06/2018 16:37, Warner Losh wrote: > >> While the compat stuff generally works, there are edge cases where it >> will fail when you have a mixed environment. You're best bet is to >> reinstall all ports. If you do just a few, you'll hit the edge cases. >> > > Hi, > > What do you mean by "mixed environment"? for context, this is a remote > server that runs sshd abd bhyve, and that's it. > A mixed environment would be a mix of old and new packages. > I expected to have to rebuild everything. I guess portupgrade -af will do > it? > I believe so. That will avoid all issues I'm aware of. Warner From owner-freebsd-current@freebsd.org Mon Jun 25 20:56: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 AC712101F228 for ; Mon, 25 Jun 2018 20:56:26 +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 1C4748D8BF; Mon, 25 Jun 2018 20:56:25 +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 ESMTP id w5PKuFPO020741; Mon, 25 Jun 2018 23:56:18 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w5PKuFPO020741 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w5PKuEqX020740; Mon, 25 Jun 2018 23:56:14 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 25 Jun 2018 23:56:14 +0300 From: Konstantin Belousov To: Rick Macklem Cc: "freebsd-current@freebsd.org" , Alexander Motin , Doug Rabson Subject: Re: nfsd kernel threads won't die via SIGKILL Message-ID: <20180625205614.GI2430@kib.kiev.ua> References: <20180624093330.GX2430@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.0 (2018-05-17) 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.26 Precedence: 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, 25 Jun 2018 20:56:26 -0000 On Mon, Jun 25, 2018 at 02:04:32AM +0000, Rick Macklem wrote: > Konstantin Belousov wrote: > >On Sat, Jun 23, 2018 at 09:03:02PM +0000, Rick Macklem wrote: > >> During testing of the pNFS server I have been frequently killing/restarting the nfsd. > >> Once in a while, the "slave" nfsd process doesn't terminate and a "ps axHl" shows: > >> 0 48889 1 0 20 0 5884 812 svcexit D - 0:00.01 nfsd: server > >> 0 48889 1 0 40 0 5884 812 rpcsvc I - 0:00.00 nfsd: server > >> ... more of the same > >> 0 48889 1 0 40 0 5884 812 rpcsvc I - 0:00.00 nfsd: server > >> 0 48889 1 0 -8 0 5884 812 rpcsvc I - 1:51.78 nfsd: server > >> 0 48889 1 0 -8 0 5884 812 rpcsvc I - 2:27.75 nfsd: server > >> > >> You can see that the top thread (the one that was created with the process) is > >> stuck in "D" on "svcexit". > >> The rest of the threads are still servicing NFS RPCs. If you still have an NFS mount >>on > >> the server, the mount continues to work and the CPU time for the last two threads > >> slowly climbs, due to NFS RPC activity. A SIGKILL was posted for the process and > >> these threads (created by kthread_add) are here, but the > >> cv_wait_sig/cv_timedwait_sig never seems to return EINTR for these other >>threads. > >> > >> if (ismaster || (!ismaster && > >> 1207 grp->sg_threadcount > grp->sg_minthreads)) > >> 1208 error = cv_timedwait_sig(&st->st_cond, > >> 1209 &grp->sg_lock, 5 * hz); > >> 1210 else > >> 1211 error = cv_wait_sig(&st->st_cond, > >> 1212 &grp->sg_lock); > >> > >> The top thread (referred to in svc.c as "ismaster" did return from here with EINTR > >> and has now done an msleep() here, waiting for the other threads to terminate. > >> > >> /* Waiting for threads to stop. */ > >> 1387 for (g = 0; g < pool->sp_groupcount; g++) { > >> 1388 grp = &pool->sp_groups[g]; > >> 1389 mtx_lock(&grp->sg_lock); > >> 1390 while (grp->sg_threadcount > 0) > >> 1391 msleep(grp, &grp->sg_lock, 0, "svcexit", 0); > >> 1392 mtx_unlock(&grp->sg_lock); > >> 1393 } > >> > >> Although I can't be sure if this patch has fixed the problem because it happens > >> intermittently, I have not seen the problem since applying this patch: > >> --- rpc/svc.c.sav 2018-06-21 22:52:11.623955000 -0400 > >> +++ rpc/svc.c 2018-06-22 09:01:40.271803000 -0400 > >> @@ -1388,7 +1388,7 @@ svc_run(SVCPOOL *pool) > >> grp = &pool->sp_groups[g]; > >> mtx_lock(&grp->sg_lock); > >> while (grp->sg_threadcount > 0) > >> - msleep(grp, &grp->sg_lock, 0, "svcexit", 0); > >> + msleep(grp, &grp->sg_lock, 0, "svcexit", 1); > >> mtx_unlock(&grp->sg_lock); > >> } > >> } > >> > >> As you can see, all it does is add a timeout to the msleep(). > >> I am not familiar with the signal delivery code in sleepqeue, so it probably > >> isn't correct, but my theory is alonge the lines of... > >> > >> Since the msleep() doesn't have PCATCH, it does not set TDF_SINTR > >> and if that happens before the other threads return EINTR from cv_wait_sig(), > >> they no longer do so? > >> And I thought that waking up from the msleep() via timeouts would maybe allow > >> the other threads to return EINTR from cv_wait_sig()? > >> > >> Does this make sense? rick > >> ps: I'll post if I see the problem again with the patch applied. > >> pss: This is a single core i386 system, just in case that might affect this. > > > >No, the patch does not make sense. I think it was just coincidental that > >with the patch you did not get the hang. > > > >Signals are delivered to a thread, which should take the appropriate > >actions. For the kernel process like rpc pool, the signals are never > >delivered, they are queued in the randomly selected thread' signal queue > >and sit there. The interruptible sleeps are aborted in the context > >of that thread, but nothing else happens. So if you need to make svc > >pools properly killable, all threads must check at least for EINTR and > >instruct other threads to exit as well. > I'm not sure I understand what the "randomly selected thread signal > queue" means, but it seems strange that this usually works. (The code > is at least 10years old. Originally committed by dfr@. I've added him > to the cc list in case he understands this? Is it that, usually, the > threads will all return EINTR before the master one gets to where the > msleep() happens if the count is > 0? Signals are put onto a signal queue between a time where the signal is generated until the thread actually consumes it. I.e. the signal queue is a container for the signals which are not yet acted upon. There is one signal queue per process, and one signal queue for each thread belonging to the process. When you signal the process, the signal is put into some thread' signal queue, where the only criteria for the selection of the thread is that the signal is not blocked. Since SIGKILL is never blocked, it is put anywhere. Until signal is delivered by cursig()/postsig() loop, typically at the AST handler, the only consequence of its presence are the EINTR/ERESTART errors returned from the PCATCH-enabled sleeps. > > >Your description at the start of the message of the behaviour after > >SIGKILL, where other threads continued to serve RPCs, exactly matches > >above explanation. You need to add some global 'stop' flag, if it is not > >yet present, and recheck it after each RPC handled. Any thread which > >notes EINTR or does a direct check for the pending signal, should set > >the flag and wake up every other thread in the pool. > Ok, I'll code up a patch with a global "stop" flag and test it for a while. > If it seems ok, I'll put it up in phabricator and ask you to review it. > > Thanks, rick From owner-freebsd-current@freebsd.org Mon Jun 25 21:08: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 20BDB101FAC3; Mon, 25 Jun 2018 21:08:24 +0000 (UTC) (envelope-from dch@skunkwerks.at) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (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 C0C528E10B; Mon, 25 Jun 2018 21:08:23 +0000 (UTC) (envelope-from dch@skunkwerks.at) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 0E19821C7B; Mon, 25 Jun 2018 17:08:23 -0400 (EDT) Received: from web6 ([10.202.2.216]) by compute7.internal (MEProxy); Mon, 25 Jun 2018 17:08:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skunkwerks.at; h=content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=wdyxopV2/yPDqGpnLKk8UEs7FJ/WIdEWC5iaAuLC1v0=; b=ohLGEkrZ 5oJAZWyUXzD01TRi8PiB0EoxsC0XXpJadRQN5T7vM0tdUT5fizR49tqPwOBJ13As X6Dt+AjWbBh3mdd9sDv0VbvK9dEe6QD95nGc+joDtB7Kkj4+uAafwsAs8Fp1/0ap kpOu036hYiqMqZckzATsLOcByzidgLJpA05Ovb1rnalRNvop+ZkcV8Q24sb1HFn0 xG6Opfk7LufMTPXOBtB4xi81BvKWP2jN9mMn1nwu4om0ymPnqq0ffME1/z0gYpei uo9pPILUFE9+Gm+IVSUC7ilQxqpn4p/igvy2ECKkX3WZ8RDq2S5gxuY4OJu7MRgO VbryTAnCsIBETA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=wdyxopV2/yPDqGpnLKk8UEs7FJ/WI dEWC5iaAuLC1v0=; b=fO3P12+qaBS4GHP6yB3VNSSuvD/887JWUWZRs3tIT5WvG byfBUIimRnSzjIEAUwZb/d/1GC22QwFLUMoPYxCDcd1wGPBFX0V9C8Fa5ApRvFlA Z4fUE6p/hwChweekk227oo/1uyJR0VGpUDG67svq9g1kJIt+JWdVhLlOaPIjx5TK sYLxOm3DJbKX4llE8hkB6CUzntLG7r2s3l5uGT1Jpy6uYgXQUrwvj/NYQjRCw8Oa bzrx30Eqj+r92MPqbHnuuuVTIStip0G99cEvTow4v7rZSetai+jJQuki1Uj4xhe6 L+ph/JwExhhyBugZENnIvPuN7hkXMNokkIF9Vukhw== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id A37984136; Mon, 25 Jun 2018 17:08:22 -0400 (EDT) Message-Id: <1529960902.613046.1420067144.3B445531@webmail.messagingengine.com> From: Dave Cottlehuber To: freebsd-current@freebsd.org, freebsd-net@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-0d8ea36c Date: Mon, 25 Jun 2018 23:08:22 +0200 Subject: unloading pf causes desktop system to freeze since ~ r335381 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 25 Jun 2018 21:08:24 -0000 [cross-posting for advice on general debugging + network-specific thoughts] TLDR since a week or so, probably around r335381 I can reliably get my machine to hang*** by unloading pf, while there's network traffic (e.g. video streaming or rsync) and waiting a minute or two I still see it with r335576 a few times today. config & logs below, h/w is intel xeon v2667v4 on supermicro X10SRA-F dual igb nics. However each time there's no crashdump, & the usual ctrl-alt-esc does't work either. I'm a bit lost as to what I can do here to capture something useful. A few minutes later, the machine spontaneously reboots, I assume due to a h/w watchdog kicking up, and there is no crashdump info present in /var/crash/ as I'd normally expect. ***hang means simultaneously: - keyboard is unresponsive (capslock/numlock keys don't cause keyboard LEDs to toggle state) - control-alt-esc doesn't work to get to the debugger - music playing via mpd to an external USB DAC stops - network sessions & tap interfaces fail - X session contents freeze but remain visible Is there some way I can get a kernel dump even though the system has fully hung? - dmesg, rc.conf, ifconfig, sysctls etc https://git.io/f4HQZ - supermicro X10SRA-F bios v2.0a settings https://git.io/f4HQb A+ Dave From owner-freebsd-current@freebsd.org Tue Jun 26 02:08: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 AC7BD1001C79 for ; Tue, 26 Jun 2018 02:08:41 +0000 (UTC) (envelope-from kiri@kx.openedu.org) Received: from kx.openedu.org (flets-sg1027.kamome.or.jp [202.216.24.27]) (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 F0926784CF; Tue, 26 Jun 2018 02:08:40 +0000 (UTC) (envelope-from kiri@kx.openedu.org) Received: from kx.openedu.org (kx.openedu.org [202.216.24.27]) by kx.openedu.org (8.14.5/8.14.5) with ESMTP id w5Q28Una093666; Tue, 26 Jun 2018 11:08:31 +0900 (JST) (envelope-from kiri@kx.openedu.org) Message-Id: <201806260208.w5Q28Una093666@kx.openedu.org> Date: Tue, 26 Jun 2018 11:08:30 +0900 From: KIRIYAMA Kazuhiko To: Toomas Soome Cc: KIRIYAMA Kazuhiko , Allan Jude , freebsd-current@freebsd.org Subject: Re: ZFS: I/O error - blocks larger than 16777216 are not supported In-Reply-To: <1CDD5AFE-F115-406C-AB92-9DC58B57E1D5@me.com> References: <201806210136.w5L1a5Nv074194@kx.openedu.org> <21493592-4eb2-59c5-1b0d-e1d08217a96b@freebsd.org> <201806210600.w5L60mYn079435@kx.openedu.org> <1CDD5AFE-F115-406C-AB92-9DC58B57E1D5@me.com> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.6 MULE XEmacs/21.4 (patch 22) (Instant Classic) (amd64--freebsd) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=X-UNKNOWN Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 26 Jun 2018 02:08:41 -0000 At Thu, 21 Jun 2018 10:48:28 +0300, Toomas Soome wrote: >=20 >=20 >=20 > > On 21 Jun 2018, at 09:00, KIRIYAMA Kazuhiko wrote: > >=20 > > At Wed, 20 Jun 2018 23:34:48 -0400, > > Allan Jude wrote: > >>=20 > >> On 2018-06-20 21:36, KIRIYAMA Kazuhiko wrote: > >>> Hi all, > >>>=20 > >>> I've been reported ZFS boot disable problem [1], and found > >>> that this issue occers form RAID configuration [2]. So I > >>> rebuit with RAID5 and re-installed 12.0-CURRENT > >>> (r333982). But failed to boot with: > >>>=20 > >>> ZFS: i/o error - all block copies unavailable > >>> ZFS: can't read MOS of pool zroot > >>> gptzfsboot: failed to mount default pool zroot > >>>=20 > >>> FreeBSD/x86 boot > >>> ZFS: I/O error - blocks larger than 16777216 are not supported > >>> ZFS: can't find dataset u > >>> Default: zroot/<0x0>: > >>>=20 > >>> In this case, the reason is "blocks larger than 16777216 are > >>> not supported" and I guess this means datasets that have > >>> recordsize greater than 8GB is NOT supported by the > >>> FreeBSD boot loader(zpool-features(7)). Is that true ? > >>>=20 > >>> My zpool featues are as follows: > >>>=20 > >>> # kldload zfs > >>> # zpool import=20 > >>> pool: zroot > >>> id: 13407092850382881815 > >>> state: ONLINE > >>> status: The pool was last accessed by another system. > >>> action: The pool can be imported using its name or numeric identifier= and > >>> the '-f' flag. > >>> see: http://illumos.org/msg/ZFS-8000-EY > >>> config: > >>>=20 > >>> zroot ONLINE > >>> mfid0p3 ONLINE > >>> # zpool import -fR /mnt zroot > >>> # zpool list > >>> NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH AL= TROOT > >>> zroot 19.9T 129G 19.7T - 0% 0% 1.00x ONLINE /m= nt > >>> # zpool get all zroot > >>> NAME PROPERTY VALUE = SOURCE > >>> zroot size 19.9T = - > >>> zroot capacity 0% = - > >>> zroot altroot /mnt = local > >>> zroot health ONLINE = - > >>> zroot guid 13407092850382881815= default > >>> zroot version - = default > >>> zroot bootfs zroot/ROOT/default = local > >>> zroot delegation on = default > >>> zroot autoreplace off = default > >>> zroot cachefile none = local > >>> zroot failmode wait = default > >>> zroot listsnapshots off = default > >>> zroot autoexpand off = default > >>> zroot dedupditto 0 = default > >>> zroot dedupratio 1.00x = - > >>> zroot free 19.7T = - > >>> zroot allocated 129G = - > >>> zroot readonly off = - > >>> zroot comment - = default > >>> zroot expandsize - = - > >>> zroot freeing 0 = default > >>> zroot fragmentation 0% = - > >>> zroot leaked 0 = default > >>> zroot feature@async_destroy enabled = local > >>> zroot feature@empty_bpobj active = local > >>> zroot feature@lz4_compress active = local > >>> zroot feature@multi_vdev_crash_dump enabled = local > >>> zroot feature@spacemap_histogram active = local > >>> zroot feature@enabled_txg active = local > >>> zroot feature@hole_birth active = local > >>> zroot feature@extensible_dataset enabled = local > >>> zroot feature@embedded_data active = local > >>> zroot feature@bookmarks enabled = local > >>> zroot feature@filesystem_limits enabled = local > >>> zroot feature@large_blocks enabled = local > >>> zroot feature@sha512 enabled = local > >>> zroot feature@skein enabled = local > >>> zroot unsupported@com.delphix:device_removal inactive = local > >>> zroot unsupported@com.delphix:obsolete_counts inactive = local > >>> zroot unsupported@com.delphix:zpool_checkpoint inactive = local > >>> #=20 > >>>=20 > >>> Regards > >>>=20 > >>> [1] https://lists.freebsd.org/pipermail/freebsd-current/2018-March/06= 8886.html > >>> [2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D151910 > >>>=20 > >>> --- > >>> KIRIYAMA Kazuhiko > >>> _______________________________________________ > >>> 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 > >> I am guessing it means something is corrupt, as 16MB is the maximum si= ze > >> of a record in ZFS. Also, the 'large_blocks' feature is 'enabled', not > >> 'active', so this suggest you do not have any records larger than 128kb > >> on your pool. > >=20 > > As I mentioned above, [2] says ZFS on RAID disks have any > > serious bugs except for mirror. Anyway I gave up to use ZFS > > on RAID{5,6}* until Bug 151910 [2] fixed. > >=20 >=20 > if you boot from usb stick (or cd), press esc at boot loader menu and ent= er lsdev -v. what sector and disk sizes are reported? OK lsdev -v disk devices: disk0: BIOS drive C (31588352 X 512) disk0p1: FreeBSD boot 512KB disk0p2: FreeBSD UFS 13GB disk0p3: FreeBSD swap 771MB disk1: BIOS drive D (4294967295 X 512) disk0p1: FreeBSD boot 512KB disk0p2: FreeBSD swap 128GB disk0p3: FreeBSD ZFS 19TB OK Does this means whole disk size that I can use is 2TB (4294967295 X 512) ?=20 >=20 > the issue [2] is mix of ancient freebsd (v 8.1 is mentioned there), and R= AID luns with 512B sector size and 15TB!!! total size - are you really sure= your BIOS can actually address 15TB lun (with 512B sector size)? Note that= the problem with large disks can hide itself till you have pool filled up = enough till the essential files will be stored above the limit~ meaning th= at you may have ~perfectly working~ setup till at some point in time, after= next update, it is suddenly not working any more. >=20 I see why I could use for a while. > Note that for boot loader we have only INT13h for BIOS version, and it re= ally is limited. The UEFI version is using EFI_BLOCK_IO API, which usually = can handle large sectors and disk sizes better. I re-installed the machine with UEFI boot: # gpart show mfid0 =3D> 40 42965401520 mfid0 GPT (20T) 40 409600 1 efi (200M) 409640 2008 - free - (1.0M) 411648 268435456 2 freebsd-swap (128G) 268847104 42696552448 3 freebsd-zfs (20T) 42965399552 2008 - free - (1.0M) # uname -a FreeBSD vm.openedu.org 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r335317: Mon Ju= n 18 16:21:17 UTC 2018 root@releng3.nyi.freebsd.org:/usr/obj/usr/src/am= d64.amd64/sys/GENERIC amd64 # zpool get all zroot NAME PROPERTY VALUE SOURCE zroot size 19.9T - zroot capacity 0% - zroot altroot - default zroot health ONLINE - zroot guid 11079446129259852576 default zroot version - default zroot bootfs zroot/ROOT/default local zroot delegation on default zroot autoreplace off default zroot cachefile - default zroot failmode wait default zroot listsnapshots off default zroot autoexpand off default zroot dedupditto 0 default zroot dedupratio 1.00x - zroot free 19.9T - zroot allocated 1.67G - zroot readonly off - zroot comment - default zroot expandsize - - zroot freeing 0 default zroot fragmentation 0% - zroot leaked 0 default zroot bootsize - default zroot checkpoint - - zroot feature@async_destroy enabled local zroot feature@empty_bpobj active local zroot feature@lz4_compress active local zroot feature@multi_vdev_crash_dump enabled local zroot feature@spacemap_histogram active local zroot feature@enabled_txg active local zroot feature@hole_birth active local zroot feature@extensible_dataset enabled local zroot feature@embedded_data active local zroot feature@bookmarks enabled local zroot feature@filesystem_limits enabled local zroot feature@large_blocks enabled local zroot feature@sha512 enabled local zroot feature@skein enabled local zroot feature@device_removal enabled local zroot feature@obsolete_counts enabled local zroot feature@zpool_checkpoint enabled local #=20 and checked 'lsdev -v' at loader prompt: OK lsdev -v PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/VenHw(CF31FAC5-C24E-11D2-85F3-00A0= C93EC93B,80) disk0: 4294967295 X 512 blocks disk0p1: EFI 200MB disk0p2: FreeBSD swap 128GB disk0p2: FreeBSD ZFS 19TB net devices: zfs devices: pool: zroot bootfs: zroot/ROOT/default config: NAME STATE zroot ONLINE mfid0p3 ONLINE OK but disk size (4294967295 X 512) still not changed or this means 4294967295 X 512 X 512 bytes ? >=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" Regards --- KIRIYAMA Kazuhiko From owner-freebsd-current@freebsd.org Tue Jun 26 06:48: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 18F4E10148AB for ; Tue, 26 Jun 2018 06:48:11 +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 9CC81828E9; Tue, 26 Jun 2018 06:48:10 +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 <0PAX000003L7JO00@st13p35im-asmtp002.me.com>; Tue, 26 Jun 2018 06:48:04 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=04042017; t=1529995684; bh=7uMPTQUbR2Ti/7B3a2ToCEap+Cqul1ZTKugJ5fFwUUg=; h=From:Message-id:Content-type:MIME-version:Subject:Date:To; b=3X30Os9hW5/h59xpNSb9JwJrMXe8tuFUA90Pjscx+5e309KV0HcLo2GdwerRDEcl2 SnGvbjs9NwcaZBTb47dIPATZD5hOy31oHDoyRxmcSV6P0Mdo1pqGTB+3rvgJNNLbPx XeZzhhO+UxeWjn6wOfICZZzmI3XGQdggyfUD8nKsgUjAOlje0BUDLkcSd4x7SGiyK0 qKOefg7k5kVnIvezW2+znj1HgZAdv1KVk2DcfOYRwx9mDcZCFyWvOJL5biwWgBVwBk 3zY8SMBnvqiWg6YwsQQPousYMZKgeqPRDtZrqg9Efx07e4wcefYYbFKRUNjzmTlV/8 9w3RAv4zG//sg== 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 <0PAX005W247S1K40@st13p35im-asmtp002.me.com>; Tue, 26 Jun 2018 06:48:02 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-06-26_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-1806260077 From: Toomas Soome Message-id: <63C1AB52-1A4B-430E-9D88-6406107785BA@me.com> MIME-version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: ZFS: I/O error - blocks larger than 16777216 are not supported Date: Tue, 26 Jun 2018 09:48:10 +0300 In-reply-to: <201806260208.w5Q28Una093666@kx.openedu.org> Cc: Allan Jude , freebsd-current@freebsd.org To: KIRIYAMA Kazuhiko References: <201806210136.w5L1a5Nv074194@kx.openedu.org> <21493592-4eb2-59c5-1b0d-e1d08217a96b@freebsd.org> <201806210600.w5L60mYn079435@kx.openedu.org> <1CDD5AFE-F115-406C-AB92-9DC58B57E1D5@me.com> <201806260208.w5Q28Una093666@kx.openedu.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.26 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 26 Jun 2018 06:48:12 -0000 > On 26 Jun 2018, at 05:08, KIRIYAMA Kazuhiko = wrote: >=20 > At Thu, 21 Jun 2018 10:48:28 +0300, > Toomas Soome wrote: >>=20 >>=20 >>=20 >>> On 21 Jun 2018, at 09:00, KIRIYAMA Kazuhiko = wrote: >>>=20 >>> At Wed, 20 Jun 2018 23:34:48 -0400, >>> Allan Jude wrote: >>>>=20 >>>> On 2018-06-20 21:36, KIRIYAMA Kazuhiko wrote: >>>>> Hi all, >>>>>=20 >>>>> I've been reported ZFS boot disable problem [1], and found >>>>> that this issue occers form RAID configuration [2]. So I >>>>> rebuit with RAID5 and re-installed 12.0-CURRENT >>>>> (r333982). But failed to boot with: >>>>>=20 >>>>> ZFS: i/o error - all block copies unavailable >>>>> ZFS: can't read MOS of pool zroot >>>>> gptzfsboot: failed to mount default pool zroot >>>>>=20 >>>>> FreeBSD/x86 boot >>>>> ZFS: I/O error - blocks larger than 16777216 are not supported >>>>> ZFS: can't find dataset u >>>>> Default: zroot/<0x0>: >>>>>=20 >>>>> In this case, the reason is "blocks larger than 16777216 are >>>>> not supported" and I guess this means datasets that have >>>>> recordsize greater than 8GB is NOT supported by the >>>>> FreeBSD boot loader(zpool-features(7)). Is that true ? >>>>>=20 >>>>> My zpool featues are as follows: >>>>>=20 >>>>> # kldload zfs >>>>> # zpool import=20 >>>>> pool: zroot >>>>> id: 13407092850382881815 >>>>> state: ONLINE >>>>> status: The pool was last accessed by another system. >>>>> action: The pool can be imported using its name or numeric = identifier and >>>>> the '-f' flag. >>>>> see: http://illumos.org/msg/ZFS-8000-EY >>>>> config: >>>>>=20 >>>>> zroot ONLINE >>>>> mfid0p3 ONLINE >>>>> # zpool import -fR /mnt zroot >>>>> # zpool list >>>>> NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH = ALTROOT >>>>> zroot 19.9T 129G 19.7T - 0% 0% 1.00x ONLINE = /mnt >>>>> # zpool get all zroot >>>>> NAME PROPERTY VALUE = SOURCE >>>>> zroot size 19.9T = - >>>>> zroot capacity 0% = - >>>>> zroot altroot /mnt = local >>>>> zroot health ONLINE = - >>>>> zroot guid = 13407092850382881815 default >>>>> zroot version - = default >>>>> zroot bootfs = zroot/ROOT/default local >>>>> zroot delegation on = default >>>>> zroot autoreplace off = default >>>>> zroot cachefile none = local >>>>> zroot failmode wait = default >>>>> zroot listsnapshots off = default >>>>> zroot autoexpand off = default >>>>> zroot dedupditto 0 = default >>>>> zroot dedupratio 1.00x = - >>>>> zroot free 19.7T = - >>>>> zroot allocated 129G = - >>>>> zroot readonly off = - >>>>> zroot comment - = default >>>>> zroot expandsize - = - >>>>> zroot freeing 0 = default >>>>> zroot fragmentation 0% = - >>>>> zroot leaked 0 = default >>>>> zroot feature@async_destroy enabled = local >>>>> zroot feature@empty_bpobj active = local >>>>> zroot feature@lz4_compress active = local >>>>> zroot feature@multi_vdev_crash_dump enabled = local >>>>> zroot feature@spacemap_histogram active = local >>>>> zroot feature@enabled_txg active = local >>>>> zroot feature@hole_birth active = local >>>>> zroot feature@extensible_dataset enabled = local >>>>> zroot feature@embedded_data active = local >>>>> zroot feature@bookmarks enabled = local >>>>> zroot feature@filesystem_limits enabled = local >>>>> zroot feature@large_blocks enabled = local >>>>> zroot feature@sha512 enabled = local >>>>> zroot feature@skein enabled = local >>>>> zroot unsupported@com.delphix:device_removal inactive = local >>>>> zroot unsupported@com.delphix:obsolete_counts inactive = local >>>>> zroot unsupported@com.delphix:zpool_checkpoint inactive = local >>>>> #=20 >>>>>=20 >>>>> Regards >>>>>=20 >>>>> [1] = https://lists.freebsd.org/pipermail/freebsd-current/2018-March/068886.html= >>>>> [2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D151910 >>>>>=20 >>>>> --- >>>>> KIRIYAMA Kazuhiko >>>>> _______________________________________________ >>>>> 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 >>>> I am guessing it means something is corrupt, as 16MB is the maximum = size >>>> of a record in ZFS. Also, the 'large_blocks' feature is 'enabled', = not >>>> 'active', so this suggest you do not have any records larger than = 128kb >>>> on your pool. >>>=20 >>> As I mentioned above, [2] says ZFS on RAID disks have any >>> serious bugs except for mirror. Anyway I gave up to use ZFS >>> on RAID{5,6}* until Bug 151910 [2] fixed. >>>=20 >>=20 >> if you boot from usb stick (or cd), press esc at boot loader menu and = enter lsdev -v. what sector and disk sizes are reported? >=20 > OK lsdev -v > disk devices: > disk0: BIOS drive C (31588352 X 512) > disk0p1: FreeBSD boot 512KB > disk0p2: FreeBSD UFS 13GB > disk0p3: FreeBSD swap 771MB > disk1: BIOS drive D (4294967295 X 512) > disk0p1: FreeBSD boot 512KB > disk0p2: FreeBSD swap 128GB > disk0p3: FreeBSD ZFS 19TB > OK >=20 > Does this means whole disk size that I can use is > 2TB (4294967295 X 512) ?=20 Yes, or to be exact, that is the disk size reported by the INT13; and as = below you do get the same value from UEFI, the limit seems to be set by = the RAID controller itself. In this case it means that the best way to = address the issue is to create one smaller lun for boot disk (zroot = pool) and larger for data. Or of course you can have separate FreeBSD = ZFS partition for zroot, just make sure it will fit inside the first = 2TB. Of course there may be option for RAID firmware update, or configuration = settings for lun, or use JBOD mode (if supported by the card). JBOD = would be the best because in the current setup, the pool is vulnerable = against silent data corruption (checksum errors) and has no way to = recover (this is the reason why RAID setups are not preferred with zfs). rgds, toomas >=20 >=20 >>=20 >> the issue [2] is mix of ancient freebsd (v 8.1 is mentioned there), = and RAID luns with 512B sector size and 15TB!!! total size - are you = really sure your BIOS can actually address 15TB lun (with 512B sector = size)? Note that the problem with large disks can hide itself till you = have pool filled up enough till the essential files will be stored above = the limit~ meaning that you may have ~perfectly working~ setup till at = some point in time, after next update, it is suddenly not working any = more. >>=20 >=20 > I see why I could use for a while. >=20 >> Note that for boot loader we have only INT13h for BIOS version, and = it really is limited. The UEFI version is using EFI_BLOCK_IO API, which = usually can handle large sectors and disk sizes better. >=20 > I re-installed the machine with UEFI boot: >=20 > # gpart show mfid0 > =3D> 40 42965401520 mfid0 GPT (20T) > 40 409600 1 efi (200M) > 409640 2008 - free - (1.0M) > 411648 268435456 2 freebsd-swap (128G) > 268847104 42696552448 3 freebsd-zfs (20T) > 42965399552 2008 - free - (1.0M) >=20 > # uname -a > FreeBSD vm.openedu.org 12.0-CURRENT FreeBSD = 12.0-CURRENT #0 r335317: Mon Jun 18 16:21:17 UTC 2018 = root@releng3.nyi.freebsd.org = :/usr/obj/usr/src/amd64.amd64/sys/GEN= ERIC amd64 > # zpool get all zroot > NAME PROPERTY VALUE = SOURCE > zroot size 19.9T - > zroot capacity 0% - > zroot altroot - = default > zroot health ONLINE - > zroot guid 11079446129259852576 = default > zroot version - = default > zroot bootfs zroot/ROOT/default = local > zroot delegation on = default > zroot autoreplace off = default > zroot cachefile - = default > zroot failmode wait = default > zroot listsnapshots off = default > zroot autoexpand off = default > zroot dedupditto 0 = default > zroot dedupratio 1.00x - > zroot free 19.9T - > zroot allocated 1.67G - > zroot readonly off - > zroot comment - = default > zroot expandsize - - > zroot freeing 0 = default > zroot fragmentation 0% - > zroot leaked 0 = default > zroot bootsize - = default > zroot checkpoint - - > zroot feature@async_destroy enabled = local > zroot feature@empty_bpobj active = local > zroot feature@lz4_compress active = local > zroot feature@multi_vdev_crash_dump enabled = local > zroot feature@spacemap_histogram active = local > zroot feature@enabled_txg active = local > zroot feature@hole_birth active = local > zroot feature@extensible_dataset enabled = local > zroot feature@embedded_data active = local > zroot feature@bookmarks enabled = local > zroot feature@filesystem_limits enabled = local > zroot feature@large_blocks enabled = local > zroot feature@sha512 enabled = local > zroot feature@skein enabled = local > zroot feature@device_removal enabled = local > zroot feature@obsolete_counts enabled = local > zroot feature@zpool_checkpoint enabled = local > #=20 >=20 > and checked 'lsdev -v' at loader prompt: >=20 > OK lsdev -v > = PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/VenHw(CF31FAC5-C24E-11D2-85F3-00A0C= 93EC93B,80) > disk0: 4294967295 X 512 blocks > disk0p1: EFI 200MB > disk0p2: FreeBSD swap 128GB > disk0p2: FreeBSD ZFS 19TB > net devices: > zfs devices: > pool: zroot > bootfs: zroot/ROOT/default > config: >=20 > NAME STATE > zroot ONLINE > mfid0p3 ONLINE > OK >=20 > but disk size (4294967295 X 512) still not changed or this > means 4294967295 X 512 X 512 bytes ? >=20 >>=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 = " >=20 > Regards >=20 > --- > KIRIYAMA Kazuhiko From owner-freebsd-current@freebsd.org Tue Jun 26 07:52: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 43A911017859; Tue, 26 Jun 2018 07:52:13 +0000 (UTC) (envelope-from dch@skunkwerks.at) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (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 D9C8984B84; Tue, 26 Jun 2018 07:52:12 +0000 (UTC) (envelope-from dch@skunkwerks.at) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id EF94421E00; Tue, 26 Jun 2018 03:52:11 -0400 (EDT) Received: from web6 ([10.202.2.216]) by compute7.internal (MEProxy); Tue, 26 Jun 2018 03:52:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skunkwerks.at; h=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=fm2; bh=IZ+apDUwMy1Ds9XYcf//sEDWsUDSS Zkcou9aWugrCcc=; b=Eyp8IL2FXR5Y76SP6BEI2BYjbMBgNXV3C6vgsVQffWtP5 x6feYm+O3QbrZk36eN2DbL4Q88ROTvy2YwflseaYfGXgESh2bcKTLIhJLGGumTUD VBf9DI2MS/065Sbbt26MM65F+9fNbt7MqInewgcb2rxQ/3pnsS5zA5Y6eUUBW7bK Z5PVFXgthsYTUk/kdfZshL8IWm0aLVFc4zO+khdocU3R/TCGU8JiTLspvOTVjHLC lXa+3qGiEI8u+asN2zJxjAEdZTtxra0cf5viQcEtAognJAevr27sjuw7gZUCkwyT U3oXrh8G+4mlxg80UEaHxijf9RHmPdC/uLZx0ghzw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=IZ+apD UwMy1Ds9XYcf//sEDWsUDSSZkcou9aWugrCcc=; b=DnZ1h/JucL1VD9w1NGIb6H NQZR0cyU6dDYTEBh7wi0hDV6ffyJi90DoCn6/+A1Qe2GuxOi3DSacui5Ic5DWsAI hGk6K5tihO/f0ywZ93CHZVERgkevhHoYy8IkQ5LrhB6lBrCscrzdffKZ5aS4EJPp i03GW3BZ41kXGy7IKt9qMh2kdTkJCZCz8NnKFFBg/kbZTq4+6F2UrWEJuOwsmNrZ O3DHnJI9r5imI0xyaf5021C3QMqSTDbehs8CL9dMbBe6yvBYPmz/xly6xxG8ykFM pPxmq9GsYPKHfcJWs128yvA2GMHUCoc3YhqnQaXrZ6IYW7lbvc94SKFRaeD6dNjA == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 9C6CF411E; Tue, 26 Jun 2018 03:52:11 -0400 (EDT) Message-Id: <1529999531.2330685.1420550472.409ED830@webmail.messagingengine.com> From: Dave Cottlehuber To: freebsd-net@freebsd.org, freebsd-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-0d8ea36c Subject: Re: unloading pf causes desktop system to freeze since ~ r335651 [coredump] Date: Tue, 26 Jun 2018 09:52:11 +0200 In-Reply-To: <1529960902.613046.1420067144.3B445531@webmail.messagingengine.com> References: <1529960902.613046.1420067144.3B445531@webmail.messagingengine.com> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 26 Jun 2018 07:52:13 -0000 On Mon, 25 Jun 2018, at 23:08, Dave Cottlehuber wrote: > [cross-posting for advice on general debugging + network-specific thoughts] The HPET NMI watchdog patch was very timely - works a treat: https://reviews.freebsd.org/D15630 > However each time there's no crashdump, & the usual ctrl-alt-esc does't > work either. I bumped my /usr/src to latest HEAD, applied HPET NMI watchdog hack & after freezing via `service pf stop`, I was rewarded with a coredump on next reboot; full log: https://git.io/f4Q4P [1202] panic: Assertion !in_epoch() && !mtx_owned(&(&(*(__typeof(vnet_entry_tcbinfo)*) (((((__curthread())->td_vnet))->vnet_data_base) + (uintptr_t)&vnet_entry_tcbinfo)))->ipi_lock) failed at /usr/src/sys/netinet/tcp_input.c:802 [1202] cpuid = 4 [1202] time = 1529997533 [1202] KDB: stack backtrace: [1202] db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0077ddc4a0 [1202] vpanic() at vpanic+0x1a3/frame 0xfffffe0077ddc500 [1202] doadump() at doadump/frame 0xfffffe0077ddc580 [1202] tcp_input() at tcp_input+0x940/frame 0xfffffe0077ddc6c0 [1202] ip_input() at ip_input+0x3f7/frame 0xfffffe0077ddc720 [1202] netisr_dispatch_src() at netisr_dispatch_src+0xa2/frame 0xfffffe0077ddc780 [1202] ether_demux() at ether_demux+0x16e/frame 0xfffffe0077ddc7b0 [1202] ether_nh_input() at ether_nh_input+0x402/frame 0xfffffe0077ddc820 [1202] netisr_dispatch_src() at netisr_dispatch_src+0xa2/frame 0xfffffe0077ddc880 [1202] ether_input() at ether_input+0x8f/frame 0xfffffe0077ddc8c0 [1202] iflib_rxeof() at iflib_rxeof+0xcce/frame 0xfffffe0077ddc9b0 [1202] _task_fn_rx() at _task_fn_rx+0x7f/frame 0xfffffe0077ddc9f0 [1202] gtaskqueue_run_locked() at gtaskqueue_run_locked+0x139/frame 0xfffffe0077ddca40 [1202] gtaskqueue_thread_loop() at gtaskqueue_thread_loop+0x88/frame 0xfffffe0077ddca70 [1202] fork_exit() at fork_exit+0x84/frame 0xfffffe0077ddcab0 [1202] fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0077ddcab0 [1202] --- trap 0, rip = 0, rsp = 0, rbp = 0 --- [1202] KDB: enter: panic db:0:kdb.enter.panic> run lockinfo db:1:lockinfo> show locks db:1:lockinfo> show alllocks Process 12789 (h2o) thread 0xfffff8020dd4f580 (101673) Process 17635 (pflogd) thread 0xfffff8017c91c580 (101027) db:1:lockinfo> show lockedvnods Locked vnodes db:0:kdb.enter.panic> show pcpu cpuid = 4 dynamic pcpu = 0xfffffe00848dd8c0 curthread = 0xfffff801067f2000: pid 0 tid 100029 "if_io_tqg_4" curpcb = 0xfffffe0077ddcb80 fpcurthread = none idlethread = 0xfffff80106796000: tid 100007 "idle: cpu4" curpmap = 0xffffffff81ffbe08 tssp = 0xffffffff82066ac0 commontssp = 0xffffffff82066ac0 rsp0 = 0xfffffe0077ddcb80 gs32p = 0xffffffff8206d6f8 ldt = 0xffffffff8206d738 tss = 0xffffffff8206d728 curvnet = 0xfffff801000ca0c0 spin locks held: db:0:kdb.enter.panic> bt Tracing pid 0 tid 100029 td 0xfffff801067f2000 kdb_enter() at kdb_enter+0x3b/frame 0xfffffe0077ddc4a0 vpanic() at vpanic+0x1c0/frame 0xfffffe0077ddc500 doadump() at doadump/frame 0xfffffe0077ddc580 tcp_input() at tcp_input+0x940/frame 0xfffffe0077ddc6c0 ip_input() at ip_input+0x3f7/frame 0xfffffe0077ddc720 netisr_dispatch_src() at netisr_dispatch_src+0xa2/frame 0xfffffe0077ddc780 ether_demux() at ether_demux+0x16e/frame 0xfffffe0077ddc7b0 ether_nh_input() at ether_nh_input+0x402/frame 0xfffffe0077ddc820 netisr_dispatch_src() at netisr_dispatch_src+0xa2/frame 0xfffffe0077ddc880 ether_input() at ether_input+0x8f/frame 0xfffffe0077ddc8c0 iflib_rxeof() at iflib_rxeof+0xcce/frame 0xfffffe0077ddc9b0 _task_fn_rx() at _task_fn_rx+0x7f/frame 0xfffffe0077ddc9f0 gtaskqueue_run_locked() at gtaskqueue_run_locked+0x139/frame 0xfffffe0077ddca40 gtaskqueue_thread_loop() at gtaskqueue_thread_loop+0x88/frame 0xfffffe0077ddca70 fork_exit() at fork_exit+0x84/frame 0xfffffe0077ddcab0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0077ddcab0 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- Please keep replies just to freebsd-net@ from here on. A+ Dave From owner-freebsd-current@freebsd.org Tue Jun 26 14:05: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 03FBE102827E for ; Tue, 26 Jun 2018 14:05:56 +0000 (UTC) (envelope-from lists@eitanadler.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 856B971BE8 for ; Tue, 26 Jun 2018 14:05:55 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: by mailman.ysv.freebsd.org (Postfix) id 3BEA6102827C; Tue, 26 Jun 2018 14:05:55 +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 17BF9102827B for ; Tue, 26 Jun 2018 14:05:55 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-yb0-x233.google.com (mail-yb0-x233.google.com [IPv6:2607:f8b0:4002:c09::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 7C45D71BE4 for ; Tue, 26 Jun 2018 14:05:54 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: by mail-yb0-x233.google.com with SMTP id g3-v6so4639445ybf.10 for ; Tue, 26 Jun 2018 07:05:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eYKqmEkmoBxq3pm+Ib5BL/dZlc4sFTleeNRmSVkGVZY=; b=PItTpa99gjDOeDCEWRYbzluU/YrrPurVSqjgbx/KbWFVP6kYxI63K0jA50dpksAXrl l+aSRvJIc8rApKVKJJqBIcHh0P4wlwl/2Fq9kCQ7XZJPUmdCm8KKZWf2JGxS+N2ZeP8r bnHrHz1gFHbPR3WnsYMLt4oqwSlVAY5QlzxzM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eYKqmEkmoBxq3pm+Ib5BL/dZlc4sFTleeNRmSVkGVZY=; b=OILk/+VJ8s1BOjOaF/IOrB3mcEsooWkE/tNhyVlgB1yypmC0/PiFgd1W68U0g9FVkV bAcwRX38286ssf/NRyNd7q0qjDen0AYvG716yGnUHXBFyfv4p71jwjo47PUINWJuNF6y ej63kZU12pv4ZqD5NOJEjy3XTpmmJa3iGmYGZwKKoMZlsaAaYCZDrkeBcvy6uWM8PWbS ZAFJfO7eazm4aBzNLJvCOtAvkigOVMe+4noQdJmTzCYgcehlpewNe0UCrfJv2nciXP2/ asOG8E+0nt6FVXzXody+vHvML6dCqnT07i+06Z3PHPWM4kyAwNElkaTGi9h0BolS0xmV 8MQA== X-Gm-Message-State: APt69E05+QWmqQlNUXbBTS07/ApOdviJ+JaMDkVvIps5lsUBvn33zLwf kPC+H9/dQDV9eiwKj7+Fq127Bi/GW4566MkM7zxMsdoQ X-Google-Smtp-Source: ADUXVKLJDTHWHNzHS358kqLEH1sQZLz5HKR2LwCEa17mEqUlXajS4cMdR3x9UeCQpT+KtPsG1speXFIOLg86sEo9kOU= X-Received: by 2002:a25:8542:: with SMTP id f2-v6mr852228ybn.87.1530021953563; Tue, 26 Jun 2018 07:05:53 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:ef50:0:0:0:0:0 with HTTP; Tue, 26 Jun 2018 07:05:22 -0700 (PDT) In-Reply-To: <20180619115030.5491af33@ernst.home> References: <20180613103535.GP2493@kib.kiev.ua> <20180619115030.5491af33@ernst.home> From: Eitan Adler Date: Tue, 26 Jun 2018 07:05:22 -0700 Message-ID: Subject: Re: Ryzen public erratas To: Gary Jennejohn Cc: Konstantin Belousov , amd64@freebsd.org, "current@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 26 Jun 2018 14:05:56 -0000 On 19 June 2018 at 02:50, Gary Jennejohn wrote: > On Mon, 18 Jun 2018 22:44:13 -0700 > Eitan Adler wrote: > >> On 13 June 2018 at 04:16, Eitan Adler wrote: >> > On 13 June 2018 at 03:35, Konstantin Belousov wrote: >> >> Today I noted that AMD published the public errata document for Ryzens, >> >> https://developer.amd.com/wp-content/resources/55449_1.12.pdf >> >> >> >> Some of the issues listed there looks quite relevant to the potential >> >> hangs that some people still experience with the machines. I wrote >> >> a script which should apply the recommended workarounds to the erratas >> >> that I find interesting. >> >> >> >> To run it, kldload cpuctl, then apply the latest firmware update to your >> >> CPU, then run the following shell script. Comments indicate the errata >> >> number for the workarounds. >> >> >> >> Please report the results. If the script helps, I will code the kernel >> >> change to apply the workarounds. >> >> >> >> #!/bin/sh >> >> >> >> # Enable workarounds for erratas listed in >> >> # https://developer.amd.com/wp-content/resources/55449_1.12.pdf >> >> >> >> # 1057, 1109 >> >> sysctl machdep.idle_mwait=0 >> >> sysctl machdep.idle=hlt >> > >> > >> > Is this needed if it was previously machdep.idle: acpi ? >> >> This might explain why I've never seen the lockup issues mentioned by >> other people. What would cause my machine to differ from others? >> > > I had sysctl machdep.idle_mwait=1 and machdep.idle=acpi before > applying the shell script. I had multiple lockups every week, > sometimes multiple lockups per day. This makes me curious about why I didn't experience lockups. Perhaps my BIOS defaulted to something else? With these settings: machdep.idle: acpi machdep.idle_mwait: 1 -- Eitan Adler From owner-freebsd-current@freebsd.org Tue Jun 26 16:24: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 BC75C1001565 for ; Tue, 26 Jun 2018 16:24:22 +0000 (UTC) (envelope-from gljennjohn@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 4EA7077AE0 for ; Tue, 26 Jun 2018 16:24:22 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 0807F1001563; Tue, 26 Jun 2018 16:24:22 +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 D48081001562 for ; Tue, 26 Jun 2018 16:24:21 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::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 409F877ADE; Tue, 26 Jun 2018 16:24:21 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wr0-x22e.google.com with SMTP id c5-v6so6717166wrs.10; Tue, 26 Jun 2018 09:24:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=WcmA1Gsk2dflsKk1KTzBK2140ttC6Xt9dO/TWVmeOZ0=; b=ecLS9NjZ4UXu1dv+CzhZBd8Wz0idzKqLmZPP57soPnaYWQHE2QT0ReqKItnOs8Qqh7 z7Dk4VuQWkcFmhgZQ9MQEtqGiClsScBR2r0B6ikvcwx1Vif3rAqSHJsHq1mIKS1u7gMh yohGDNWmzCuHGpHwvjbg38UWsHDStmJ/0z8tpQq/pJORF5UuraqQXFaNo3jnVYORssAp I8SHSJ8BSpi/A9M71ThXDz/i0Upv70LXnNB6FYRF08VIgAh1YdqB7xekzsnVn3YqGYpO HnUJY7rrx94ngYOJiJuMqX/6F9YWCF7Q3fOwFK1oJAnr6ZJzuRTp9lnkblKHPN4v37ol IIpg== 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:reply-to:mime-version:content-transfer-encoding; bh=WcmA1Gsk2dflsKk1KTzBK2140ttC6Xt9dO/TWVmeOZ0=; b=HPfHiQrBfZzgAbhmROF62AXN0U25omVWQbA3cexSrX195TLOk2nYCDVVc4EPiFWUnb cLgQ7NDACrSI0IqdPt8W2WyA/MXGQfMUQZeKjAznAfbm0Hho6GlLL2t3yEQojOr+SLLt oo1z91WjxTejBGHQS2Q6AbeRPjRYPAOz+Ej5xWaHrlqfGAFU286jkjo9s9/6pvXDkjdm prVAQRnuVR5Y1zKQ3JpZCBvHcHR5lTs1djt4ZhLauIQ5WEWdDf/fUr0tLJHVxDiT5Lcn 608CsHK+oxSHnW58nLdzNrERB0M2ffPfqs7CmEiqCjC2buL99eGALt58L7VFVy8/HeAn Mq1w== X-Gm-Message-State: APt69E369xgSwuk0qEInjNaYKxn8bofSt+eXWSFioMF4RxoNnYE9qiAL HNnI877j75p45utnr+w58sRwpQ== X-Google-Smtp-Source: AAOMgpegtTZ2lqtitG+GrWTiaVnRFRzSChkwMIXZmu+Die3IpKW466WBttbdH6RbbvD31y3lUEgyLw== X-Received: by 2002:adf:90e9:: with SMTP id i96-v6mr2135043wri.93.1530030258905; Tue, 26 Jun 2018 09:24:18 -0700 (PDT) Received: from ernst.home (p5B0234B4.dip0.t-ipconnect.de. [91.2.52.180]) by smtp.gmail.com with ESMTPSA id k12-v6sm2582595wrr.40.2018.06.26.09.24.17 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 26 Jun 2018 09:24:17 -0700 (PDT) Date: Tue, 26 Jun 2018 18:24:12 +0200 From: Gary Jennejohn To: Bryan Drewery Cc: current@freebsd.org Subject: Re: error building clang in HEAD Message-ID: <20180626182412.49dce7b0@ernst.home> In-Reply-To: References: <20180623154048.1b228df0@ernst.home> <196E84B3-B58F-4296-B6EA-84D0DE3230EF@FreeBSD.org> <20180624095747.7384f5bf@ernst.home> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.16.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.26 Precedence: 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, 26 Jun 2018 16:24:23 -0000 On Mon, 25 Jun 2018 11:28:18 -0700 Bryan Drewery wrote: > On 6/24/2018 12:57 AM, Gary Jennejohn wrote: > > On Sat, 23 Jun 2018 17:05:16 +0200 > > Dimitry Andric wrote: > > > >> On 23 Jun 2018, at 15:40, Gary Jennejohn wrote: > >>> > >>> There is a strange error building clang with this use case: > >>> > >>> cd /usr/src > >>> make -j10 makeworld > >> > >> What's the "makeworld" target? I've not heard of this. > >> > > > > A typo. I meant buildowrld. > > > >>> which produces this error output: > >>> > >>> ===> lib/clang/libclang (all) > >>> error: unable to rename temporary 'Sema/SemaTemplate-12ad7e30.o.tmp' to output file 'Sema/SemaTemplate.o': 'No such file or directory' > >>> 1 error generated. > >>> --- Sema/SemaTemplate.o --- > >>> *** [Sema/SemaTemplate.o] Error code 1 > >> > >> This typically happens if "make obj" was not run before the rest of the > >> make targets. Normally, the order is: make obj, then make depend, then > >> make (a.k.a. make all). > >> > >> Is there a directory /usr/obj/usr/src/lib/libclang/Sema ? > >> > > > > Well, I would hope/expect that make buildworld does make obj. > > > > Yes, the directory was there. > > > > Actually neither 'make obj' nor 'make depend' is done or needed anymore > in buildworld. > > The directory above is incorrect, please check for > > /usr/obj/usr/src/amd64.amd64/lib/clang/libclang/Sema > Well, now everything is there because I ran a buildworld without -j. > Do you have another Makefile or script that is executing > buildworld for you? > No, I use a bash alias named mw: mw is aliased to `pushd /usr/src;time make -s -j$NCPU buildworld;popd' NCPU is defined as 10. > What's in your src.conf and make.conf? > The only changes I made recently were to /etc/src.conf when I added: WITHOUT_LLVM_TARGET_AARCH64=yes WITHOUT_LLVM_TARGET_ARM=ys WITHOUT_LLVM_TARGET_MIPS=yes WITHOUT_LLVM_TARGET_POWERPC=yes WITHOUT_LLVM_TARGET_SPARC=yes WITH_LLVM_TARGET_X86=yes Otherwise, I haven't touched src.conf or make.conf in a long time. I'll try commenting these out and see what happens. -- Gary Jennejohn From owner-freebsd-current@freebsd.org Tue Jun 26 16:31: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 7F48810019F3 for ; Tue, 26 Jun 2018 16:31:28 +0000 (UTC) (envelope-from gljennjohn@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 0DB0D77FDD for ; Tue, 26 Jun 2018 16:31:28 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id C5F8F10019F1; Tue, 26 Jun 2018 16:31:27 +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 A132B10019F0; Tue, 26 Jun 2018 16:31:27 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::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 208E477FD8; Tue, 26 Jun 2018 16:31:27 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wr0-x230.google.com with SMTP id a12-v6so17917938wro.1; Tue, 26 Jun 2018 09:31:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=BRJPCMVmatsSPfSumJl9MNz9KEoYEw1FInrURNRinec=; b=LrALL+hw8kVhJcunvyD+6HjmNo+etIYxrcEg0DMRrjSDDxzEJn530b8NbndaxR6wrU 3kCx+F7SKjCbDlVM9CFuOQo/KHKpDFfzW9DAvxfQwjLrcAiqDmZJXTvpvilQs6r1kZGA o9+2D+0Xbeo8koncs09DI0+2XQULf/ATTED/dDvLybg+EJIGawdQVGfFAzahk59zjvsC irLdYsIW7QvoLchpOh1oAihOgWxFXJubrU2jjV1/oA4ZNKMOxJdJwZQXoHB0GSpHW+BQ oBZBOvnj5Mv2gI/8lMlpbHzu+TAOXtcqoHnPjOsPoRSUyxtbAmXaxQ49rBT7DC1/XLj+ 6ZnQ== 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:reply-to:mime-version:content-transfer-encoding; bh=BRJPCMVmatsSPfSumJl9MNz9KEoYEw1FInrURNRinec=; b=fxI86DhVpfPwGM4j+XJN+WuVD8uYiONERooJNrcq+/Y8yU4rrpaL755fgwuccE64LB J9GCusvF/4Ox9eM9l7/McqNt6zZbpTZ+lSV0XNYfGB536B0IGiKWw++Vhw15LWNCO5Rd ojW64awDQj5WrRSpoikjLrwgYpm3uNRY4nw4VHO4Wbs48qrQ8ZN9wWoEwsjodmlQkp3K ToVnPFL5XHmM7aeM0QsoE8vOsAES6ubd3Yoi8aq9sYRrhiCHfnIUb1SrQF2fwbD+imft oTd28I5bQX0l/8MSA+euWq1XBfbcvLss0310Io7JEgexNLUxsEx7yObvVyeEjWaqUhGK DjzQ== X-Gm-Message-State: APt69E0QGw6HosKNHMIet2E5AZuV1JUgSuZn4oALBNWoUZmLbQtZl7F0 2hu3Ee3skfCfC0ioUSbinyI= X-Google-Smtp-Source: AAOMgpeBCv+VRFpXBUjpdD4DT8Sit4X8hWVb9woUTtsBXH8ruyor/+aB6+3Hd1Rgbky3ncMVu9ihUQ== X-Received: by 2002:a5d:4b4b:: with SMTP id w11-v6mr2113423wrs.87.1530030686149; Tue, 26 Jun 2018 09:31:26 -0700 (PDT) Received: from ernst.home (p5B0234B4.dip0.t-ipconnect.de. [91.2.52.180]) by smtp.gmail.com with ESMTPSA id c6-v6sm2924601wrp.29.2018.06.26.09.31.24 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 26 Jun 2018 09:31:25 -0700 (PDT) Date: Tue, 26 Jun 2018 18:31:24 +0200 From: Gary Jennejohn To: Eitan Adler Cc: Konstantin Belousov , amd64@freebsd.org, "current@freebsd.org" Subject: Re: Ryzen public erratas Message-ID: <20180626183124.5d2173ec@ernst.home> In-Reply-To: References: <20180613103535.GP2493@kib.kiev.ua> <20180619115030.5491af33@ernst.home> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.16.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.26 Precedence: 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, 26 Jun 2018 16:31:28 -0000 On Tue, 26 Jun 2018 07:05:22 -0700 Eitan Adler wrote: > On 19 June 2018 at 02:50, Gary Jennejohn wrote: > > On Mon, 18 Jun 2018 22:44:13 -0700 > > Eitan Adler wrote: > > > >> On 13 June 2018 at 04:16, Eitan Adler wrote: > >> > On 13 June 2018 at 03:35, Konstantin Belousov wrote: > >> >> Today I noted that AMD published the public errata document for Ryzens, > >> >> https://developer.amd.com/wp-content/resources/55449_1.12.pdf > >> >> > >> >> Some of the issues listed there looks quite relevant to the potential > >> >> hangs that some people still experience with the machines. I wrote > >> >> a script which should apply the recommended workarounds to the erratas > >> >> that I find interesting. > >> >> > >> >> To run it, kldload cpuctl, then apply the latest firmware update to your > >> >> CPU, then run the following shell script. Comments indicate the errata > >> >> number for the workarounds. > >> >> > >> >> Please report the results. If the script helps, I will code the kernel > >> >> change to apply the workarounds. > >> >> > >> >> #!/bin/sh > >> >> > >> >> # Enable workarounds for erratas listed in > >> >> # https://developer.amd.com/wp-content/resources/55449_1.12.pdf > >> >> > >> >> # 1057, 1109 > >> >> sysctl machdep.idle_mwait=0 > >> >> sysctl machdep.idle=hlt > >> > > >> > > >> > Is this needed if it was previously machdep.idle: acpi ? > >> > >> This might explain why I've never seen the lockup issues mentioned by > >> other people. What would cause my machine to differ from others? > >> > > > > I had sysctl machdep.idle_mwait=1 and machdep.idle=acpi before > > applying the shell script. I had multiple lockups every week, > > sometimes multiple lockups per day. > > This makes me curious about why I didn't experience lockups. Perhaps my > BIOS defaulted to something else? > > With these settings: > > machdep.idle: acpi > machdep.idle_mwait: 1 > I can only say that after updating the processor's microcde and applying the errata script my system runs much more stabily. No lockups for days. I suspect that updating the microcode helped quite a bit. I have a first-generation Ryzen 5 1600 with all the errata. -- Gary Jennejohn From owner-freebsd-current@freebsd.org Tue Jun 26 18:00: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 330D5100737B for ; Tue, 26 Jun 2018 18:00:18 +0000 (UTC) (envelope-from gljennjohn@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 BD08D7B867 for ; Tue, 26 Jun 2018 18:00:17 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 8188E1007378; Tue, 26 Jun 2018 18:00: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 5C9BE1007377 for ; Tue, 26 Jun 2018 18:00:17 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C5BD47B864; Tue, 26 Jun 2018 18:00:16 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wr0-x22d.google.com with SMTP id g18-v6so18142828wro.7; Tue, 26 Jun 2018 11:00:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=zitDer2+lRlFDd3SCGK/dWTH+kav9kuf4bJ1nyQVyQE=; b=FdZ5gf7pvxrkJDVxR6pi/6uOm8AzGYJc1ozu7QEy5W9xjI14Zy4BR/8Ydum+t8Kmgg Qe5zLLdilRgotB8BwICdEnLUCPO7vwV8tXhZwli7wkIj6IESvjvuVK2bXQryhGJkIgCP k9DMVsoFJDYvb+vpHzJdcFECQY+3a4JqhMR5crziQm0SW6Us6vC80PMnFagSPl3Vvznr E9Yo98eXTsrutCTSltL/9LZBjUosiDa8CZJzKhDmJzYDueMpuLjX38/cgj+6UCfad/9F mkr31BoyxiVvaqN2+YNliJqpGe4NOi8qABEL/piOpPb1gquuiHqZJ2JpDWXi23zVTegs qIyA== 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:reply-to:mime-version:content-transfer-encoding; bh=zitDer2+lRlFDd3SCGK/dWTH+kav9kuf4bJ1nyQVyQE=; b=opyMGMQRlkwD0RRxItYyaWDVnzwI3kvjLu5KLhLEA6Nam/fKetbg2/jOHmN/l68EUx u4rRa0SJBUqaLBAcbevjtt3G84Zb/FLjtQFrDGC4LQQijx5XnjTB9kzP4XNGYmAyW/2s 37ZmI/DRuC6t8C08LOEnZXog9AlVR6E4oSHx+NrqbTxeS8gm3Ub1s0FW8+GC0dVJ8rYy KhSyq/9yggCd/NAZVuQcpws9mZnTtwSdQAANp0CiJiigv7SiPDX48n/KIhtmyiYcoCNW 3jReV5ClYOV7eyJO8H0UOUK6JYZPlIHTklTyhhhW4WJ37BRBX63zULJkOhQF0NwqzA0+ IfbA== X-Gm-Message-State: APt69E1LHF7rJF5j4n92AoWMybGa4/85k8x0r+g5Gsh806DfhHJQdfUN 9hwIdFSvHm8o+2uPtIiV4iWrNA== X-Google-Smtp-Source: AAOMgpeYfhWia5/NIx+bn7//DlKvm6r/j0IgbhLzhnS3ZcXm5VA2Flud+VdfO0cmFpBjfYjpHVHSkw== X-Received: by 2002:adf:a035:: with SMTP id k50-v6mr2356175wrk.202.1530036015588; Tue, 26 Jun 2018 11:00:15 -0700 (PDT) Received: from ernst.home (p5B0234B4.dip0.t-ipconnect.de. [91.2.52.180]) by smtp.gmail.com with ESMTPSA id 139-v6sm3246791wmu.47.2018.06.26.11.00.13 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 26 Jun 2018 11:00:14 -0700 (PDT) Date: Tue, 26 Jun 2018 20:00:13 +0200 From: Gary Jennejohn To: Bryan Drewery Cc: current@freebsd.org Subject: Re: error building clang in HEAD Message-ID: <20180626200013.247e7927@ernst.home> In-Reply-To: <20180626182412.49dce7b0@ernst.home> References: <20180623154048.1b228df0@ernst.home> <196E84B3-B58F-4296-B6EA-84D0DE3230EF@FreeBSD.org> <20180624095747.7384f5bf@ernst.home> <20180626182412.49dce7b0@ernst.home> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.16.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.26 Precedence: 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, 26 Jun 2018 18:00:18 -0000 On Tue, 26 Jun 2018 18:24:12 +0200 Gary Jennejohn wrote: > On Mon, 25 Jun 2018 11:28:18 -0700 > Bryan Drewery wrote: > > > On 6/24/2018 12:57 AM, Gary Jennejohn wrote: > > > On Sat, 23 Jun 2018 17:05:16 +0200 > > > Dimitry Andric wrote: > > > > > >> On 23 Jun 2018, at 15:40, Gary Jennejohn wrote: > > >>> > > >>> There is a strange error building clang with this use case: > > >>> > > >>> cd /usr/src > > >>> make -j10 makeworld > > >> > > >> What's the "makeworld" target? I've not heard of this. > > >> > > > > > > A typo. I meant buildowrld. > > > > > >>> which produces this error output: > > >>> > > >>> ===> lib/clang/libclang (all) > > >>> error: unable to rename temporary 'Sema/SemaTemplate-12ad7e30.o.tmp' to output file 'Sema/SemaTemplate.o': 'No such file or directory' > > >>> 1 error generated. > > >>> --- Sema/SemaTemplate.o --- > > >>> *** [Sema/SemaTemplate.o] Error code 1 > > >> > > >> This typically happens if "make obj" was not run before the rest of the > > >> make targets. Normally, the order is: make obj, then make depend, then > > >> make (a.k.a. make all). > > >> > > >> Is there a directory /usr/obj/usr/src/lib/libclang/Sema ? > > >> > > > > > > Well, I would hope/expect that make buildworld does make obj. > > > > > > Yes, the directory was there. > > > > > > > Actually neither 'make obj' nor 'make depend' is done or needed anymore > > in buildworld. > > > > The directory above is incorrect, please check for > > > > /usr/obj/usr/src/amd64.amd64/lib/clang/libclang/Sema > > > > Well, now everything is there because I ran a buildworld without -j. > > > Do you have another Makefile or script that is executing > > buildworld for you? > > > > No, I use a bash alias named mw: > mw is aliased to `pushd /usr/src;time make -s -j$NCPU buildworld;popd' > > NCPU is defined as 10. > > > What's in your src.conf and make.conf? > > > > The only changes I made recently were to /etc/src.conf when I added: > > WITHOUT_LLVM_TARGET_AARCH64=yes > WITHOUT_LLVM_TARGET_ARM=ys > WITHOUT_LLVM_TARGET_MIPS=yes > WITHOUT_LLVM_TARGET_POWERPC=yes > WITHOUT_LLVM_TARGET_SPARC=yes > WITH_LLVM_TARGET_X86=yes > > Otherwise, I haven't touched src.conf or make.conf in a long time. > I removed some old cruft from src.conf and now make -j10 buildworld is succeeding, even after rm -rf /usr/obj/usr. Thanks for pointing me in the right direction. -- Gary Jennejohn From owner-freebsd-current@freebsd.org Tue Jun 26 19:11: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 C4EB01012693 for ; Tue, 26 Jun 2018 19:11:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-13.consmr.mail.bf2.yahoo.com (sonic316-13.consmr.mail.bf2.yahoo.com [74.6.130.123]) (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 66FCC7F642 for ; Tue, 26 Jun 2018 19:11:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: Q64AQEYVM1k46Y1rSRJemp23WND6AqhPaEdL4WW07jV1Kw_XJ5NTnaamCxKNtBH 9cMe9aTHN3Xob78Wwj3vS5J8pWgrfT5MzsmezqzYa9D_rEqugp0MVUTi1DergdYxNmJbmnsBnUUM iVk24UbbrIagicTssQJP3jx._IzwPOhUyEqiZ_ql_nDmBQ_ZTHqDvsfuNMbHjdwepM0bLxmaAQlg GUUH.dCqzw2TjCZfqCJzpiNpDTGrxH24C486z7mTa4C0atwiUNEJiouW1NXk9_IdQMwGoatTWwHP A.Sdr2EQBcJJIXKQaqaF5CcuGxcrqaXXB7KeE0Du6ggqgEJHPJUvkyvBkDgGGouaqrR3VqAX1LfN iZK5fAz3Y8bWwAQlp37HTfir5rPPHbpG6f6m.2.WTByhzfLYNQ7rl4VhMxUKb_NCsInfQY015TU1 Yn9GCPOmqcpbnmbw63__Nf6dG5KEDttou4fO8YokM_5afEs9Ls80aAHbR.RrrqBPl6gKtVkYEiWO GaVL1hz3jrtgkCBXTw1O3gKVzQyILnfAQ_VWBoH.mzT.OWuVs_U03Ia.gWE2coEWDuNEvNkICKgT JO_5SxE4foAjX4.PaIbmkPNntn2HSw06y_JXMIcfBYgRkIrQCpWqWieUnJB4mADrDR_m_o_MhjCW .fhMnnSfM5Uiafzql18UcwQvo3mJy3oqswxueR8ypkmILo8V6Z9bao7Ox0Wu0xDFkoG_P1VLQcyy LKfGeBYFPUGCc0wRjEd3k5dsE.oz6XhILdxpZPfUQhVq_WvrGAo_6Afn8kQUmpDUeYU8tx5TEdmS 8PTnRdGdzFEB9HsOvpWGb6fiCywNVLcskX3QW9i23MuKF.xKTakBE4SbxkFI3b2bo6QUwzzNwXN0 6cgwFhQp84jO2jZfKsMXC4etG6aqStCSXrr3QSWx8UmLZ.ghSL26Hi1R6dfI9ImKoYcs5OlO37UP DFM2TkTJd6SY4RZrV4034p40qxw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.bf2.yahoo.com with HTTP; Tue, 26 Jun 2018 19:11:49 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp410.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 7945e5fb160124b68c724d444c598e91; Tue, 26 Jun 2018 19:11:45 +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.4 \(3445.8.2\)) Subject: Re: svn commit: r335672 - head/sys/modules [ broke ci.freebsd.org FreeBSD-head-{powerpcspe,mips,mips64,powerpc,armv6,armv7}-build ] Message-Id: <21B2ACE4-3945-48AE-BB04-5341F6723B98@yahoo.com> Date: Tue, 26 Jun 2018 12:11:43 -0700 To: Ed Maste , svn-src-head@freebsd.org, FreeBSD Current X-Mailer: Apple Mail (2.3445.8.2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 26 Jun 2018 19:11:56 -0000 > Author: emaste > Date: Tue Jun 26 16:50:41 2018 > New Revision: 335672 > URL:=20 > https://svnweb.freebsd.org/changeset/base/335672 >=20 >=20 > Log: > Build linprocfs and linsysfs also on arm64 > =20 > Sponsored by: Turing Robotic Industries >=20 > . . . = https://ci.freebsd.org/job/FreeBSD-head-powerpcspe-build/6487/consoleText (a gcc 4.2.1 32-bit target example): --- all_subdir_linprocfs --- /usr/src/sys/compat/linprocfs/linprocfs.c: In function = 'linprocfs_doprocstat': /usr/src/sys/compat/linprocfs/linprocfs.c:747: warning: format '%ld' = expects type 'long int', but argument 3 has type 'time_t' [-Wformat] /usr/src/sys/compat/linprocfs/linprocfs.c:748: warning: format '%ld' = expects type 'long int', but argument 3 has type 'time_t' [-Wformat] /usr/src/sys/compat/linprocfs/linprocfs.c:749: warning: format '%ld' = expects type 'long int', but argument 3 has type 'time_t' [-Wformat] /usr/src/sys/compat/linprocfs/linprocfs.c:750: warning: format '%ld' = expects type 'long int', but argument 3 has type 'time_t' [-Wformat] /usr/src/sys/compat/linprocfs/linprocfs.c:755: warning: format '%lu' = expects type 'long unsigned int', but argument 3 has type 'time_t' = [-Wformat] --- all_subdir_libiconv --- ctfmerge -L VERSION -g -o libiconv.kld iconv.o iconv_ucs.o iconv_xlat.o = iconv_xlat16.o iconv_converter_if.o --- all_subdir_linprocfs --- *** [linprocfs.o] Error code 1 https://ci.freebsd.org/job/FreeBSD-head-armv7-build/444/consoleText (32-bit clang example): --- all_subdir_linprocfs --- /usr/src/sys/compat/linprocfs/linprocfs.c:747:26: error: format = specifies type 'long' but the argument has type 'long long' = [-Werror,-Wformat] PS_ADD("utime", "%ld", TV2J(&kp.ki_rusage.ru_utime)); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ %lld /usr/src/sys/compat/linprocfs/linprocfs.c:122:17: note: expanded from = macro 'TV2J' #define TV2J(x) ((x)->tv_sec * 100UL + (x)->tv_usec / 10000) ^ /usr/src/sys/compat/linprocfs/linprocfs.c:723:57: note: expanded from = macro 'PS_ADD' #define PS_ADD(name, fmt, arg) sbuf_printf(sb, " " fmt, arg) ^~~ /usr/src/sys/compat/linprocfs/linprocfs.c:748:26: error: format = specifies type 'long' but the argument has type 'long long' = [-Werror,-Wformat] PS_ADD("stime", "%ld", TV2J(&kp.ki_rusage.ru_stime)); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ %lld /usr/src/sys/compat/linprocfs/linprocfs.c:122:17: note: expanded from = macro 'TV2J' #define TV2J(x) ((x)->tv_sec * 100UL + (x)->tv_usec / 10000) ^ /usr/src/sys/compat/linprocfs/linprocfs.c:723:57: note: expanded from = macro 'PS_ADD' #define PS_ADD(name, fmt, arg) sbuf_printf(sb, " " fmt, arg) ^~~ /usr/src/sys/compat/linprocfs/linprocfs.c:749:26: error: format = specifies type 'long' but the argument has type 'long long' = [-Werror,-Wformat] PS_ADD("cutime", "%ld", = TV2J(&kp.ki_rusage_ch.ru_utime)); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ %lld /usr/src/sys/compat/linprocfs/linprocfs.c:122:17: note: expanded from = macro 'TV2J' #define TV2J(x) ((x)->tv_sec * 100UL + (x)->tv_usec / 10000) ^ /usr/src/sys/compat/linprocfs/linprocfs.c:723:57: note: expanded from = macro 'PS_ADD' #define PS_ADD(name, fmt, arg) sbuf_printf(sb, " " fmt, arg) ^~~ /usr/src/sys/compat/linprocfs/linprocfs.c:750:26: error: format = specifies type 'long' but the argument has type 'long long' = [-Werror,-Wformat] PS_ADD("cstime", "%ld", = TV2J(&kp.ki_rusage_ch.ru_stime)); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ %lld /usr/src/sys/compat/linprocfs/linprocfs.c:122:17: note: expanded from = macro 'TV2J' #define TV2J(x) ((x)->tv_sec * 100UL + (x)->tv_usec / 10000) ^ /usr/src/sys/compat/linprocfs/linprocfs.c:723:57: note: expanded from = macro 'PS_ADD' #define PS_ADD(name, fmt, arg) sbuf_printf(sb, " " fmt, arg) ^~~ /usr/src/sys/compat/linprocfs/linprocfs.c:755:29: error: format = specifies type 'unsigned long' but the argument has type 'long long' = [-Werror,-Wformat] PS_ADD("starttime", "%lu", TV2J(&kp.ki_start) - = TV2J(&boottime)); = ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ %lld /usr/src/sys/compat/linprocfs/linprocfs.c:122:17: note: expanded from = macro 'TV2J' #define TV2J(x) ((x)->tv_sec * 100UL + (x)->tv_usec / 10000) ^ /usr/src/sys/compat/linprocfs/linprocfs.c:723:57: note: expanded from = macro 'PS_ADD' #define PS_ADD(name, fmt, arg) sbuf_printf(sb, " " fmt, arg) ^~~ . . . --- all_subdir_linprocfs --- 5 errors generated. *** [linprocfs.o] Error code 1 mips64 is different but still broken . . . https://ci.freebsd.org/job/FreeBSD-head-mips64-build/3089/consoleText : --- all_subdir_linprocfs --- In file included from /usr/src/sys/compat/linprocfs/linprocfs.c:108: /usr/src/sys/compat/linux/linux_util.h:76:1: error: "DUMMY" redefined In file included from ./machine/reg.h:51, from /usr/src/sys/sys/ptrace.h:40, from /usr/src/sys/compat/linprocfs/linprocfs.c:64: ./machine/regnum.h:107:1: error: this is the location of the previous = definition . . . --- all_subdir_linprocfs --- *** [linprocfs.o] Error code 1 (powerpc64 built okay.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Tue Jun 26 19:40: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 30AFD10142D0 for ; Tue, 26 Jun 2018 19:40:35 +0000 (UTC) (envelope-from kob6558@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 B8AE480C8A for ; Tue, 26 Jun 2018 19:40:34 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 7282210142CE; Tue, 26 Jun 2018 19:40:34 +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 4D8B710142CC for ; Tue, 26 Jun 2018 19:40:34 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::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 D764180C86; Tue, 26 Jun 2018 19:40:33 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by mail-ua0-x22e.google.com with SMTP id v15-v6so4805414ual.11; Tue, 26 Jun 2018 12:40:33 -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=UUTcACiszu8+J9kVjspCo2VZGht/THCD3jIHC+JMD2M=; b=XbptW5JLLh5S1NR/Qs55xJ9g94H3gsvkddqcWAoAkQNlCaVMuKKNzjHQ9dX8lR/rqY Fjy50CB95UsGELI/0jzuqeKPSnORHmGgoZMUfP0CfUnc9VP+juyqkpPeETfyvFhlywM9 Lxv6PQf0PApU47X6zI/Hl+tYhjFyXRrfVrl2YQmg09dxGjXZ3RmsrHgumLYZkvCgy82P 0yQFjyzT90pKKAzBixzgtI7Jve63dbGwwBwSsxGNw297muVorVTvWLy3ZTOhZmmgyF19 MH5qV31AXExPJ03l80heUEdHArv7vjMHn58nb+c/++UUeSTc5W5at0ZWkleMnsR35rpR E5lA== 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=UUTcACiszu8+J9kVjspCo2VZGht/THCD3jIHC+JMD2M=; b=VWa8t2sbONWiG88351Uy1GQ7xSgrVNs1A9QqjWt+KzN/1cZLmUotPSwm7Kvkhxyrmw LA84fj4t0cDWvQUnKHFCL+L2wIDdV+5gqwdfy90KpRm6aNWIJegtrNbLUfDJt/Ifxs0T aeArfLVJxXXnfegVp6M7n347ptFg4EBapwfl4ncKEr98nNC+RXcH9icf7HmZYe63dO9I SyT+jp9fgE0WgKR4tCOgg6zdrA4H+wXH9wq22FgEkPut7EJTuPN2ua093VZnd0yPybjZ lme2FNUoIEaaoaDenfHAwFohTt/JZaosbgOm0Vm/Nieb8I0e7x7W4G/jzJ8PS/1s7pQG hY4Q== X-Gm-Message-State: APt69E2TXcfENgrk1+dHZhvz6l4B7RBkn4MhT9Je/38pWLLsdywnuJqY CfBu0SL/9Joe3COxIVvFnDwK3hqFooDixST1CF/URF6R X-Google-Smtp-Source: AAOMgpdTbLUmBe97A46ub3ztl6yfYY3btyMNK6ji7bsA/H7vM6R5bvTs+9Oexy3Xe5oROuZLf9L2Af3xLYaHbzpKo7s= X-Received: by 2002:ab0:19c2:: with SMTP id r2-v6mr1886063uai.110.1530042033148; Tue, 26 Jun 2018 12:40:33 -0700 (PDT) MIME-Version: 1.0 Sender: kob6558@gmail.com Received: by 2002:a67:8f05:0:0:0:0:0 with HTTP; Tue, 26 Jun 2018 12:40:32 -0700 (PDT) In-Reply-To: <20180626200013.247e7927@ernst.home> References: <20180623154048.1b228df0@ernst.home> <196E84B3-B58F-4296-B6EA-84D0DE3230EF@FreeBSD.org> <20180624095747.7384f5bf@ernst.home> <20180626182412.49dce7b0@ernst.home> <20180626200013.247e7927@ernst.home> From: Kevin Oberman Date: Tue, 26 Jun 2018 12:40:32 -0700 X-Google-Sender-Auth: dGShtjHWA7SHQN6ltHBNtidl0tE Message-ID: Subject: Re: error building clang in HEAD To: Gary Jennejohn Cc: Bryan Drewery , current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 26 Jun 2018 19:40:35 -0000 On Tue, Jun 26, 2018 at 11:00 AM, Gary Jennejohn wrote: > On Tue, 26 Jun 2018 18:24:12 +0200 > Gary Jennejohn wrote: > > > On Mon, 25 Jun 2018 11:28:18 -0700 > > Bryan Drewery wrote: > > > > > On 6/24/2018 12:57 AM, Gary Jennejohn wrote: > > > > On Sat, 23 Jun 2018 17:05:16 +0200 > > > > Dimitry Andric wrote: > > > > > > > >> On 23 Jun 2018, at 15:40, Gary Jennejohn > wrote: > > > >>> > > > >>> There is a strange error building clang with this use case: > > > >>> > > > >>> cd /usr/src > > > >>> make -j10 makeworld > > > >> > > > >> What's the "makeworld" target? I've not heard of this. > > > >> > > > > > > > > A typo. I meant buildowrld. > > > > > > > >>> which produces this error output: > > > >>> > > > >>> ===> lib/clang/libclang (all) > > > >>> error: unable to rename temporary 'Sema/SemaTemplate-12ad7e30.o.tmp' > to output file 'Sema/SemaTemplate.o': 'No such file or directory' > > > >>> 1 error generated. > > > >>> --- Sema/SemaTemplate.o --- > > > >>> *** [Sema/SemaTemplate.o] Error code 1 > > > >> > > > >> This typically happens if "make obj" was not run before the rest of > the > > > >> make targets. Normally, the order is: make obj, then make depend, > then > > > >> make (a.k.a. make all). > > > >> > > > >> Is there a directory /usr/obj/usr/src/lib/libclang/Sema ? > > > >> > > > > > > > > Well, I would hope/expect that make buildworld does make obj. > > > > > > > > Yes, the directory was there. > > > > > > > > > > Actually neither 'make obj' nor 'make depend' is done or needed anymore > > > in buildworld. > > > > > > The directory above is incorrect, please check for > > > > > > /usr/obj/usr/src/amd64.amd64/lib/clang/libclang/Sema > > > > > > > Well, now everything is there because I ran a buildworld without -j. > > > > > Do you have another Makefile or script that is executing > > > buildworld for you? > > > > > > > No, I use a bash alias named mw: > > mw is aliased to `pushd /usr/src;time make -s -j$NCPU buildworld;popd' > > > > NCPU is defined as 10. > > > > > What's in your src.conf and make.conf? > > > > > > > The only changes I made recently were to /etc/src.conf when I added: > > > > WITHOUT_LLVM_TARGET_AARCH64=yes > > WITHOUT_LLVM_TARGET_ARM=ys > > WITHOUT_LLVM_TARGET_MIPS=yes > > WITHOUT_LLVM_TARGET_POWERPC=yes > > WITHOUT_LLVM_TARGET_SPARC=yes > > WITH_LLVM_TARGET_X86=yes > > > > Otherwise, I haven't touched src.conf or make.conf in a long time. > > > > I removed some old cruft from src.conf and now make -j10 buildworld is > succeeding, even after rm -rf /usr/obj/usr. > > Thanks for pointing me in the right direction. > > -- > Gary Jennejohn > I'd like to hear what triggered this as removing unneeded LLVM targets seems like a good idea if you know that you won't need them. Building LLVM takes a long time on my 7+ year old, memory constrained (8G) system. Anything that reduces that time would be nice. -- 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 Jun 26 19:51: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 14F9310155E4 for ; Tue, 26 Jun 2018 19:51:40 +0000 (UTC) (envelope-from bdrewery@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 8E813816A8 for ; Tue, 26 Jun 2018 19:51:39 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 484DC10155E2; Tue, 26 Jun 2018 19:51:39 +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 20AD710155DF for ; Tue, 26 Jun 2018 19:51:39 +0000 (UTC) (envelope-from bdrewery@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 AE29C816A6; Tue, 26 Jun 2018 19:51:38 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (unknown [127.0.1.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 7B9BBDFE9; Tue, 26 Jun 2018 19:51:38 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 4AE15BC8; Tue, 26 Jun 2018 19:51:37 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id Ux4cCckx3-Pb; Tue, 26 Jun 2018 19:51:29 +0000 (UTC) Subject: Re: error building clang in HEAD DKIM-Filter: OpenDKIM Filter v2.10.3 mail.xzibition.com 37C61BB3 To: Kevin Oberman , Gary Jennejohn Cc: current@freebsd.org References: <20180623154048.1b228df0@ernst.home> <196E84B3-B58F-4296-B6EA-84D0DE3230EF@FreeBSD.org> <20180624095747.7384f5bf@ernst.home> <20180626182412.49dce7b0@ernst.home> <20180626200013.247e7927@ernst.home> From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Autocrypt: addr=bdrewery@FreeBSD.org; prefer-encrypt=mutual; keydata= xsBNBFJphmsBCADiFgmS4bIzwZijrS31SjEMzg+n5zNellgM+HkShwehpqCiyhXdWrvH6dTZ a6u50pbUIX7doTR7W7PQHCjCTqtpwvcj0eulZva+iHFp+XrbgSFHn+VVXgkYP2MFySyZRFab D2qqzJBEJofhpv4HvY6uQI5K99pMqKr1Z/lHqsijYYu4RH2OfwB5PinId7xeldzWEonVoCr+ rfxzO/UrgA6v/3layGZcKNHFjmc3NqoN1DXtdaEHqtjIozzbndVkH6lkFvIpIrI6i5ox8pwp VxsxLCr/4Musd5CWgHiet5kSw2SzNeA8FbxdLYCpXNVu+uBACEbCUP+CSNy3NVfEUxsBABEB AAHNJEJyeWFuIERyZXdlcnkgPGJkcmV3ZXJ5QEZyZWVCU0Qub3JnPsLAgAQTAQoAKgIbAwUL CQgHAwUVCgkICwUWAwIBAAIeAQIXgAIZAQUCWujOIgUJCmB7NwAKCRA113G7bkaXz/xpB/9b /UWIPbieY1IeIuHF2pyYPE7Hytkh3HVsxMA0F5Ma2AYQsXZZeKNKWrF7RPyDyDwUklLHJkhm k3EfClBbHxf08kMIm1vWCJRtgxic9knY/bzYGiWMpHjg3cSd1XfrYH1autYqTZAjDwIkgOjU dR//Tbn4V36sY7y2jz+kdMVWvK53U32aZqiwBbCn4DPe1wSZcUs17mV/0uZdIoGdj74B1orN A/0py5vHYo6HcbBNoaR8pKRLf5VZNRsxqGIMhTucx4SJWcHpuRBWYyvJSFzwvxdK4ZD4Yqoc kFGPVtOXktVMai9exrLvP3G77fKMu8DI6j4QRU4wCesnHuIfRPFuzsBNBFJphmsBCACiVFPf kNfaFtUSuY0395ueo/rMyHPGPQ2iwvERFCpeFGSQSgagpenNHLpFQKTg/dl6FOoST5tqyxMq fyHGHDzzU51bvA/IfaGoNi/BIhTe/toZNMRvpcI3PLjiGcnJnuwCCbAVOAGdb+t5cZtpNdOI cKYmrYG3u9RiBpe6dTF+qLrD/8Bs1wjhduQ8fcNNgnkXu8xDH4ZxY0lIc3QgvYWp9vimlQe6 iKjUd2/DX28ETZcD5h6pYV331KMPTrEI0p0yvFijUZce8c1XHFyL1j9sBAha5qpszJl6Uq5i LolhKRcGfcdmtD72vHQjUYglUyudSJUVyo2gMYjdbiFKzJulABEBAAHCwGUEGAEKAA8CGwwF AlrozigFCQpgez0ACgkQNddxu25Gl8+m5Af/R3VEdxNMAcDIes9ADhQyofj20SPV3eCJ3HYR OebTSuNdOudGt4AAyA8Ks94u9hiIp5IGsc6RDsT9W7O2vgXhd6eV3eiY5Oif5xLIYrIDVu1Y 1GyRxRrPEn/QOqDN6uFZCPwK1aOapGcYCrO9lB0gMuTVfgHanU61rgC9tMX0OoAOyRd+V3/M 8lDNhjJdF/IpO3SdYzKfkwduy4qamw4Gphcx/RfYQvYLq/eDkP8d50PphWdboqWBwNRHayro W/07OGzfxM5fJ5mBsXPQcO2QcRjkyHf6xCM6Hi1qQL4OnXMNE/ZTX0lnOj1/pH93TlzSHZMP TaiiA/MBD3vGsXBmBg== Organization: FreeBSD Message-ID: Date: Tue, 26 Jun 2018 12:51:29 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MtssKEg8nXaW6ThhZOMVzbThXoweEwzeD" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 26 Jun 2018 19:51:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --MtssKEg8nXaW6ThhZOMVzbThXoweEwzeD Content-Type: multipart/mixed; boundary="8DOKuFLizFbw5qklLtgD17CIGj4QXVKXe"; protected-headers="v1" From: Bryan Drewery To: Kevin Oberman , Gary Jennejohn Cc: current@freebsd.org Message-ID: Subject: Re: error building clang in HEAD References: <20180623154048.1b228df0@ernst.home> <196E84B3-B58F-4296-B6EA-84D0DE3230EF@FreeBSD.org> <20180624095747.7384f5bf@ernst.home> <20180626182412.49dce7b0@ernst.home> <20180626200013.247e7927@ernst.home> In-Reply-To: --8DOKuFLizFbw5qklLtgD17CIGj4QXVKXe Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 6/26/2018 12:40 PM, Kevin Oberman wrote: > On Tue, Jun 26, 2018 at 11:00 AM, Gary Jennejohn > wrote: >=20 > On Tue, 26 Jun 2018 18:24:12 +0200 > Gary Jennejohn >= > wrote: >=20 > > On Mon, 25 Jun 2018 11:28:18 -0700 > > Bryan Drewery wrote: > > > > > On 6/24/2018 12:57 AM, Gary Jennejohn wrote:=C2=A0 > > > > On Sat, 23 Jun 2018 17:05:16 +0200 > > > > Dimitry Andric wrote: > > > >=C2=A0 =C2=A0 =C2=A0 > > > >> On 23 Jun 2018, at 15:40, Gary Jennejohn > > wrote:=C2=A0 =C2= =A0 > > > >>> > > > >>> There is a strange error building clang with this use case:= > > > >>> > > > >>> cd /usr/src > > > >>> make -j10 makeworld=C2=A0 =C2=A0 =C2=A0 > > > >> > > > >> What's the "makeworld" target?=C2=A0 I've not heard of this.= > > > >>=C2=A0 =C2=A0 > > > > > > > > A typo.=C2=A0 I meant buildowrld. > > > >=C2=A0 =C2=A0 =C2=A0 > > > >>> which produces this error output: > > > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 > > > >>> =3D=3D=3D> lib/clang/libclang (all)=C2=A0 =C2=A0 =C2=A0 > > > >>> error: unable to rename temporary > 'Sema/SemaTemplate-12ad7e30.o.tmp' to output file > 'Sema/SemaTemplate.o': 'No such file or directory' > > > >>> 1 error generated. > > > >>> --- Sema/SemaTemplate.o --- > > > >>> *** [Sema/SemaTemplate.o] Error code 1=C2=A0 =C2=A0 =C2=A0 > > > >> > > > >> This typically happens if "make obj" was not run before the > rest of the > > > >> make targets.=C2=A0 Normally, the order is: make obj, then m= ake > depend, then > > > >> make (a.k.a. make all). > > > >> > > > >> Is there a directory /usr/obj/usr/src/lib/libclang/Sema ? > > > >>=C2=A0 =C2=A0 > > > > > > > > Well, I would hope/expect that make buildworld does make obj.= > > > > > > > > Yes, the directory was there. > > > >=C2=A0 =C2=A0 =C2=A0 > > > > > > Actually neither 'make obj' nor 'make depend' is done or needed= > anymore > > > in buildworld. > > > > > > The directory above is incorrect, please check for > > > > > >=C2=A0 =C2=A0 =C2=A0/usr/obj/usr/src/amd64.amd64/lib/clang/libcl= ang/Sema > > >=C2=A0 =C2=A0 > > > > Well, now everything is there because I ran a buildworld without = -j. > > > > > Do you have another Makefile or script that is executing > > > buildworld for you? > > >=C2=A0 =C2=A0 > > > > No, I use a bash alias named mw: > > mw is aliased to `pushd /usr/src;time make -s -j$NCPU buildworld;= popd' > > > > NCPU is defined as 10. > > > > > What's in your src.conf and make.conf? > > >=C2=A0 =C2=A0 > > > > The only changes I made recently were to /etc/src.conf when I add= ed: > > > > WITHOUT_LLVM_TARGET_AARCH64=3Dyes > > WITHOUT_LLVM_TARGET_ARM=3Dys > > WITHOUT_LLVM_TARGET_MIPS=3Dyes > > WITHOUT_LLVM_TARGET_POWERPC=3Dyes > > WITHOUT_LLVM_TARGET_SPARC=3Dyes > > WITH_LLVM_TARGET_X86=3Dyes > > > > Otherwise, I haven't touched src.conf or make.conf in=C2=A0 a lon= g time. > > >=20 > I removed some old cruft from src.conf and now make -j10 buildworld= is > succeeding, even after rm -rf /usr/obj/usr. >=20 > Thanks for pointing me in the right direction. >=20 > --=20 > Gary Jennejohn >=20 >=20 > I'd like to hear what triggered this as removing unneeded LLVM targets > seems like a good idea if you know that you won't need them. Building I don't think the options are related to the build error. > LLVM takes a long time on my 7+ year old, memory constrained (8G) > system. Anything that reduces that time would be nice. By the way, before these options get out of hand... I am adding a new WITHOUT_LLVM_TARGET_ALL option to more easily disable unneeded targets which will be simpler for user maintenance. And I am going to make buildworld automatically disable unneeded targets for the bootstrap compiler. For the installed compiler it will still default to all targets. If targets are disabled then SYSTEM_COMPILER logic will fail when cross-building and you will need to build another bootstrap compiler. Something to keep in mind. > -- > Kevin Oberman, Part time kid herder and retired Network Engineer > E-mail: rkoberman@gmail.com > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 >=20 --=20 Regards, Bryan Drewery --8DOKuFLizFbw5qklLtgD17CIGj4QXVKXe-- --MtssKEg8nXaW6ThhZOMVzbThXoweEwzeD 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 iQEcBAEBAgAGBQJbMplBAAoJEDXXcbtuRpfP3KQH/AxQYtzxOgY+Ep/MTXgVw8K1 6xpZ3X4m6VcpRXv8WBI09QhknggSXxw5eFJ+lo36myFT7UsHrA6F10w4pXWK/aTA XiiA9fBvwfwiBF7AuQWS/hZklmSGB3PHNcCk0JE4+3mcbi8j8wdMiYAIqNY7u/wU f7JjmFwGMHjgvgwKesvsd78kEngzH41kjIxxZzJEWNMlppYgYUF0wX/3Q8+TFNal U9dClhcVQBsmJX0/ZNez6U/k2F1z0ym/L9JO+xHu+xT/IbcbbGPWHHobZ8GtGLdH gncWF1dxzeFsrkEnuUQUGWC+TtIYeg4HRYkDJ53U+2fI3uyJQXV5lFwmBzr/St8= =XXJ9 -----END PGP SIGNATURE----- --MtssKEg8nXaW6ThhZOMVzbThXoweEwzeD-- From owner-freebsd-current@freebsd.org Tue Jun 26 20:50: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 439091019B8A for ; Tue, 26 Jun 2018 20:50:43 +0000 (UTC) (envelope-from lars@gustik.eu) Received: from madarka.gustik.eu (madarka.gustik.eu [IPv6:2a01:4f8:150:80b1:fe57:f772:524c:99d0]) (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 D645783AFA for ; Tue, 26 Jun 2018 20:50:42 +0000 (UTC) (envelope-from lars@gustik.eu) Received: from romy.j20.helspy.pw (unknown [IPv6:2a01:c844:106d:4420:df9b:a36f:cb77:f65e]) by madarka.gustik.eu (Postfix) with ESMTPSA id EBFB015A08 for ; Tue, 26 Jun 2018 22:50:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gustik.eu; s=mail; t=1530046234; bh=1pJnWHbLWIJpkMstHbIlQ+dCCV2OMyoka6UIf0HeYMA=; h=Date:From:To:Subject:In-Reply-To:References; b=mgsVF5tnTmouLEi8tt+gAmZkd+AFQxoeMk56UbeN3ziwfOlormh2atMAoTz9bFI4J KFngIAYI8YXwlnT+bSdzQ/ovrDV6CM1xSRn6WFx8euFR/xnlw6uLTMrlczAOJAhGMO YYwMFC9eDC4CtLgmC6NYGtUKU2ukFFwO9FiyCM8c= Date: Tue, 26 Jun 2018 22:50:31 +0200 From: Lars Schotte To: freebsd-current@freebsd.org Subject: Re: svn commit: r335399: . . . head/sys/security/mac_veriexec/ . . . breaks ci.freebsg.org builds of FreeBSD-head-{armv6,ar,m7,i386,mips,powerpc,powerpcspe}-build Message-ID: <20180626225031.224e81f8@romy.j20.helspy.pw> In-Reply-To: <16300ECA-4991-40B9-94CB-9579B3F19245@yahoo.com> References: <16300ECA-4991-40B9-94CB-9579B3F19245@yahoo.com> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.31; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 26 Jun 2018 20:50:43 -0000 Yes, add amd64 to it. I get install: mac_veriexec.ko: No such file or directory when I do installkernel. On Tue, 19 Jun 2018 19:33:17 -0700 Mark Millard wrote: > Stephen J. Kiernan stevek at FreeBSD.org > Wed Jun 20 00:41:33 UTC 2018 > > > Author: stevek > Date: Wed Jun 20 00:41:30 2018 > New Revision: 335399 > URL: > https://svnweb.freebsd.org/changeset/base/335399 > > > Log: > MAC/veriexec implements a verified execution environment using the > MAC framework. > > . . . > > > But the logs on ci.freebsd.prg show for -r335399 and later for > FreeBSD-head-{armv6,ar,m7,i386,mips,powerpc,powerpcspe}-build > messages like: > > > --- all_subdir_mac_veriexec --- > cc1: warnings being treated as errors > /usr/src/sys/security/mac_veriexec/veriexec_fingerprint.c: In > function > 'identify_error': /usr/src/sys/security/mac_veriexec/veriexec_fingerprint.c:115: > warning: format '%lu' expects type 'long unsigned int', but argument > 5 has type > 'dev_t' [-Wformat] /usr/src/sys/security/mac_veriexec/veriexec_fingerprint.c:115: > warning: format '%lu' expects type 'long unsigned int', but argument > 6 has type 'ino_t' [-Wformat] . . . --- all_subdir_mac_veriexec --- > *** [veriexec_fingerprint.o] Error code 1 > > And, as a result, those builds fail on ci.freebsd.org . > > Basically the 32-bit architectures fail and the 64-bit > ones do not (for the same code). > > > I've not checked the later *veriex* related check-ins: > > -r335400 > -r335401 > -r335402 > > for possible similar problems. > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > > _______________________________________________ > 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" -- Lars Schotte Mudroňova 13 92101 PieÅ¡Å¥any From owner-freebsd-current@freebsd.org Tue Jun 26 20:54: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 CAA40101A038 for ; Tue, 26 Jun 2018 20:54:05 +0000 (UTC) (envelope-from lars@gustik.eu) Received: from madarka.gustik.eu (madarka.gustik.eu [IPv6:2a01:4f8:150:80b1:fe57:f772:524c:99d0]) (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 6853683F76 for ; Tue, 26 Jun 2018 20:54:05 +0000 (UTC) (envelope-from lars@gustik.eu) Received: from romy.j20.helspy.pw (unknown [IPv6:2a01:c844:106d:4420:df9b:a36f:cb77:f65e]) by madarka.gustik.eu (Postfix) with ESMTPSA id EEDDF15A09 for ; Tue, 26 Jun 2018 22:54:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gustik.eu; s=mail; t=1530046444; bh=mtUKQPn0IhO0H8DxEwtXi6+ledEMbGYmLGI+uPLSzpg=; h=Date:From:To:Subject; b=FyednMmXUW2c2dg64wyj5MNm4Pf0OIc7y7NbwJ8l8zwfKk/edI0qUgwO1oAVPs81p j8sSDc2zxuy4hwn1fGON1IutCjBxyckHUK9rdDvnhZYxp8HtsYiOsF0FGYsZuhD5w/ SYWrIKETVZEMU2OeWSt8bvSbzmhab89+fhaDHvhM= Date: Tue, 26 Jun 2018 22:54:03 +0200 From: Lars Schotte To: FreeBSD Current Subject: make installworld fails on install: process-control: No such file or directory Message-ID: <20180626225403.7971b68d@romy.j20.helspy.pw> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.31; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 26 Jun 2018 20:54:06 -0000 make installworld fails on install: process-control: No such file or directory somewhere around Revision: 335679 of ^/head. -- Lars Schotte Mudroňova 13 92101 PieÅ¡Å¥any From owner-freebsd-current@freebsd.org Tue Jun 26 21:08: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 7CA0F101AC71 for ; Tue, 26 Jun 2018 21:08:11 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::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 C62A9846A6 for ; Tue, 26 Jun 2018 21:08:10 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lj1-x230.google.com with SMTP id i125-v6so9882653lji.2 for ; Tue, 26 Jun 2018 14:08:10 -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=BNaJ3wBqJpCW7TgJzxLto15DUJpUGpzZuvcIxbolQyI=; b=sGutBw30nz9fjYzM31F8vAsHNZhCx4PEzXVNl2DzN1QrzI+vYALsg2RepfKvEb2aLT 0aewzukYUnYetcrKKnx0npyoYh7hXqrCgJPIcaH6qpByUVMnh6Qk3iJNYNTEkX2s6+ja rzZnIZdhjESelWV9KSebHob6TVAzuq5WtvBDUr6JTkL4pTr+9fzdxFrF2B7aaH7GylW2 SH5uUG3tfZ3HxjpBg+JYuFi4uiIr++A04OTclC6B158l6UtjVoBatAFIhoQF6dKJTsPo j2HcdPQPukz0DqYrl/c0u6QKpVcl4GyOuFg6fFaSXbaV0qsyeXRy5uI0FmYqFh+x+ESI kPcQ== 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=BNaJ3wBqJpCW7TgJzxLto15DUJpUGpzZuvcIxbolQyI=; b=VfsiJb1PzCBtnvU/ZbuyX9v7RjlDUWBnTbsW7eoU1uUSf4Bg1ZCEqZZe4e9wFPNEdL gwIZb8bWulvdXIuEtxADONOjf1R1T6/QkBee2W269voof8Jmb/9EXVkkPqVlMVRfcooi iKmb+RhcM6CbMiW5Cs9AaoG5gCdb3BdSt2Um6KkNXN+rf3ZlUGAWgnlPR+T7sNuL/0X1 gZRd5Tz23+ajXD0ASqD2BDMwx9zsOeb1aa59uml7UigdGA28S0m84MW7EDA2fODIaBbM gmqYuWrx7Kvqb/a3ePoBCfJScdRDGwinGduWQU6Bjrqhu4tlWULNSF5SMHi4RhT0V8gP iDYQ== X-Gm-Message-State: APt69E1+Co/oSLFzqq6Ua+YYk1+AcoAqgqg5S+LcOhL1KaTgQnDmGEIE jc0qdWY7sgqxVLAdmTkbovGrkCnUMbFoPQb4Nug= X-Google-Smtp-Source: AAOMgpd5cZsyaKd0go2YVN3N8tQZIT0fc7zGvLjC58IIqqPQnWkVQdzCilO8k94nt83OzIQqiwyXaOBlH1sUALVB0Jw= X-Received: by 2002:a2e:2007:: with SMTP id g7-v6mr2173286ljg.50.1530047289213; Tue, 26 Jun 2018 14:08:09 -0700 (PDT) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 2002:ab3:1e71:0:0:0:0:0 with HTTP; Tue, 26 Jun 2018 14:08:08 -0700 (PDT) In-Reply-To: <20180626225403.7971b68d@romy.j20.helspy.pw> References: <20180626225403.7971b68d@romy.j20.helspy.pw> From: Alan Somers Date: Tue, 26 Jun 2018 15:08:08 -0600 X-Google-Sender-Auth: llX4goh-EZze4rtEzm2SMP1dVDg Message-ID: Subject: Re: make installworld fails on install: process-control: No such file or directory To: Lars Schotte Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 26 Jun 2018 21:08:11 -0000 It works for me (though I didn't do a clean build). Can you please svn up and try again? I'll do a clean build in the meantime. On Tue, Jun 26, 2018 at 2:54 PM, Lars Schotte wrote: > make installworld fails on install: process-control: No such file or > directory somewhere around Revision: 335679 of ^/head. > > -- > Lars Schotte > Mudro=C5=88ova 13 > 92101 Pie=C5=A1=C5=A5any > _______________________________________________ > 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 Jun 26 21:39:44 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 61733101C2A1 for ; Tue, 26 Jun 2018 21:39:44 +0000 (UTC) (envelope-from adrian.chadd@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 EA9BD85727 for ; Tue, 26 Jun 2018 21:39:43 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id A977E101C2A0; Tue, 26 Jun 2018 21:39:43 +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 87152101C29F for ; Tue, 26 Jun 2018 21:39:43 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wr0-x241.google.com (mail-wr0-x241.google.com [IPv6:2a00:1450:400c:c0c::241]) (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 0B1B08571E for ; Tue, 26 Jun 2018 21:39:43 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-wr0-x241.google.com with SMTP id p12-v6so17013368wrn.11 for ; Tue, 26 Jun 2018 14:39:42 -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 :cc; bh=iVk8le+dmd9kbQdhNOjCNs5YAGpnXjZSI4PhFcvnxSw=; b=kJPMbnn2mJXYlncf4Cua+NoMiVxi1KR4W0f1Os2R1LSXRZJX48J3OxvjpBiS5Y0+nV CU5BQhYfbF8E7Kmz1YZXsB6QuF/i6bbVzWZE9YEJ+XXsI9UgJ1bQBhDEC6s3ICZ347xT BEbzuWfwU4qeOYP9zMUZ2GVYeJ9VcbzbabGPBRNYuiavF1slGmze43WDQnXUWqfU1B4n Kcra2YE/mEE49LWzt6FLVdFB5uedGRRG04tGsGF9qL3rDb7GbRH4cf4w5oY3vLPSZCAy 0TAqIEPBP2IO03iA7WkIatNhxkLc3M528thBRTm+rI6V1O7Ma/mSoB58MiJNRFbCVC1j KbKA== 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=iVk8le+dmd9kbQdhNOjCNs5YAGpnXjZSI4PhFcvnxSw=; b=Y5i5e+OdZ869m2ueUpfPMrhslvAEtiTBC4j+Ytok7R+KkLqa3qc/U88Wc4dq8oHgqh Ej64c8kHzl+jBV/X0S6B65rYeer2vmfv9jEFyTQBVWc36Jfw0xRYuJwEBD7ahWgI+84O n7sstPM/FYA22Nq6/fG+KDjA+J6DrIXQqdqRUlyEnz1qfzBRg1yK3b2rKVKPr5B2BTiV gLDZ/kLjj+0kmHN0dOJKdXuG610tVdirWCSYzPO6B9lAA14/emFD/024kNpTtwipYBn+ eOndTTd2t2DiYevK0fipoJZ7LFsiQq7tuiShTTlj6KgkCud9tCcAH7ZaWPfXEYlH2tq2 gZQw== X-Gm-Message-State: APt69E1RVPQZERWFut4cgibKYsTLj4+2J3EbQW4lLwjX64ww+SILP41q dV7jMI9S7p5lFoviCQJ8wYhv/jRVc4oGrHKR7gvn/A== X-Google-Smtp-Source: AAOMgpdasW7sdrdOGvOTL9gvc1DZJmHieiVId3S+UsHsrkeNMBLrALCMEhYu3iHviiZhRZuOYeptX0AD+c1PwJ330t0= X-Received: by 2002:adf:acc3:: with SMTP id o61-v6mr2979555wrc.34.1530049181915; Tue, 26 Jun 2018 14:39:41 -0700 (PDT) MIME-Version: 1.0 References: <20180624120329.Horde.HWORumQ7Ng1KAUeviJNtoc3@webmail.leidinger.net> <20180625182250.GA40651@troutmask.apl.washington.edu> In-Reply-To: <20180625182250.GA40651@troutmask.apl.washington.edu> From: Adrian Chadd Date: Tue, 26 Jun 2018 14:39:27 -0700 Message-ID: Subject: Re: numa involved in instability and swap usage despite RAM free? To: Steve Kargl Cc: Alexander Leidinger , "current@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 26 Jun 2018 21:39:44 -0000 Hi, Aren't there now per-domain VM counters you can query via sysctl? Maybe they'd help in diagnosing what's going on. -adrian On Mon, 25 Jun 2018 at 11:23, Steve Kargl wrote: > > On Sun, Jun 24, 2018 at 12:03:29PM +0200, Alexander Leidinger wrote: > > > > I don't have hard evidence, but there is enough "smell" to open up a > > discussion... > > > > Short: > > Can it be that enabling numa in the kernel is the reason why some > > people see instability with zfs and usage of swap while a lot of free > > RAM is available? > > Interesting observation. I do have NUMA in my kernel, and swap > seems to be used instead of recycling freeing inactive memory. > Top shows > > Mem: 506M Active, 27G Inact, 98M Laundry, 2735M Wired, 1474M Buf, 1536M Free > Swap: 16G Total, 120M Used, 16G Free > > Perhaps, I don't understand what is meant by inactive memory. I > thought that this means memory is still available in the buffer > cache, but nothing is current using what is there. > > -- > Steve > _______________________________________________ > 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 Jun 26 22:23: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 9F2D9101E36A for ; Tue, 26 Jun 2018 22:23:00 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) 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 3F71D86F42 for ; Tue, 26 Jun 2018 22:23:00 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: by mailman.ysv.freebsd.org (Postfix) id 0026C101E369; Tue, 26 Jun 2018 22:23:00 +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 E2112101E367 for ; Tue, 26 Jun 2018 22:22:59 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7434A86F41 for ; Tue, 26 Jun 2018 22:22:59 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id w5QMMqpJ030276 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 26 Jun 2018 15:22:52 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id w5QMMq9E030275; Tue, 26 Jun 2018 15:22:52 -0700 (PDT) (envelope-from sgk) Date: Tue, 26 Jun 2018 15:22:51 -0700 From: Steve Kargl To: Adrian Chadd Cc: Alexander Leidinger , "current@freebsd.org" Subject: Re: numa involved in instability and swap usage despite RAM free? Message-ID: <20180626222251.GA30202@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20180624120329.Horde.HWORumQ7Ng1KAUeviJNtoc3@webmail.leidinger.net> <20180625182250.GA40651@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 26 Jun 2018 22:23:00 -0000 On Tue, Jun 26, 2018 at 02:39:27PM -0700, Adrian Chadd wrote: > On Mon, 25 Jun 2018 at 11:23, Steve Kargl > wrote: > > > > On Sun, Jun 24, 2018 at 12:03:29PM +0200, Alexander Leidinger wrote: > > > > > > I don't have hard evidence, but there is enough "smell" to open up a > > > discussion... > > > > > > Short: > > > Can it be that enabling numa in the kernel is the reason why some > > > people see instability with zfs and usage of swap while a lot of free > > > RAM is available? > > > > Interesting observation. I do have NUMA in my kernel, and swap > > seems to be used instead of recycling freeing inactive memory. > > Top shows > > > > Mem: 506M Active, 27G Inact, 98M Laundry, 2735M Wired, 1474M Buf, 1536M Free > > Swap: 16G Total, 120M Used, 16G Free > > > > Perhaps, I don't understand what is meant by inactive memory. I > > thought that this means memory is still available in the buffer > > cache, but nothing is current using what is there. > > > > Aren't there now per-domain VM counters you can query via sysctl? > Maybe they'd help in diagnosing what's going on. > I upgraded to a r335642 yesterday. I haven't seen the swapping problem, yet; although I've tried to force it. There are 158 sysctl knobs that contain the string "vm". Do you have a pointer any particular one to monitor? -- Steve From owner-freebsd-current@freebsd.org Tue Jun 26 23:36: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 6A2351021A49 for ; Tue, 26 Jun 2018 23:36:36 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::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 ACB2789DDB; Tue, 26 Jun 2018 23:36:35 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lf0-x22c.google.com with SMTP id n96-v6so124118lfi.1; Tue, 26 Jun 2018 16:36:35 -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=f6nFdu/zLVq1pYCPnhhwHoG4VOg9lgVYqArs5MJjtAk=; b=rnF8xr+RUQV08Kpx2gWpu3/jMJgJHqQK+UzxgZbqRfpLYsVe/qYgqSpQ7t5TXoOneQ 1vHmKAt3yV2S9s1ZuF4NRfF37KdphxCVOdYXDleAnmeRpV3pinI6QKVPiTSmU5IUgjrC 7q1Uz+ALUtIevmGCAyiS8zW/8hvkz2bjObutngB3Fdx4xZyyKzso2xMf3uno8mHOyA5K DYv9/pfXzQpP+WjFvh/2Wl5OxHeSdizMurmtZ6xtCXvT9Tji7mJEb0/ztvva4p97AN3E i3uDuusL9+8sfp+FVOIL9m+oJq+PW0F1pjnmw5+91UzVo4eMJnUt/lF3jEUGnQVJ6MOD IzXw== 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=f6nFdu/zLVq1pYCPnhhwHoG4VOg9lgVYqArs5MJjtAk=; b=hLAzPFQwa9bXfEa2Ts6d6X2IeZQCw3GFM7Gms+27NK2IMvHJZHZSozG2QXhqJrFxnX Wydxw6RJVMzAh6HNqoCKqg1i0jKHgpU+0GHo0mt/dzwibmhTOi+STL1GGKAA3GkbnmFT Tk8XjpYV058R3sYyAu8VrmYVi9uNgzcqBjAA3n9IOj+vSM8TzKxY5zFmkDA7isGA1DDt lABw+MyLHjzZu1FdRMoFkin6cgWxaH8xZw/8f0i4gwkeglPDX3zfxdbMDvp3g1wd6qIY dSUVv86Rvr/8350fVx8dOa/5F+7aEF45i8yBzvpyWCkSc+p7gHXFS/gm7oQBv2+WVaP+ Yd4Q== X-Gm-Message-State: APt69E2aK/ppNl/8DRPyFLYJ4sYFAYOKhG0hi6ib4TmUQl2egsjMeCv+ bnNKnpHgfm3lHwpol7K4+O9XDTfnuNUQggkf6JA= X-Google-Smtp-Source: AAOMgpfZTxrbh6Lwc4sGz+P3o6WAFubNm0xqvtEUkv3dvNjC/cDYZTgbTtPePig6d5JhrkIybK1x8QFEzrIa4Zq8SGM= X-Received: by 2002:a19:5459:: with SMTP id i86-v6mr2453571lfb.34.1530056194016; Tue, 26 Jun 2018 16:36:34 -0700 (PDT) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 2002:ab3:1b91:0:0:0:0:0 with HTTP; Tue, 26 Jun 2018 16:36:33 -0700 (PDT) In-Reply-To: References: <20180626225403.7971b68d@romy.j20.helspy.pw> From: Alan Somers Date: Tue, 26 Jun 2018 17:36:33 -0600 X-Google-Sender-Auth: gES9bxfyTW6ucGkqj2l94PR3mc4 Message-ID: Subject: Re: make installworld fails on install: process-control: No such file or directory To: Alan Somers Cc: Lars Schotte , FreeBSD Current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 26 Jun 2018 23:36:36 -0000 Still works for me with a clean build. Is it still failing for you? On Tue, Jun 26, 2018 at 3:08 PM, Alan Somers wrote: > It works for me (though I didn't do a clean build). Can you please svn u= p > and try again? I'll do a clean build in the meantime. > > > On Tue, Jun 26, 2018 at 2:54 PM, Lars Schotte wrote: > >> make installworld fails on install: process-control: No such file or >> directory somewhere around Revision: 335679 of ^/head. >> >> -- >> Lars Schotte >> Mudro=C5=88ova 13 >> 92101 Pie=C5=A1=C5=A5any >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.or= g >> " >> > > From owner-freebsd-current@freebsd.org Wed Jun 27 01:05: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 C405C1025699 for ; Wed, 27 Jun 2018 01:05:11 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670060.outbound.protection.outlook.com [40.107.67.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT TLS CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 367828C623; Wed, 27 Jun 2018 01:05:11 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM (52.132.44.24) by YTOPR0101MB1034.CANPRD01.PROD.OUTLOOK.COM (52.132.48.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.884.23; Wed, 27 Jun 2018 01:05:09 +0000 Received: from YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM ([fe80::d0eb:3783:7c99:2802]) by YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM ([fe80::d0eb:3783:7c99:2802%4]) with mapi id 15.20.0884.024; Wed, 27 Jun 2018 01:05:09 +0000 From: Rick Macklem To: Konstantin Belousov CC: "freebsd-current@freebsd.org" , Alexander Motin , Doug Rabson Subject: Re: nfsd kernel threads won't die via SIGKILL Thread-Topic: nfsd kernel threads won't die via SIGKILL Thread-Index: AQHUCzMbOoi8yQKY7UygDXm1hs0B0KRvJmwAgAESAI+AAT8WAIAB0vQT Date: Wed, 27 Jun 2018 01:05:09 +0000 Message-ID: References: <20180624093330.GX2430@kib.kiev.ua> , <20180625205614.GI2430@kib.kiev.ua> In-Reply-To: <20180625205614.GI2430@kib.kiev.ua> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YTOPR0101MB1034; 7:guW5+4fmPAY511uKfx/3B9o0ApBTwAEu6CKI5Up7S9yd67xZhANkY8kSPyU93N8oVMcwvHxJaazyBjNYBKQ6Soxt1bdGixNVQMoxWpqUCL7ROSVt1JYKLA+TTGIeSV3cuJHd5YT8rfnaYtFHUwFkgRHR0Lj7kFManln8qiIb1fzThWMyz3ZTlR5bRucPmtiPnlCseqQKon7J9yQ4ItpBlr4slmdeAPaM2IBSvr5ZuLGq18fknXmBcHOJVZryIo/m x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: c31c7be4-661f-4ca4-ef40-08d5dbca0773 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600026)(711020)(2017052603328)(7153060)(7193020); SRVR:YTOPR0101MB1034; x-ms-traffictypediagnostic: YTOPR0101MB1034: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231254)(944501410)(52105095)(149027)(150027)(6041310)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123564045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:YTOPR0101MB1034; BCL:0; PCL:0; RULEID:; SRVR:YTOPR0101MB1034; x-forefront-prvs: 0716E70AB6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(136003)(39860400002)(396003)(366004)(376002)(199004)(189003)(86362001)(99286004)(25786009)(53936002)(6436002)(4326008)(6246003)(97736004)(6916009)(26005)(1411001)(81156014)(81166006)(76176011)(74482002)(478600001)(68736007)(186003)(486006)(33656002)(102836004)(256004)(14444005)(786003)(446003)(11346002)(54906003)(6506007)(316002)(229853002)(55016002)(476003)(105586002)(2900100001)(93886005)(5250100002)(106356001)(7696005)(39060400002)(5660300001)(14454004)(9686003)(8936002)(305945005)(74316002)(2906002)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:YTOPR0101MB1034; H:YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-microsoft-antispam-message-info: pdE3NmDz8873WPIpCV/DY+QXz0DFi6JUov0RuhMrNoAeUKfrdRtHiaHPMgpDGO2YR8pt5nvlAFRIN7EUtO9Eb34HYj/WZX0vaK1ngZo5kgEwxghh2jXM/7TGx2CRLf4mrxgT2HM0CracoKpollu7Go91kewYnxfCtlSDIUcax/TlKpbrSjv7VM+hEbJuuRTRkAiB8fiI0D+QRGaKfhx+BjTqVcDlfd8geS9sVFLRIfR+rVavh5rrTsP1uSIC20GzCESz3bj00fhRtDymlMqLdhrmBy+wGcHZtuLJDc5LVnJy+oEVYGbWR00GxNTyc64Fn2F+tnPcdTSW4bV9VC82n7GA4TA2vNyIvKCo2kGwq/U= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-Network-Message-Id: c31c7be4-661f-4ca4-ef40-08d5dbca0773 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jun 2018 01:05:09.6277 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTOPR0101MB1034 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 27 Jun 2018 01:05:12 -0000 Konstantin Belousov wrote: On Mon, Jun 25, 2018 at 02:04:32AM +0000, Rick Macklem wrote: > Konstantin Belousov wrote: > >On Sat, Jun 23, 2018 at 09:03:02PM +0000, Rick Macklem wrote: > >> During testing of the pNFS server I have been frequently killing/resta= rting the nfsd. > >> Once in a while, the "slave" nfsd process doesn't terminate and a "ps = axHl" shows: > >> 0 48889 1 0 20 0 5884 812 svcexit D - 0:00.01 nfsd= : server > >> 0 48889 1 0 40 0 5884 812 rpcsvc I - 0:00.00 nfsd= : server > >> ... more of the same > >> 0 48889 1 0 40 0 5884 812 rpcsvc I - 0:00.00 nfsd= : server > >> 0 48889 1 0 -8 0 5884 812 rpcsvc I - 1:51.78 nfsd= : server > >> 0 48889 1 0 -8 0 5884 812 rpcsvc I - 2:27.75 nfsd= : server > >> > >> You can see that the top thread (the one that was created with the pro= cess) is > >> stuck in "D" on "svcexit". > >> The rest of the threads are still servicing NFS RPCs. [lots of stuff snipped] >Signals are put onto a signal queue between a time where the signal is >generated until the thread actually consumes it. I.e. the signal queue >is a container for the signals which are not yet acted upon. There is >one signal queue per process, and one signal queue for each thread >belonging to the process. When you signal the process, the signal is >put into some thread' signal queue, where the only criteria for the >selection of the thread is that the signal is not blocked. Since >SIGKILL is never blocked, it is put anywhere. > >Until signal is delivered by cursig()/postsig() loop, typically at the >AST handler, the only consequence of its presence are the EINTR/ERESTART >errors returned from the PCATCH-enabled sleeps. Ok, now I think I understand how this works. Thanks a lot for the explanati= on. > >Your description at the start of the message of the behaviour after > >SIGKILL, where other threads continued to serve RPCs, exactly matches > >above explanation. You need to add some global 'stop' flag, if it is not I looked at the code and there is already basically a "global stop flag". It's done by setting the sg_state variable to CLOSING for all thread groups in a function called svc_exit(). (I missed this when I looked before, so I didn't understand how all the threads normally terminate.) So, when I looked at svc_run_internal(), there is a loop while (state !=3D = closing) that calls cv_wait_sig()/cv_timedwait_sig() and when these return EINTR/ERE= START the call to svc_exit() is done to make the threads all return from the func= tion. --> The only way in can get into the broken situation I see sometimes is if= the top thread (called "ismaster" by the code) somehow returns from svc_run_internal() without calling svc_exit(), so that the state isn'= t set to "closing". Turns out there is only one place this can happen. It's this line: if (grp->sg_threadcount > grp->sg_maxthreads) break; I wouldn't have thought that sg_threadcount would have become ">" tha= n sg_maxthreads, but when I looked at the output of "ps" that I pasted = into the first message, there are 33 threads. (When I started the nfsd, I = specified 32 threads, so I think it did the "break;" at this place to get out o= f the loop and return from svc_run_internal() without calling svc_exit().) I think changing the above line to: if (!ismaster && grp->sg_threadcount > grp->sg_maxthre= ads) will fix it. I'll test this and see if I can get it to fail. Thanks again for your help, rick From owner-freebsd-current@freebsd.org Wed Jun 27 04:52: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 8E24B102E9C5 for ; Wed, 27 Jun 2018 04:52:10 +0000 (UTC) (envelope-from FreeBSD@shaneware.biz) 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 2913793D32 for ; Wed, 27 Jun 2018 04:52:10 +0000 (UTC) (envelope-from FreeBSD@shaneware.biz) Received: by mailman.ysv.freebsd.org (Postfix) id D39AB102E9BC; Wed, 27 Jun 2018 04:52: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 C2064102E9BB for ; Wed, 27 Jun 2018 04:52:09 +0000 (UTC) (envelope-from FreeBSD@shaneware.biz) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [150.101.137.129]) by mx1.freebsd.org (Postfix) with ESMTP id 0943B93D2E for ; Wed, 27 Jun 2018 04:52:08 +0000 (UTC) (envelope-from FreeBSD@shaneware.biz) Received: from ppp118-210-121-130.bras2.adl4.internode.on.net (HELO leader.local) ([118.210.121.130]) by ipmail06.adl2.internode.on.net with ESMTP; 27 Jun 2018 14:21:59 +0930 Subject: Re: numa involved in instability and swap usage despite RAM free? Cc: "current@freebsd.org" References: <20180624120329.Horde.HWORumQ7Ng1KAUeviJNtoc3@webmail.leidinger.net> <20180625182250.GA40651@troutmask.apl.washington.edu> <20180626222251.GA30202@troutmask.apl.washington.edu> From: Shane Ambler Message-ID: Date: Wed, 27 Jun 2018 14:21:57 +0930 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180626222251.GA30202@troutmask.apl.washington.edu> 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.26 Precedence: 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, 27 Jun 2018 04:52:10 -0000 On 27/06/2018 07:52, Steve Kargl wrote: > On Tue, Jun 26, 2018 at 02:39:27PM -0700, Adrian Chadd wrote: >> On Mon, 25 Jun 2018 at 11:23, Steve Kargl >> wrote: >>> >>> On Sun, Jun 24, 2018 at 12:03:29PM +0200, Alexander Leidinger wrote: >>>> >>>> I don't have hard evidence, but there is enough "smell" to open up a >>>> discussion... >>>> >>>> Short: >>>> Can it be that enabling numa in the kernel is the reason why some >>>> people see instability with zfs and usage of swap while a lot of free >>>> RAM is available? >>> >>> Interesting observation. I do have NUMA in my kernel, and swap >>> seems to be used instead of recycling freeing inactive memory. >>> Top shows >>> >>> Mem: 506M Active, 27G Inact, 98M Laundry, 2735M Wired, 1474M Buf, 1536M Free >>> Swap: 16G Total, 120M Used, 16G Free >From someone that has had memory issues since 10.1 (bug 194654), I have recently realised something that seems to make some sense to me. The arc_max setting is a limit of zfs arc and this ram gets wired to prevent it swapping, this makes sense. The vm.max_wired is a value that I had thought was ignored but now I see that these are two values of wired memory which are not connected. max_wired appears to default to 30% of kmem_size. Both of these values are added together to be reported in vm.stats.vm.v_wire_count which is the wired value shown by top. This appears to be the reason that I can see 9G wired when max_wired is at 5G The implications of this is that together (arc_max + max_wired) can be set to more than the physical installed ram. I can verify that with 8G installed and the two values add up to more than 7G you get no choice but a hard reset. Since upgrading to 16G I have been more vigilant and not allowed more than 10G to be wired so haven't had that problem in a year and a half. With the default arc_max usually set to ram minus 1G and max_wired at 5G it is easy to see that the current defaults are dangerous. I have not seen max_wired mentioned in relation to zfs but it seems that it should be considered when setting arc_max to prevent over wiring ram. Close to three weeks ago I applied review D7538 to my everyday desktop running stable/11. Until a few days ago I had no swap usage which is now at 9M. In the last few years of monitoring wired usage to try and find a solution I have not seen less than 1G of swap usage after an hour of uptime. If nothing else D7538 makes arc more willing to be released. -- FreeBSD - the place to B...Storing Data Shane Ambler From owner-freebsd-current@freebsd.org Wed Jun 27 07:14: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 75148100E687 for ; Wed, 27 Jun 2018 07:14:46 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-wm0-f46.google.com (mail-wm0-f46.google.com [74.125.82.46]) (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 E0DFF7050E for ; Wed, 27 Jun 2018 07:14:45 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-wm0-f46.google.com with SMTP id v16-v6so4508520wmv.5 for ; Wed, 27 Jun 2018 00:14:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:openpgp:autocrypt:message-id :date:user-agent:mime-version:content-language :content-transfer-encoding; bh=VwQbp+An6POsJVQUvFR4ADCo3z90s0Y0337VrxMUzIs=; b=f2qcDVOQljzRDX/LNMPdxpuCdWd6bZIoT6idhHwh7TpyZt0tXeTp1niKfgpVsnuEQI +WxVDqvOZYdcbbi8iwWND8LR30xZxn9OpwQMKKr4JpJ4t75tfFNPFFahrOgtvSyK0J6S qzroCKgCkk8k1IjOs+H8zcTHP0leWhg+ua/bAQgbcifSMvzSTRQi3gui/4u9DFOBdenz SIjsjxPsrBzFxEt64ci2C6mxtRE169QSIsUFxB+Mw5F2Hlx0XppDDNixo7Nx374HHynL 3LjFanT9+ezZ90cl4wu7QvByQb1HeBWvxwjV7fJ/WICoayoHIYM7MQwI4RkIMp81sOXb F7tg== X-Gm-Message-State: APt69E3CKq6QIOiLdZ91PtsiUTDvIhfgtHhNZPkQsjlDxk35bzSI/a1b 6r/TZDSQ1Z6OljHvAkNAKL9/UR/w X-Google-Smtp-Source: AAOMgpc1FNTFa0EH7H3GSaEYuhuPUVujZPRHqPA79g2QfUR4vyNVEzWcnSGA1rc46MtqB2f7S6nQxw== X-Received: by 2002:a1c:5644:: with SMTP id k65-v6mr4130589wmb.50.1530083679018; Wed, 27 Jun 2018 00:14:39 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id f81-v6sm6934343wmh.32.2018.06.27.00.14.37 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Jun 2018 00:14:38 -0700 (PDT) To: FreeBSD Current From: Andriy Gapon Subject: TSC calibration in virtual machines Openpgp: preference=signencrypt Autocrypt: addr=avg@FreeBSD.org; prefer-encrypt=mutual; keydata= xsFNBFm4LIgBEADNB/3lT7f15UKeQ52xCFQx/GqHkSxEdVyLFZTmY3KyNPQGBtyvVyBfprJ7 mAeXZWfhat6cKNRAGZcL5EmewdQuUfQfBdYmKjbw3a9GFDsDNuhDA2QwFt8BmkiVMRYyvI7l N0eVzszWCUgdc3qqM6qqcgBaqsVmJluwpvwp4ZBXmch5BgDDDb1MPO8AZ2QZfIQmplkj8Y6Z AiNMknkmgaekIINSJX8IzRzKD5WwMsin70psE8dpL/iBsA2cpJGzWMObVTtCxeDKlBCNqM1i gTXta1ukdUT7JgLEFZk9ceYQQMJJtUwzWu1UHfZn0Fs29HTqawfWPSZVbulbrnu5q55R4PlQ /xURkWQUTyDpqUvb4JK371zhepXiXDwrrpnyyZABm3SFLkk2bHlheeKU6Yql4pcmSVym1AS4 dV8y0oHAfdlSCF6tpOPf2+K9nW1CFA8b/tw4oJBTtfZ1kxXOMdyZU5fiG7xb1qDgpQKgHUX8 7Rd2T1UVLVeuhYlXNw2F+a2ucY+cMoqz3LtpksUiBppJhw099gEXehcN2JbUZ2TueJdt1FdS ztnZmsHUXLxrRBtGwqnFL7GSd6snpGIKuuL305iaOGODbb9c7ne1JqBbkw1wh8ci6vvwGlzx rexzimRaBzJxlkjNfMx8WpCvYebGMydNoeEtkWldtjTNVsUAtQARAQABzR5BbmRyaXkgR2Fw b24gPGF2Z0BGcmVlQlNELm9yZz7CwZQEEwEIAD4WIQS+LEO7ngQnXA4Bjr538m7TUc1yjwUC WbgsiAIbIwUJBaOagAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRB38m7TUc1yj+JAEACV l9AK/nOWAt/9cufV2fRj0hdOqB1aCshtSrwHk/exXsDa4/FkmegxXQGY+3GWX3deIyesbVRL rYdtdK0dqJyT1SBqXK1h3/at9rxr9GQA6KWOxTjUFURsU7ok/6SIlm8uLRPNKO+yq0GDjgaO LzN+xykuBA0FlhQAXJnpZLcVfPJdWv7sSHGedL5ln8P8rxR+XnmsA5TUaaPcbhTB+mG+iKFj GghASDSfGqLWFPBlX/fpXikBDZ1gvOr8nyMY9nXhgfXpq3B6QCRYKPy58ChrZ5weeJZ29b7/ QdEO8NFNWHjSD9meiLdWQaqo9Y7uUxN3wySc/YUZxtS0bhAd8zJdNPsJYG8sXgKjeBQMVGuT eCAJFEYJqbwWvIXMfVWop4+O4xB+z2YE3jAbG/9tB/GSnQdVSj3G8MS80iLS58frnt+RSEw/ psahrfh0dh6SFHttE049xYiC+cM8J27Aaf0i9RflyITq57NuJm+AHJoU9SQUkIF0nc6lfA+o JRiyRlHZHKoRQkIg4aiKaZSWjQYRl5Txl0IZUP1dSWMX4s3XTMurC/pnja45dge/4ESOtJ9R 8XuIWg45Oq6MeIWdjKddGhRj3OohsltKgkEU3eLKYtB6qRTQypHHUawCXz88uYt5e3w4V16H lCpSTZV/EVHnNe45FVBlvK7k7HFfDDkryM7BTQRZuCyIARAAlq0slcsVboY/+IUJdcbEiJRW be9HKVz4SUchq0z9MZPX/0dcnvz/gkyYA+OuM78dNS7Mbby5dTvOqfpLJfCuhaNYOhlE0wY+ 1T6Tf1f4c/uA3U/YiadukQ3+6TJuYGAdRZD5EqYFIkreARTVWg87N9g0fT9BEqLw9lJtEGDY EWUE7L++B8o4uu3LQFEYxcrb4K/WKmgtmFcm77s0IKDrfcX4doV92QTIpLiRxcOmCC/OCYuO jB1oaaqXQzZrCutXRK0L5XN1Y1PYjIrEzHMIXmCDlLYnpFkK+itlXwlE2ZQxkfMruCWdQXye syl2fynAe8hvp7Mms9qU2r2K9EcJiR5N1t1C2/kTKNUhcRv7Yd/vwusK7BqJbhlng5ZgRx0m WxdntU/JLEntz3QBsBsWM9Y9wf2V4tLv6/DuDBta781RsCB/UrU2zNuOEkSixlUiHxw1dccI 6CVlaWkkJBxmHX22GdDFrcjvwMNIbbyfQLuBq6IOh8nvu9vuItup7qemDG3Ms6TVwA7BD3j+ 3fGprtyW8Fd/RR2bW2+LWkMrqHffAr6Y6V3h5kd2G9Q8ZWpEJk+LG6Mk3fhZhmCnHhDu6CwN MeUvxXDVO+fqc3JjFm5OxhmfVeJKrbCEUJyM8ESWLoNHLqjywdZga4Q7P12g8DUQ1mRxYg/L HgZY3zfKOqcAEQEAAcLBfAQYAQgAJhYhBL4sQ7ueBCdcDgGOvnfybtNRzXKPBQJZuCyIAhsM BQkFo5qAAAoJEHfybtNRzXKPBVwQAKfFy9P7N3OsLDMB56A4Kf+ZT+d5cIx0Yiaf4n6w7m3i ImHHHk9FIetI4Xe54a2IXh4Bq5UkAGY0667eIs+Z1Ea6I2i27Sdo7DxGwq09Qnm/Y65ADvXs 3aBvokCcm7FsM1wky395m8xUos1681oV5oxgqeRI8/76qy0hD9WR65UW+HQgZRIcIjSel9vR XDaD2HLGPTTGr7u4v00UeTMs6qvPsa2PJagogrKY8RXdFtXvweQFz78NbXhluwix2Tb9ETPk LIpDrtzV73CaE2aqBG/KrboXT2C67BgFtnk7T7Y7iKq4/XvEdDWscz2wws91BOXuMMd4c/c4 OmGW9m3RBLufFrOag1q5yUS9QbFfyqL6dftJP3Zq/xe+mr7sbWbhPVCQFrH3r26mpmy841ym dwQnNcsbIGiBASBSKksOvIDYKa2Wy8htPmWFTEOPRpFXdGQ27awcjjnB42nngyCK5ukZDHi6 w0qK5DNQQCkiweevCIC6wc3p67jl1EMFY5+z+zdTPb3h7LeVnGqW0qBQl99vVFgzLxchKcl0 R/paSFgwqXCZhAKMuUHncJuynDOP7z5LirUeFI8qsBAJi1rXpQoLJTVcW72swZ42IdPiboqx NbTMiNOiE36GqMcTPfKylCbF45JNX4nF9ElM0E+Y8gi4cizJYBRr2FBJgay0b9Cp Message-ID: <8ac353c5-d188-f432-aab1-86f4ca5fd295@FreeBSD.org> Date: Wed, 27 Jun 2018 10:14:37 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 27 Jun 2018 07:14:46 -0000 It seems that TSC calibration in virtual machines sometimes can do more harm than good. Should we default to trusting the information provided by a hypervisor? Specifically, I am observing a problem on GCE instances where calibrated TSC frequency is about 10% lower than advertised frequency. And apparently the advertised frequency is the right one. I found this thread with similar reports and a variety of workarounds from administratively disabling the calibration to switching to a different timecounter: https://lists.freebsd.org/pipermail/freebsd-cloud/2017-January/000080.html -- Andriy Gapon From owner-freebsd-current@freebsd.org Wed Jun 27 07:28:04 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 23D57100F6D1 for ; Wed, 27 Jun 2018 07:28:04 +0000 (UTC) (envelope-from gljennjohn@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 98DA9710C1 for ; Wed, 27 Jun 2018 07:28:03 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 58CFB100F6CF; Wed, 27 Jun 2018 07:28:03 +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 312A7100F6CD for ; Wed, 27 Jun 2018 07:28:03 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::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 7D1CF710BE; Wed, 27 Jun 2018 07:28:02 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wr0-x22c.google.com with SMTP id k16-v6so907133wro.0; Wed, 27 Jun 2018 00:28:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=xMsivK14KZQYNWPlkf6ny5kBFwOtjd+ySY7QEvelPY8=; b=UnFo8G0/q9WEPJBcLd57dEizfj1Ivz6EDed003e52Zod3YR5cmbRJvQTdSmIoEY8Ue tArE50YZGI2HLR8Ejl1oaA4naFx95x4djEXrQ4wstVBQ3Bkg4iZVVUfj+1t9Dj0NyOqs mTMB9kSCApbZfZ6lQa4fgTDSiNqVmHNrPLk2RQKkPV2Fx3MULDYPl2eaQnviRfi7WnVs NwqXCvw+rzlpSwV8mz0mjnYkIJmu275FM/5BPsbqlRmZPEMUN+NeuM6REiWmbtbYvZV7 YO9PQAKoRru8mqt+fEPxYFBgbuQqRKMXZxiamZH50xudiC4SIMR06+okQCiwuFvNe67e R8ng== 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:reply-to:mime-version:content-transfer-encoding; bh=xMsivK14KZQYNWPlkf6ny5kBFwOtjd+ySY7QEvelPY8=; b=nFkXFLOGguMGMKhvHtAzcb1gZpidCHfqXRZwLG9FNUHnJ2HW9PwZyyJ5HQ7G34dGDd AXug4o7U3APthQXM5vFt/TuLOWm2hk7LdfuZp3GDGzSSpTlAC/pKADattcgSu8uxJ+RJ N/4NyJkUvvXB+InRogWANcFbRF8Ewo8wHSqjzetAXg2ZmoqpFAkwCFZZCle5vXN3RdFL q4QmHKzB6QU5PuwsmSeyoHybMKx78haMzj9NgElb4+ZlCg9MWhV7g32/GyXPsLshANEw 9Lh3jwos0idHGNM/8kCDF2Lk25bXbH+bCKh8cmMDlHmUO4kgz5L1b8x6ELC5dlMupYT2 Rl4A== X-Gm-Message-State: APt69E0kn22xYUsheNOtmw/Q2pH2oV7x2u527y5OWaaPOXFtcCngrqXc ImkzCHF6sxUUUOSYDBcNj0OrFA== X-Google-Smtp-Source: AAOMgpexIDCQefrtRz3NR+vyZqspeIBk5j0SXdUMOC7e88KO0VDjKi5VvTTbtXLsjwF0s03nb29iLA== X-Received: by 2002:adf:9a0b:: with SMTP id z11-v6mr3966087wrb.47.1530084481374; Wed, 27 Jun 2018 00:28:01 -0700 (PDT) Received: from ernst.home (p5B0234B4.dip0.t-ipconnect.de. [91.2.52.180]) by smtp.gmail.com with ESMTPSA id a184-v6sm4118764wmf.30.2018.06.27.00.28.00 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 27 Jun 2018 00:28:00 -0700 (PDT) Date: Wed, 27 Jun 2018 09:27:59 +0200 From: Gary Jennejohn To: Bryan Drewery Cc: Kevin Oberman , current@freebsd.org Subject: Re: error building clang in HEAD Message-ID: <20180627092759.3fe84eca@ernst.home> In-Reply-To: References: <20180623154048.1b228df0@ernst.home> <196E84B3-B58F-4296-B6EA-84D0DE3230EF@FreeBSD.org> <20180624095747.7384f5bf@ernst.home> <20180626182412.49dce7b0@ernst.home> <20180626200013.247e7927@ernst.home> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.16.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.26 Precedence: 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, 27 Jun 2018 07:28:04 -0000 On Tue, 26 Jun 2018 12:51:29 -0700 Bryan Drewery wrote: > On 6/26/2018 12:40 PM, Kevin Oberman wrote: > > On Tue, Jun 26, 2018 at 11:00 AM, Gary Jennejohn > > wrote: > > > > On Tue, 26 Jun 2018 18:24:12 +0200 > > Gary Jennejohn > > > wrote: > > > > > On Mon, 25 Jun 2018 11:28:18 -0700 > > > Bryan Drewery wrote: > > > > > > > On 6/24/2018 12:57 AM, Gary Jennejohn wrote:__ > > > > > On Sat, 23 Jun 2018 17:05:16 +0200 > > > > > Dimitry Andric wrote: > > > > >__ __ __ > > > > >> On 23 Jun 2018, at 15:40, Gary Jennejohn > > > wrote:__ __ > > > > >>> > > > > >>> There is a strange error building clang with this use case: > > > > >>> > > > > >>> cd /usr/src > > > > >>> make -j10 makeworld__ __ __ > > > > >> > > > > >> What's the "makeworld" target?__ I've not heard of this. > > > > >>__ __ > > > > > > > > > > A typo.__ I meant buildowrld. > > > > >__ __ __ > > > > >>> which produces this error output: > > > > >>>__ __ __ __ > > > > >>> ===> lib/clang/libclang (all)__ __ __ > > > > >>> error: unable to rename temporary > > 'Sema/SemaTemplate-12ad7e30.o.tmp' to output file > > 'Sema/SemaTemplate.o': 'No such file or directory' > > > > >>> 1 error generated. > > > > >>> --- Sema/SemaTemplate.o --- > > > > >>> *** [Sema/SemaTemplate.o] Error code 1__ __ __ > > > > >> > > > > >> This typically happens if "make obj" was not run before the > > rest of the > > > > >> make targets.__ Normally, the order is: make obj, then make > > depend, then > > > > >> make (a.k.a. make all). > > > > >> > > > > >> Is there a directory /usr/obj/usr/src/lib/libclang/Sema ? > > > > >>__ __ > > > > > > > > > > Well, I would hope/expect that make buildworld does make obj. > > > > > > > > > > Yes, the directory was there. > > > > >__ __ __ > > > > > > > > Actually neither 'make obj' nor 'make depend' is done or needed > > anymore > > > > in buildworld. > > > > > > > > The directory above is incorrect, please check for > > > > > > > >__ __ __/usr/obj/usr/src/amd64.amd64/lib/clang/libclang/Sema > > > >__ __ > > > > > > Well, now everything is there because I ran a buildworld without -j. > > > > > > > Do you have another Makefile or script that is executing > > > > buildworld for you? > > > >__ __ > > > > > > No, I use a bash alias named mw: > > > mw is aliased to `pushd /usr/src;time make -s -j$NCPU buildworld;popd' > > > > > > NCPU is defined as 10. > > > > > > > What's in your src.conf and make.conf? > > > >__ __ > > > > > > The only changes I made recently were to /etc/src.conf when I added: > > > > > > WITHOUT_LLVM_TARGET_AARCH64=yes > > > WITHOUT_LLVM_TARGET_ARM=ys > > > WITHOUT_LLVM_TARGET_MIPS=yes > > > WITHOUT_LLVM_TARGET_POWERPC=yes > > > WITHOUT_LLVM_TARGET_SPARC=yes > > > WITH_LLVM_TARGET_X86=yes > > > > > > Otherwise, I haven't touched src.conf or make.conf in__ a long time. > > > > > > > I removed some old cruft from src.conf and now make -j10 buildworld is > > succeeding, even after rm -rf /usr/obj/usr. > > > > Thanks for pointing me in the right direction. > > > > I'd like to hear what triggered this as removing unneeded LLVM targets > > seems like a good idea if you know that you won't need them. Building > > I don't think the options are related to the build error. > Correct, these options were not the cause of the errors. I had some really old options from several years ago which were the cause. Don't remeber now exactly which ones, but they were all related to using CLANG instead of GCC. -- Gary Jennejohn From owner-freebsd-current@freebsd.org Wed Jun 27 10:46: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 4A8C2101AA5A for ; Wed, 27 Jun 2018 10:46:39 +0000 (UTC) (envelope-from danfe@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 F37AE773F9; Wed, 27 Jun 2018 10:46:38 +0000 (UTC) (envelope-from danfe@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1033) id E9C4B178F7; Wed, 27 Jun 2018 10:46:38 +0000 (UTC) Date: Wed, 27 Jun 2018 10:46:38 +0000 From: Alexey Dokuchaev To: Mark Johnston Cc: Kevin Lo , Lev Serebryakov , gljennjohn@gmail.com, FreeBSD current Subject: Re: swapping is completely broken in -CURRENT r334649? Message-ID: <20180627104638.GA15311@FreeBSD.org> References: <20180605181716.73b8ea91@ernst.home> <2925b27f-43cf-8813-eaa7-4f3d12bef8f0@FreeBSD.org> <20180605214808.GA94301@pesky> <20180615051025.GA79327@ns.kevlo.org> <20180615084022.GA32922@pesky.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180615084022.GA32922@pesky.lan> User-Agent: Mutt/1.9.5 (2018-04-13) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 27 Jun 2018 10:46:39 -0000 On Fri, Jun 15, 2018 at 04:40:22AM -0400, Mark Johnston wrote: > ... > The change was committed as r334752. Are you seeing unexpected OOM > kills on or after that revision? I've just discovered this thread. I've updated my -CURRENT desktop ca. June 4th and my X.org session crashes within several minutes. This is on i386 system with 4G RAM. I cannot get SVN revision of that kernel because something got broken and it was not embedded in the image. :-( Rebooting with kernel="kernel.old" from May 12th made this problem go away. Is the root cause is known at this time? Which revision shall I try to see whether it does not exhibit this bug any longer? Thanks, ./danfe From owner-freebsd-current@freebsd.org Wed Jun 27 11:56: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 DD534101F0BB for ; Wed, 27 Jun 2018 11:56:37 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-ed1-x544.google.com (mail-ed1-x544.google.com [IPv6:2a00:1450:4864:20::544]) (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 583A779A78; Wed, 27 Jun 2018 11:56:37 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-ed1-x544.google.com with SMTP id b12-v6so2915510edt.8; Wed, 27 Jun 2018 04:56:37 -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=i6CaoBhIG2TFxY/UHvJEQl5eT53cmPttmw/fPDjlqKE=; b=hB8Ctzk8t67tI+/K9ChJcN5csMjqmQ/rqsVtayjLAW9fW9r0Uf/FsSZGJWoDHQOxJO OoNKz9Op0KoRj9u+dXdJeg/ZTFhlnuAE6yvsypyRbXoxfASkiORJhVINVTeipPP6j+yq LFcR7Enc5r8WSXGrTcwnd7XuQ1J08pZqvXuyGVx0gtYsYwo/Hwm7n/IiCiEsaTruai6j LP5cDgMhvqfCfiiHMwQOXo5eDXTZLaI80hcpFXgEKHxH0EAuitGJuhV8S7d0WOfHY/Hx qK3/JzEjBcS2yL2HCVjCQK2Qg7qEOxS1G6OMQFu1TZ/hZJicCAR+jwCRkW0jQYzE9WtR NyGA== 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=i6CaoBhIG2TFxY/UHvJEQl5eT53cmPttmw/fPDjlqKE=; b=iHcgwckEp+9CQsw39HdSwEsFAF7HENpYMTyVFgssYg3Ou9rg/d6QjjKdbgWncg+pL0 vEJTW/xuYwyXjrta67w7DcVAIn1UgbPShRau1maMpgqzIj5c2QNBuijoCGV5EcAFpUE2 hXC7WEYKizpe5/zsWBY4APtDH+X9eVnzOlMdzJRJODQuZIHUpEHUg03+mdcQugdjDLh3 WHudZGidm4D3iqDH0XJBgWQ1UDI+l/9H03llJ/o3cj4H/a9cZ5P8RaR5CPhPA3XUQcYK a9E484Hz8ZLMihmQeZDoGZABqG9c57QyrlYBoKQZdgdeJX/NYGZGkc7xhnA+uEIzhdm+ ZMAA== X-Gm-Message-State: APt69E2KT3Usoxrh0Oirj9Twlgm0qVBAbFMjoJcPK1ngy4ts1nOaIeVW Vx5hXq7z07i/fu3qhjBvx7difA== X-Google-Smtp-Source: AAOMgpd3a4S3Kq722uFDmL2SEo0/ZXhULrSQUoLbLxB1D89rUDkBo9IlM+Fw1hoFkhl2MEAUKHP2xw== X-Received: by 2002:aa7:d84a:: with SMTP id f10-v6mr5459623eds.157.1530100596213; Wed, 27 Jun 2018 04:56:36 -0700 (PDT) Received: from pesky (dhcp-077-251-153-140.chello.nl. [77.251.153.140]) by smtp.gmail.com with ESMTPSA id h16-v6sm1651563ede.66.2018.06.27.04.56.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Jun 2018 04:56:35 -0700 (PDT) Sender: Mark Johnston Date: Wed, 27 Jun 2018 07:55:26 -0400 From: Mark Johnston To: Alexey Dokuchaev Cc: Kevin Lo , Lev Serebryakov , gljennjohn@gmail.com, FreeBSD current Subject: Re: swapping is completely broken in -CURRENT r334649? Message-ID: <20180627115526.GA52468@pesky> References: <20180605181716.73b8ea91@ernst.home> <2925b27f-43cf-8813-eaa7-4f3d12bef8f0@FreeBSD.org> <20180605214808.GA94301@pesky> <20180615051025.GA79327@ns.kevlo.org> <20180615084022.GA32922@pesky.lan> <20180627104638.GA15311@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180627104638.GA15311@FreeBSD.org> User-Agent: Mutt/1.10.0 (2018-05-17) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 27 Jun 2018 11:56:38 -0000 On Wed, Jun 27, 2018 at 10:46:38AM +0000, Alexey Dokuchaev wrote: > On Fri, Jun 15, 2018 at 04:40:22AM -0400, Mark Johnston wrote: > > ... > > The change was committed as r334752. Are you seeing unexpected OOM > > kills on or after that revision? > > I've just discovered this thread. I've updated my -CURRENT desktop ca. > June 4th and my X.org session crashes within several minutes. This is > on i386 system with 4G RAM. > > I cannot get SVN revision of that kernel because something got broken > and it was not embedded in the image. :-( > > Rebooting with kernel="kernel.old" from May 12th made this problem go > away. Is the root cause is known at this time? Which revision shall > I try to see whether it does not exhibit this bug any longer? Thanks, As noted earlier in the thread, r329882 introduced a problem where out-of-memory kills were taking place despite an abundance of free pages and swap space. That bug was fixed in r334752. If you are seeing a problem that is fixed in a kernel from May 12th, then it is possibly unrelated to this bug, but it is worth testing r334752 or later to confirm. From owner-freebsd-current@freebsd.org Wed Jun 27 15:32: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 CE9741029BCD for ; Wed, 27 Jun 2018 15:32:46 +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 7372B82EBC; Wed, 27 Jun 2018 15:32:46 +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 62AC010AFD4; Wed, 27 Jun 2018 11:32:45 -0400 (EDT) Subject: Re: TSC calibration in virtual machines To: Andriy Gapon , FreeBSD Current References: <8ac353c5-d188-f432-aab1-86f4ca5fd295@FreeBSD.org> From: John Baldwin Message-ID: <729d4477-3c68-e3db-2ebc-0bd4deba61cd@FreeBSD.org> Date: Wed, 27 Jun 2018 08:32:44 -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: <8ac353c5-d188-f432-aab1-86f4ca5fd295@FreeBSD.org> 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, 27 Jun 2018 11:32:45 -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.26 Precedence: 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, 27 Jun 2018 15:32:47 -0000 On 6/27/18 12:14 AM, Andriy Gapon wrote: > > It seems that TSC calibration in virtual machines sometimes can do more harm > than good. Should we default to trusting the information provided by a hypervisor? > > Specifically, I am observing a problem on GCE instances where calibrated TSC > frequency is about 10% lower than advertised frequency. And apparently the > advertised frequency is the right one. > > I found this thread with similar reports and a variety of workarounds from > administratively disabling the calibration to switching to a different timecounter: > https://lists.freebsd.org/pipermail/freebsd-cloud/2017-January/000080.html I suspect you are probably right that we should just "trust" TSC frequencies provided by a hypervisor. We could perhaps choose to whitelist hypervisors known to provide accurate values if we wanted to be cautious. -- John Baldwin From owner-freebsd-current@freebsd.org Wed Jun 27 16:36: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 02C05102BF7C for ; Wed, 27 Jun 2018 16:36:50 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 99521850A8; Wed, 27 Jun 2018 16:36:49 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from freefall.freebsd.org (static-71-168-218-4.cmdnnj.fios.verizon.net [71.168.218.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jkim/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 6FB601EC1F; Wed, 27 Jun 2018 16:36:49 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Subject: Re: TSC calibration in virtual machines To: Andriy Gapon , FreeBSD Current References: <8ac353c5-d188-f432-aab1-86f4ca5fd295@FreeBSD.org> From: Jung-uk Kim Openpgp: preference=signencrypt Autocrypt: addr=jkim@FreeBSD.org; prefer-encrypt=mutual; keydata= xsBNBFJBztUBCAChqNyGqmFuNo0U7MBzsD+q/G6Cv0l7LGVrOAsgh34M8wIWhD+tztDWMVfn AhxNDd0ceCj2bYOe67sTQxAScEcbt2FfvPOLp9MEXb9qohZj172Gwkk7dnhOhZZKhVGVZKM4 NcsuBDUzgf4f3Vdzj4wg6WlqplnTZo8lPE4hZWvZHoFIyunPTJWenybeV1xnxK7JkUdSvQR0 fA59RfTTECMwTrSEfYGUnxIDBraxJ7Ecs/0hGQ7sljIj8WBvlRDU5fU1xfF35aw56T8POQRq F4E6RVJW3YGuTpSwgtGZOTfygcLRhAiq3dFC3JNLaTVTpM8PjOinJyt9AU6RoITGOKwDABEB AAHNHkp1bmctdWsgS2ltIDxqa2ltQEZyZWVCU0Qub3JnPsLAfQQTAQoAJwUCUkHO1QIbAwUJ E0/POwULCQgHAwUVCgkICwUWAgMBAAIeAQIXgAAKCRB8n5Ym/NvxRqyzB/wL7QtsIpeGfGIA ZPMtgXMucM3NWzomyQMln2j2efUkDKthzh9jBxgF53TjOr7imwIt0PT2k1bqctPrq5IRqnu9 mGroqaCLE3LG2/E3jEaao4k9PO6efwlioyivUo5NrqIQOQ4k3EAXw7d2y0Dk1VpTgdMrnUAB hj7lGlLqS4ydcrf24DdbCRGdEQwqd9DBeBgbWynxAJMgbZBhYVEyIHuQKkJ8qY0ibIPXXuF0 KYDeH0qUHtWV2K3srNyPtymUkBQD84Pl1GWRYx05XdUHDmnX0JV3lg0BfYJZgZv0ehPQrMfY Fd9abTkf9FHQYz1JtsC8wUuRgqElRd6+YAGf8Tt9zsBNBFJBztUBCADLtSrP44El2VoJmH14 OFrlOgxzZnbn+Y/Gf1k12mJBiR+A+pBeRLD50p7AiTrjHRxO3cHcl9Dh0uf1VSbXgp8Or0ye iP/86fZPd4k5HXNmDTLL0HecPE08SCqGZ0W8vllQrokB1QxxRUB+fFMPJyMCjDAZ7P9fFTOS dTw1bJSTtOD8Sx8MpZUa9ti06bXFlVYDlaqSdgk181SSx+ZbSKkQR8CIMARlHwiLsa3Z9q9O EJr20HPyxe0AlTvwvFndH61hg7ds63eRvglwRnNON28VXO/lvKXq7Br/CiiyhFdKfINIx2Z5 htYq22tgGTW7mBURbIKoECFBTX9Lv6BXz6w9ABEBAAHCwGUEGAEKAA8FAlJBztUCGwwFCRNP zzsACgkQfJ+WJvzb8UZcJQf+IsTCxUEqY7W/pT84sMg5/QD3s6ufTRncvq14fEOxCNq1Rf4Q 9P+tOFa8GZfKDGB2BFGIrW7uT5mlmKdK1vO6ZIA930y5kUsnCmBUEBJkE2ciSQk01aB/1o62 Q3Gk/F6BwtNY9OXiqF7AcAo+K/BMIaqb26QKeh+IIgK1NN9dQiq3ByTbl4zpGZa6MmsnnRTu mzGKt2nkz7vBzH6+hZp1OzGZikgjjhYWVFoJo1dvf/rv4obs0ZJEqFPQs/1Qa1dbkKBv6odB XJpPH0ssOluTY24d1XxTiKTwmWvHeQkOKRAIfD7VTtF4TesoZYkf7hsh3e3VwXhptSLFnEOi WwYofg== Message-ID: <4d7957f6-9497-19ff-4dbb-436bb6b05a56@FreeBSD.org> Date: Wed, 27 Jun 2018 12:36:42 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <8ac353c5-d188-f432-aab1-86f4ca5fd295@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="i3db1n5AU0SP87SkKIjI4GhC9VJU1zR7S" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 27 Jun 2018 16:36:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --i3db1n5AU0SP87SkKIjI4GhC9VJU1zR7S Content-Type: multipart/mixed; boundary="DE1LZOkh9kxFql1fzPsgzKkQJkdJC3Vej"; protected-headers="v1" From: Jung-uk Kim To: Andriy Gapon , FreeBSD Current Message-ID: <4d7957f6-9497-19ff-4dbb-436bb6b05a56@FreeBSD.org> Subject: Re: TSC calibration in virtual machines References: <8ac353c5-d188-f432-aab1-86f4ca5fd295@FreeBSD.org> In-Reply-To: <8ac353c5-d188-f432-aab1-86f4ca5fd295@FreeBSD.org> --DE1LZOkh9kxFql1fzPsgzKkQJkdJC3Vej Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 06/27/2018 03:14, Andriy Gapon wrote: >=20 > It seems that TSC calibration in virtual machines sometimes can do more= harm > than good. Should we default to trusting the information provided by a= hypervisor? >=20 > Specifically, I am observing a problem on GCE instances where calibrate= d TSC > frequency is about 10% lower than advertised frequency. And apparently= the > advertised frequency is the right one. >=20 > I found this thread with similar reports and a variety of workarounds f= rom > administratively disabling the calibration to switching to a different = timecounter: > https://lists.freebsd.org/pipermail/freebsd-cloud/2017-January/000080.h= tml We already do that for VMware hosts since r221214. https://svnweb.freebsd.org/changeset/base/221214 We should do the same for each hypervisor. Jung-uk Kim --DE1LZOkh9kxFql1fzPsgzKkQJkdJC3Vej-- --i3db1n5AU0SP87SkKIjI4GhC9VJU1zR7S Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEl1bqgKaRyqfWXu/CfJ+WJvzb8UYFAlszvSAACgkQfJ+WJvzb 8UYU2Af+Ou3jz23pGMgvsQ4gUbdS2znHEvu7mD/z70iyKwg8+MHivYR7dw06yLzn VKPHsttg/TyJFcRqi60U1kIMzJkdbngiQ65bxwzm/TCAeLIbFWaxga/tYwfBvroP 9pTBq1G7wghktAXYpDWRVlNeKdrLx595auOTU/BRiLlV72q8aU7SxnqZkNACmvna rff3USaZa8OVWo/YfFLH2PdZlT5+rpgkP1b4gR/wWoZLjQy87Ko+dNrMTrqNKe9T 3SyHj3tJJsUs/X1Zi9YMD2C7s7AdTXKLJ1RuL4bN1TkF4v3pUltO5ZjK45Sm/pvH KLJ6ySjth5xhW06RNqMiQgPQu75veQ== =oUJ2 -----END PGP SIGNATURE----- --i3db1n5AU0SP87SkKIjI4GhC9VJU1zR7S-- From owner-freebsd-current@freebsd.org Wed Jun 27 16:47: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 181A2102C645 for ; Wed, 27 Jun 2018 16:47:54 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::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 59AAE8597D; Wed, 27 Jun 2018 16:47:53 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lf0-x236.google.com with SMTP id a4-v6so2063023lff.5; Wed, 27 Jun 2018 09:47:53 -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=91vUDIaS2seBYYXwfzS3lGRpmRtB5+QD2NLGtHKUce4=; b=RM4bLObw1R5LWVtfq7WyDKejYAod1yImopscSnyZtOghFs/Vy6tA8D4v7CEc4woxPj zrgcT2nkabw9BbOAc0mTPxbAapo90PvZQ0cllk/ud5xSR8Oy3OU1baKZltd/Es90mU2Y nPRoqh/Gt/IMuzhun/1c7XdqDC3NHdKwMEfpFp5r4G63dTR9r9TO8xSWfec0ytnOF/vt VgDVXdE049dL1klp6CwrKCqY862ENAc5Owx2f3tRsij2Ob9V7JxMHaqAVNVu8OCmgbdz PwANwvxWpP+FtcPK/JlKop2G8+mbUsS3nBfXlRf+uEBoJv0vyFErhdnkPxGcgRib5lL5 +0Ww== 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=91vUDIaS2seBYYXwfzS3lGRpmRtB5+QD2NLGtHKUce4=; b=qzjLiKoALa+1klauX4KhgKqaoGplg3l5c+xndX49n+sjgqm983PaWKsq61asp56Y71 4r96qJu7v4wsC0PRlzszh/MLR1rL5hoGVpdOgqM04mTGVteGGVF4Lvnn7px3HGjCdYNe Kb/zyQDSLDxr9MWml027KxQ7Hx1RYFE91Xw/VjPeckgRLKPTI9CExzsWfDS13/FeZFrm R5y2HQnevhRLmJPfMLMLyE5FvY4/rCo1fu7oU78QJEAvKrfKZyMBUrjxznLpG3VU/v5J KZK6kTWuPe7iObHael4euauo28CEVWK65G4Z420y582mP6Ya2UuVvXNteNt7dfdvf5J7 jx+A== X-Gm-Message-State: APt69E3/8IIWL3tiRB7Nc45tPEfLqF5Ho/i8ns2xRrqAfVRQgSLBlnO6 tOr77An2Y931J/Tm13iUruzHc/BJ8V0jBnTrobs= X-Google-Smtp-Source: AAOMgpdWO6YI/jrLnS3I32K4U+rkRVH3ssMCTyknYLJXTjgPSFzlM5cX+wXayVjqK8sOTYOojba6kgaXT+A0bmdWFdA= X-Received: by 2002:a19:385a:: with SMTP id d26-v6mr4996565lfj.47.1530118071491; Wed, 27 Jun 2018 09:47:51 -0700 (PDT) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 2002:ab3:1b91:0:0:0:0:0 with HTTP; Wed, 27 Jun 2018 09:47:50 -0700 (PDT) In-Reply-To: <4d7957f6-9497-19ff-4dbb-436bb6b05a56@FreeBSD.org> References: <8ac353c5-d188-f432-aab1-86f4ca5fd295@FreeBSD.org> <4d7957f6-9497-19ff-4dbb-436bb6b05a56@FreeBSD.org> From: Alan Somers Date: Wed, 27 Jun 2018 10:47:50 -0600 X-Google-Sender-Auth: uCVjQOJuJlSuyZnCc6AXRRds9aQ Message-ID: Subject: Re: TSC calibration in virtual machines To: Jung-uk Kim Cc: Andriy Gapon , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 27 Jun 2018 16:47:54 -0000 On Wed, Jun 27, 2018 at 10:36 AM, Jung-uk Kim wrote: > On 06/27/2018 03:14, Andriy Gapon wrote: > > > > It seems that TSC calibration in virtual machines sometimes can do more > harm > > than good. Should we default to trusting the information provided by a > hypervisor? > > > > Specifically, I am observing a problem on GCE instances where calibrated > TSC > > frequency is about 10% lower than advertised frequency. And apparently > the > > advertised frequency is the right one. > > > > I found this thread with similar reports and a variety of workarounds > from > > administratively disabling the calibration to switching to a different > timecounter: > > https://lists.freebsd.org/pipermail/freebsd-cloud/2017- > January/000080.html > > We already do that for VMware hosts since r221214. > > https://svnweb.freebsd.org/changeset/base/221214 > > We should do the same for each hypervisor. > > Jung-uk Kim > > We probably should. But why does calibration fail in the first place? If it can fail in a VM, then it can probably fail on bare metal too. It would be worth investigating. From owner-freebsd-current@freebsd.org Wed Jun 27 17:01: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 C5F7D102D2A4 for ; Wed, 27 Jun 2018 17:01:36 +0000 (UTC) (envelope-from bdrewery@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 3EC5586D18 for ; Wed, 27 Jun 2018 17:01:36 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id ECE36102D2A0; Wed, 27 Jun 2018 17:01:35 +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 CA254102D29F; Wed, 27 Jun 2018 17:01:35 +0000 (UTC) (envelope-from bdrewery@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 70EF586D16; Wed, 27 Jun 2018 17:01:35 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (unknown [127.0.1.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 4F8111DB3A; Wed, 27 Jun 2018 17:01:35 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 07F149672; Wed, 27 Jun 2018 17:01:34 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id ZbYlKDuXjsRr; Wed, 27 Jun 2018 17:01:31 +0000 (UTC) To: "current@freebsd.org" DKIM-Filter: OpenDKIM Filter v2.10.3 mail.xzibition.com 5C9A1966D Cc: FreeBSD Toolchain From: Bryan Drewery Subject: Build updates Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Autocrypt: addr=bdrewery@FreeBSD.org; prefer-encrypt=mutual; keydata= xsBNBFJphmsBCADiFgmS4bIzwZijrS31SjEMzg+n5zNellgM+HkShwehpqCiyhXdWrvH6dTZ a6u50pbUIX7doTR7W7PQHCjCTqtpwvcj0eulZva+iHFp+XrbgSFHn+VVXgkYP2MFySyZRFab D2qqzJBEJofhpv4HvY6uQI5K99pMqKr1Z/lHqsijYYu4RH2OfwB5PinId7xeldzWEonVoCr+ rfxzO/UrgA6v/3layGZcKNHFjmc3NqoN1DXtdaEHqtjIozzbndVkH6lkFvIpIrI6i5ox8pwp VxsxLCr/4Musd5CWgHiet5kSw2SzNeA8FbxdLYCpXNVu+uBACEbCUP+CSNy3NVfEUxsBABEB AAHNJEJyeWFuIERyZXdlcnkgPGJkcmV3ZXJ5QEZyZWVCU0Qub3JnPsLAgAQTAQoAKgIbAwUL CQgHAwUVCgkICwUWAwIBAAIeAQIXgAIZAQUCWujOIgUJCmB7NwAKCRA113G7bkaXz/xpB/9b /UWIPbieY1IeIuHF2pyYPE7Hytkh3HVsxMA0F5Ma2AYQsXZZeKNKWrF7RPyDyDwUklLHJkhm k3EfClBbHxf08kMIm1vWCJRtgxic9knY/bzYGiWMpHjg3cSd1XfrYH1autYqTZAjDwIkgOjU dR//Tbn4V36sY7y2jz+kdMVWvK53U32aZqiwBbCn4DPe1wSZcUs17mV/0uZdIoGdj74B1orN A/0py5vHYo6HcbBNoaR8pKRLf5VZNRsxqGIMhTucx4SJWcHpuRBWYyvJSFzwvxdK4ZD4Yqoc kFGPVtOXktVMai9exrLvP3G77fKMu8DI6j4QRU4wCesnHuIfRPFuzsBNBFJphmsBCACiVFPf kNfaFtUSuY0395ueo/rMyHPGPQ2iwvERFCpeFGSQSgagpenNHLpFQKTg/dl6FOoST5tqyxMq fyHGHDzzU51bvA/IfaGoNi/BIhTe/toZNMRvpcI3PLjiGcnJnuwCCbAVOAGdb+t5cZtpNdOI cKYmrYG3u9RiBpe6dTF+qLrD/8Bs1wjhduQ8fcNNgnkXu8xDH4ZxY0lIc3QgvYWp9vimlQe6 iKjUd2/DX28ETZcD5h6pYV331KMPTrEI0p0yvFijUZce8c1XHFyL1j9sBAha5qpszJl6Uq5i LolhKRcGfcdmtD72vHQjUYglUyudSJUVyo2gMYjdbiFKzJulABEBAAHCwGUEGAEKAA8CGwwF AlrozigFCQpgez0ACgkQNddxu25Gl8+m5Af/R3VEdxNMAcDIes9ADhQyofj20SPV3eCJ3HYR OebTSuNdOudGt4AAyA8Ks94u9hiIp5IGsc6RDsT9W7O2vgXhd6eV3eiY5Oif5xLIYrIDVu1Y 1GyRxRrPEn/QOqDN6uFZCPwK1aOapGcYCrO9lB0gMuTVfgHanU61rgC9tMX0OoAOyRd+V3/M 8lDNhjJdF/IpO3SdYzKfkwduy4qamw4Gphcx/RfYQvYLq/eDkP8d50PphWdboqWBwNRHayro W/07OGzfxM5fJ5mBsXPQcO2QcRjkyHf6xCM6Hi1qQL4OnXMNE/ZTX0lnOj1/pH93TlzSHZMP TaiiA/MBD3vGsXBmBg== Organization: FreeBSD Message-ID: <168e5fec-2d38-78e1-6aa4-c51e860ffd55@FreeBSD.org> Date: Wed, 27 Jun 2018 10:01:31 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ivcbCxvMIvGjxTzN3ZuVIzLY8vhXnF8e3" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 27 Jun 2018 17:01:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ivcbCxvMIvGjxTzN3ZuVIzLY8vhXnF8e3 Content-Type: multipart/mixed; boundary="nEwayV8hkKBhe6Ow34RSpuktd8Ui4SoSY"; protected-headers="v1" From: Bryan Drewery To: "current@freebsd.org" Cc: FreeBSD Toolchain Message-ID: <168e5fec-2d38-78e1-6aa4-c51e860ffd55@FreeBSD.org> Subject: Build updates --nEwayV8hkKBhe6Ow34RSpuktd8Ui4SoSY Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable As of r335704: - make tinderbox/universe will now build the bootstrap clang *once*. Each target clang is still build of course. This support does not work with gcc. - make buildworld (kernel-toolchain and toolchain) will build the bootstrap clang (if needed per SYSTEM_COMPILER logic) with only the TARGET.TARGET_ARCH backend support. The installed clang has all still so SYSTEM_COMPILER logic works for cross-compling. This uses the feature dim@ added in r335558 to selectively disable LLVM targets. I've added a new option named WITH[OUT]_LLVM_TARGET_ALL which I suggest using rather than the per-arch options. It is default on (WITH). Set WITHOUT to only build the needed native arch on your system for both bootstrap and compiled clang. Setting WITHOUT disables SYSTEM_COMPILER support for cross-builds. Please CC me directly for any weird tinderbox/universe or clang failures for the next few weeks. --=20 Regards, Bryan Drewery --nEwayV8hkKBhe6Ow34RSpuktd8Ui4SoSY-- --ivcbCxvMIvGjxTzN3ZuVIzLY8vhXnF8e3 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 iQEcBAEBAgAGBQJbM8LrAAoJEDXXcbtuRpfP9ToH/iq/SMoFoTGcOji/EQj9wudK nJUHYq8jxoQyT5n1jw3qje4QSsXV600sEQiPFiI5STxnGcr+boK1x1gsCEzm6uBx wxNuCS1YHSn8gXZhF1iLKtni8l0wxCnocuTU59tIF6yiI4lLnrcONALUFvahzq3f +9ZqxYz79R6QlUSz0kjdss5b6iaU/tCfUTeR6DxRoQFfVAeh7SInWQiC7ivtbhhc BOWg72A/2DW4kSNfiVZ2NZr5FzLDsMIovMPNgZyTbB6jlmluHUsAa06MbkCtOW/z k+W865SbparsM1/JiCu1VvatxkCS574PCOjmSmEy5/YernCP9T7Epq5ZG9SvzuM= =ZuNL -----END PGP SIGNATURE----- --ivcbCxvMIvGjxTzN3ZuVIzLY8vhXnF8e3-- From owner-freebsd-current@freebsd.org Wed Jun 27 17:01: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 74BDA102D2EC for ; Wed, 27 Jun 2018 17:01:51 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::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 DF80186D71; Wed, 27 Jun 2018 17:01:50 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: by mail-lj1-x22e.google.com with SMTP id k20-v6so2205587ljk.9; Wed, 27 Jun 2018 10:01:50 -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 :cc; bh=oHNwFFksmr+oCYpiEzBRksB0VwxWb3n9mcWn6pUVRs8=; b=MNhwSVpZdHnCwG82WPv0lyRiJmP7qIwUttxYjUuVTquJKFWiPDZMW+yY/jx/4dtpie 9Ab3Uwb15PllsGAUkpP9JjgCIRn0q36fG5S2s2K/kp7S3z3ls0g2zeUd9JijyqRR9GEu WGm5zZuDaMwGQse05YG7+ZLt8pGhAokRWLK7LIjmIYCX5R+EQ71BGG3cSEdhYwHmeVvv a0egpr1xEPH93TGaTMaBxV7XNOk9fwdgQ4sm/v/cGGqW5qHjvtGfk9p7H3twmttR8pZK T8qBr6HgxPg0Asz8TLmD85JtnxlUOSmlS1JYRXWf2CfqJIT35FE31+plDqn/SwDCTpQj qh2Q== 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=oHNwFFksmr+oCYpiEzBRksB0VwxWb3n9mcWn6pUVRs8=; b=nIF239iQ+oYIUhu39hePsbWkThEKnxIz26kljxa2GizudESV8Usva3u5SVwcYOMlPE kbGcgsqVDNh07kNQ2nLM1qDpR4U/xr8oNfz+D6HbkIR+O2QhJgGQz0yTPfbluJQcQ9C3 E1UJBMTunb7jVeuUNUiwUYoqas3ESoLjY/n4hzsdHusiopzTiBNq6f3pLX+ncHtpM5z2 r4LjZRXcy0folKv9K8XjwBpKYaAcehjJFLybrWHm4DLKd8PV8B078f2V129/JvWPZriq c1ygWOfqmyjFzYSw7J1GkiHQQj1mbXNowthDfd34M71pyCfff/Hh48EcDNmMQxRqyW+x 30OQ== X-Gm-Message-State: APt69E0OQBT1FNX0gIZSKCHidPD4ZGqVdZcDeHjsVm2OIWPPPMIyrgRw Y5oQ7MdgcAVgrfEFwPUzknDBBRqI91yZjCrrJTM= X-Google-Smtp-Source: ADUXVKIEGhAxHpmWDA9iADvyyf7OnNVBzgc8IZlsmr3rEkHnNaJ4McIrCax8PHqYV4F0HmOXc1FYHoJU1IvI7znroxc= X-Received: by 2002:a2e:2d11:: with SMTP id t17-v6mr4574477ljt.145.1530118909322; Wed, 27 Jun 2018 10:01:49 -0700 (PDT) MIME-Version: 1.0 References: <8ac353c5-d188-f432-aab1-86f4ca5fd295@FreeBSD.org> <4d7957f6-9497-19ff-4dbb-436bb6b05a56@FreeBSD.org> In-Reply-To: From: Ryan Stone Date: Wed, 27 Jun 2018 13:01:40 -0400 Message-ID: Subject: Re: TSC calibration in virtual machines To: Alan Somers Cc: jkim@freebsd.org, Andriy Gapon , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 27 Jun 2018 17:01:51 -0000 I would guess that the calibration can fail because when running under the hypervisor, the FreeBSD guest code can be descheduled at the wrong time. As I recall, the current algorithm looks like: 1. Sample rdtsc 2. Use a fixed-frequency timer to busy-wait for exactly 1 second 3. Sample rdtsc again 4. tsc_freq = sample2 - sample1; If we are descheduled between 2 and 3, the time we spend off-cpu will not be accounted for at step 4. On bare-metal this is not possible as neither the scheduler nor interrupts are not running yet. Although, come to think of it, I seem to recall something about SMI interrupts mucking this up long in the past, for exactly the same reason. From owner-freebsd-current@freebsd.org Wed Jun 27 17:05:16 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 E92A8102D63B for ; Wed, 27 Jun 2018 17:05:15 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8B93C871C3; Wed, 27 Jun 2018 17:05:15 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from freefall.freebsd.org (static-71-168-218-4.cmdnnj.fios.verizon.net [71.168.218.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jkim/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 5100B1EF2C; Wed, 27 Jun 2018 17:05:15 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Subject: Re: TSC calibration in virtual machines To: Alan Somers Cc: Andriy Gapon , FreeBSD Current References: <8ac353c5-d188-f432-aab1-86f4ca5fd295@FreeBSD.org> <4d7957f6-9497-19ff-4dbb-436bb6b05a56@FreeBSD.org> From: Jung-uk Kim Openpgp: preference=signencrypt Autocrypt: addr=jkim@FreeBSD.org; prefer-encrypt=mutual; keydata= xsBNBFJBztUBCAChqNyGqmFuNo0U7MBzsD+q/G6Cv0l7LGVrOAsgh34M8wIWhD+tztDWMVfn AhxNDd0ceCj2bYOe67sTQxAScEcbt2FfvPOLp9MEXb9qohZj172Gwkk7dnhOhZZKhVGVZKM4 NcsuBDUzgf4f3Vdzj4wg6WlqplnTZo8lPE4hZWvZHoFIyunPTJWenybeV1xnxK7JkUdSvQR0 fA59RfTTECMwTrSEfYGUnxIDBraxJ7Ecs/0hGQ7sljIj8WBvlRDU5fU1xfF35aw56T8POQRq F4E6RVJW3YGuTpSwgtGZOTfygcLRhAiq3dFC3JNLaTVTpM8PjOinJyt9AU6RoITGOKwDABEB AAHNHkp1bmctdWsgS2ltIDxqa2ltQEZyZWVCU0Qub3JnPsLAfQQTAQoAJwUCUkHO1QIbAwUJ E0/POwULCQgHAwUVCgkICwUWAgMBAAIeAQIXgAAKCRB8n5Ym/NvxRqyzB/wL7QtsIpeGfGIA ZPMtgXMucM3NWzomyQMln2j2efUkDKthzh9jBxgF53TjOr7imwIt0PT2k1bqctPrq5IRqnu9 mGroqaCLE3LG2/E3jEaao4k9PO6efwlioyivUo5NrqIQOQ4k3EAXw7d2y0Dk1VpTgdMrnUAB hj7lGlLqS4ydcrf24DdbCRGdEQwqd9DBeBgbWynxAJMgbZBhYVEyIHuQKkJ8qY0ibIPXXuF0 KYDeH0qUHtWV2K3srNyPtymUkBQD84Pl1GWRYx05XdUHDmnX0JV3lg0BfYJZgZv0ehPQrMfY Fd9abTkf9FHQYz1JtsC8wUuRgqElRd6+YAGf8Tt9zsBNBFJBztUBCADLtSrP44El2VoJmH14 OFrlOgxzZnbn+Y/Gf1k12mJBiR+A+pBeRLD50p7AiTrjHRxO3cHcl9Dh0uf1VSbXgp8Or0ye iP/86fZPd4k5HXNmDTLL0HecPE08SCqGZ0W8vllQrokB1QxxRUB+fFMPJyMCjDAZ7P9fFTOS dTw1bJSTtOD8Sx8MpZUa9ti06bXFlVYDlaqSdgk181SSx+ZbSKkQR8CIMARlHwiLsa3Z9q9O EJr20HPyxe0AlTvwvFndH61hg7ds63eRvglwRnNON28VXO/lvKXq7Br/CiiyhFdKfINIx2Z5 htYq22tgGTW7mBURbIKoECFBTX9Lv6BXz6w9ABEBAAHCwGUEGAEKAA8FAlJBztUCGwwFCRNP zzsACgkQfJ+WJvzb8UZcJQf+IsTCxUEqY7W/pT84sMg5/QD3s6ufTRncvq14fEOxCNq1Rf4Q 9P+tOFa8GZfKDGB2BFGIrW7uT5mlmKdK1vO6ZIA930y5kUsnCmBUEBJkE2ciSQk01aB/1o62 Q3Gk/F6BwtNY9OXiqF7AcAo+K/BMIaqb26QKeh+IIgK1NN9dQiq3ByTbl4zpGZa6MmsnnRTu mzGKt2nkz7vBzH6+hZp1OzGZikgjjhYWVFoJo1dvf/rv4obs0ZJEqFPQs/1Qa1dbkKBv6odB XJpPH0ssOluTY24d1XxTiKTwmWvHeQkOKRAIfD7VTtF4TesoZYkf7hsh3e3VwXhptSLFnEOi WwYofg== Message-ID: <0984f859-bce2-3dcb-40ba-58bb61598e1b@FreeBSD.org> Date: Wed, 27 Jun 2018 13:05:10 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="I6pGaQ5DvOJY0xQeNb9GGZBU4SvrZ2rst" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 27 Jun 2018 17:05:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --I6pGaQ5DvOJY0xQeNb9GGZBU4SvrZ2rst Content-Type: multipart/mixed; boundary="2MGmki2NJfPcbAiF1fTO7BLsifonTMqLQ"; protected-headers="v1" From: Jung-uk Kim To: Alan Somers Cc: Andriy Gapon , FreeBSD Current Message-ID: <0984f859-bce2-3dcb-40ba-58bb61598e1b@FreeBSD.org> Subject: Re: TSC calibration in virtual machines References: <8ac353c5-d188-f432-aab1-86f4ca5fd295@FreeBSD.org> <4d7957f6-9497-19ff-4dbb-436bb6b05a56@FreeBSD.org> In-Reply-To: --2MGmki2NJfPcbAiF1fTO7BLsifonTMqLQ Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 06/27/2018 12:47, Alan Somers wrote: > On Wed, Jun 27, 2018 at 10:36 AM, Jung-uk Kim > wrote: >=20 > On 06/27/2018 03:14, Andriy Gapon wrote: > >=20 > > It seems that TSC calibration in virtual machines sometimes can d= o more harm > > than good.=C2=A0 Should we default to trusting the information pr= ovided by a hypervisor? > >=20 > > Specifically, I am observing a problem on GCE instances where cal= ibrated TSC > > frequency is about 10% lower than advertised frequency.=C2=A0 And= apparently the > > advertised frequency is the right one. > >=20 > > I found this thread with similar reports and a variety of workaro= unds from > > administratively disabling the calibration to switching to a diff= erent timecounter: > > https://lists.freebsd.org/pipermail/freebsd-cloud/2017-January/00= 0080.html > >=20 > We already do that for VMware hosts since r221214. >=20 > https://svnweb.freebsd.org/changeset/base/221214 > >=20 > We should do the same for each hypervisor. >=20 > We probably should.=C2=A0 But why does calibration fail in the first pl= ace? Because multiple guests are sharing same physical CPUs and guest OS has no control, timing cannot be 100% accurate. > If it can fail in a VM, then it can probably fail on bare metal too.=C2= =A0 It > would be worth investigating. It does not "fail" in bare metal because we have almost complete control.= Jung-uk Kim --2MGmki2NJfPcbAiF1fTO7BLsifonTMqLQ-- --I6pGaQ5DvOJY0xQeNb9GGZBU4SvrZ2rst Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEl1bqgKaRyqfWXu/CfJ+WJvzb8UYFAlszw8YACgkQfJ+WJvzb 8UYVxQf/ThwArM/OpiePmcwU+d5/sVUMRPnYZdRmsaYSkp+rvnBUH1e+fGJpnO+V Tu1TkpcvHNfPYwYOIE+84VP4sAcfI5Ex9wBxhZ8RrrGQ6zJKujK/kd3CALZgHMc6 QUhpHkuMbu+dBTI9uvW8RuEWlRsr4GBmk8XxOPSQlLPTsSTP9wlhWdcRdq76zsm1 jr0dUNYn8ZVeW/pAr4F/h1VF+4HhwOUJXkLQgZWJflFqzNmmaRFakkm4eT6onTBN k9mRxe1DrZ+kDjrhdgv7kjmW9TU9tt56NpC92K9+VY5nJhcuKBt3AZsmgqQ2j5g7 4gSP9ipS+Zbzj9vvwJ3RxsruD6AloQ== =mbHv -----END PGP SIGNATURE----- --I6pGaQ5DvOJY0xQeNb9GGZBU4SvrZ2rst-- From owner-freebsd-current@freebsd.org Wed Jun 27 17:05: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 8C6B4102D6CE for ; Wed, 27 Jun 2018 17:05:41 +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 0944D87241; Wed, 27 Jun 2018 17:05:40 +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 w5RH5WLp009270; Wed, 27 Jun 2018 10:05: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 w5RH5WZ7009269; Wed, 27 Jun 2018 10:05:32 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201806271705.w5RH5WZ7009269@pdx.rh.CN85.dnsmgr.net> Subject: Re: TSC calibration in virtual machines In-Reply-To: To: Alan Somers Date: Wed, 27 Jun 2018 10:05:32 -0700 (PDT) CC: Jung-uk Kim , Andriy Gapon , FreeBSD Current 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.26 Precedence: 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, 27 Jun 2018 17:05:41 -0000 > On Wed, Jun 27, 2018 at 10:36 AM, Jung-uk Kim wrote: > > > On 06/27/2018 03:14, Andriy Gapon wrote: > > > > > > It seems that TSC calibration in virtual machines sometimes can do more > > harm > > > than good. Should we default to trusting the information provided by a > > hypervisor? > > > > > > Specifically, I am observing a problem on GCE instances where calibrated > > TSC > > > frequency is about 10% lower than advertised frequency. And apparently > > the > > > advertised frequency is the right one. > > > > > > I found this thread with similar reports and a variety of workarounds > > from > > > administratively disabling the calibration to switching to a different > > timecounter: > > > https://lists.freebsd.org/pipermail/freebsd-cloud/2017- > > January/000080.html > > > > We already do that for VMware hosts since r221214. > > > > https://svnweb.freebsd.org/changeset/base/221214 > > > > We should do the same for each hypervisor. > > > > Jung-uk Kim > > > > > We probably should. But why does calibration fail in the first place? If > it can fail in a VM, then it can probably fail on bare metal too. It would > be worth investigating. No, the failure in a VM is unique to a VM, it has to do with the fact your have the hypervisor timeslicing a CPU that you believe to be 100% dedicated to you. There are several white papers, including one from VMWare about what they have done to help with the time keeping problems. What is suggested above would be a correct thing to do. Bhyve creates these issues as well, and use of certain timers in a bhyve guest can cause you nightmares with ntp. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-current@freebsd.org Wed Jun 27 17: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 2CF82102D78F for ; Wed, 27 Jun 2018 17:06:21 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 89A9987321; Wed, 27 Jun 2018 17:06:20 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lj1-x22d.google.com with SMTP id a6-v6so2218283ljj.7; Wed, 27 Jun 2018 10:06:20 -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=x6OEF2U6mBR49GHZweGF3GdhgIRB5wkYk0AGkGIkFZI=; b=PJwFIdsYRwd1sKCxlyFA/2Skoma8T19gaVH7Y7JMGukPYyTeVMgGluWpGb7SPYBOn6 owCBpZPqPlf3gyOCjm0SfbM44C7N+hCiKaJuuY28EZ+Ol2DDMIlm1NQmtiMhyW+JXREk xqKPs43aIjm1x8zufsZgDrc/DJESEfQJQfrQgF0QBUXWEhOTaEndZRfVGyXtxwYE0p9R kBAI0tySLgETJq0j+yP7YoUjEnt/kN63GOiO8/y78wXv/42703zWOQRip2nqCkt14FS2 z7dI5HxhiPVfAoassEhlPojFX9mP/eYyUPOnqKPJ8aD2Hef0BV4QhCBDflsmqG6iRNV4 OszA== 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=x6OEF2U6mBR49GHZweGF3GdhgIRB5wkYk0AGkGIkFZI=; b=eu8oAT+RLd4qxGQwgr/a3DcNb10R7/cUHmyAkXXDmZOMwPIBkCsqFKnSXXGjjGiMda 2hf2unvzobd0s9XahHzpXKCX5kG2khwkLM9HuDRUzkdHFL39jo7ZTJT51YXZu0E4FDkM M8628kjNWugCHxuJWbW9A0zquCSGqFTmd9iITc7tnK02aZNIviMab9MazJSjsW5QrOY3 ZaappL5lsPhyPHkwI5mu5Ci5QwMK0O0tWC5ttHWdcCy2SQsHjufaQxgDPql0J2lVgOGY FvWyuAlcIOrAMShT0f9WW38BlU/zohyNbH47gMfTJk9V5N30oI01yMMeoc7zGRGoU1T9 rXWw== X-Gm-Message-State: APt69E2i5bn/blToUUU8wtfQrG15XDxZOIv2kg2Z2b+DCllSt4F/dbzu uILMSc+NnrVgSFYvNk+mZXijyyC6mNAqS0OB68U= X-Google-Smtp-Source: AAOMgpfxD7G+0yGB3v+6qSL8Cc24AH+AjH4TvaLfCtO35JGQKpfU5qdhd5hZtRf3HDx3vTN6EP1Ctj36k0k8/eKrXq8= X-Received: by 2002:a2e:29da:: with SMTP id p87-v6mr2907356ljp.12.1530119178950; Wed, 27 Jun 2018 10:06:18 -0700 (PDT) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 2002:ab3:1b91:0:0:0:0:0 with HTTP; Wed, 27 Jun 2018 10:06:18 -0700 (PDT) In-Reply-To: <0984f859-bce2-3dcb-40ba-58bb61598e1b@FreeBSD.org> References: <8ac353c5-d188-f432-aab1-86f4ca5fd295@FreeBSD.org> <4d7957f6-9497-19ff-4dbb-436bb6b05a56@FreeBSD.org> <0984f859-bce2-3dcb-40ba-58bb61598e1b@FreeBSD.org> From: Alan Somers Date: Wed, 27 Jun 2018 11:06:18 -0600 X-Google-Sender-Auth: 80ULbhP0dX6zXehV0aknJ1RWav4 Message-ID: Subject: Re: TSC calibration in virtual machines To: Jung-uk Kim Cc: Andriy Gapon , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 27 Jun 2018 17:06:21 -0000 On Wed, Jun 27, 2018 at 11:05 AM, Jung-uk Kim wrote: > On 06/27/2018 12:47, Alan Somers wrote: > > On Wed, Jun 27, 2018 at 10:36 AM, Jung-uk Kim > > wrote: > > > > On 06/27/2018 03:14, Andriy Gapon wrote: > > > > > > It seems that TSC calibration in virtual machines sometimes can do > more harm > > > than good. Should we default to trusting the information provided > by a hypervisor? > > > > > > Specifically, I am observing a problem on GCE instances where > calibrated TSC > > > frequency is about 10% lower than advertised frequency. And > apparently the > > > advertised frequency is the right one. > > > > > > I found this thread with similar reports and a variety of > workarounds from > > > administratively disabling the calibration to switching to a > different timecounter: > > > https://lists.freebsd.org/pipermail/freebsd-cloud/2017- > January/000080.html > > January/000080.html> > > > > We already do that for VMware hosts since r221214. > > > > https://svnweb.freebsd.org/changeset/base/221214 > > > > > > We should do the same for each hypervisor. > > > > We probably should. But why does calibration fail in the first place? > Because multiple guests are sharing same physical CPUs and guest OS has > no control, timing cannot be 100% accurate. > > > If it can fail in a VM, then it can probably fail on bare metal too. It > > would be worth investigating. > It does not "fail" in bare metal because we have almost complete control. > > Jung-uk Kim > > Makes sense. I didn't realize that it ran before the scheduler or interrupts were started. From owner-freebsd-current@freebsd.org Wed Jun 27 17:10: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 F0ECE102DD17 for ; Wed, 27 Jun 2018 17:10:54 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8EEF7882F1; Wed, 27 Jun 2018 17:10:54 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from freefall.freebsd.org (static-71-168-218-4.cmdnnj.fios.verizon.net [71.168.218.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jkim/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 5AF341EF2E; Wed, 27 Jun 2018 17:10:54 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Subject: Re: TSC calibration in virtual machines To: Ryan Stone , Alan Somers Cc: Andriy Gapon , FreeBSD Current References: <8ac353c5-d188-f432-aab1-86f4ca5fd295@FreeBSD.org> <4d7957f6-9497-19ff-4dbb-436bb6b05a56@FreeBSD.org> From: Jung-uk Kim Openpgp: preference=signencrypt Autocrypt: addr=jkim@FreeBSD.org; prefer-encrypt=mutual; keydata= xsBNBFJBztUBCAChqNyGqmFuNo0U7MBzsD+q/G6Cv0l7LGVrOAsgh34M8wIWhD+tztDWMVfn AhxNDd0ceCj2bYOe67sTQxAScEcbt2FfvPOLp9MEXb9qohZj172Gwkk7dnhOhZZKhVGVZKM4 NcsuBDUzgf4f3Vdzj4wg6WlqplnTZo8lPE4hZWvZHoFIyunPTJWenybeV1xnxK7JkUdSvQR0 fA59RfTTECMwTrSEfYGUnxIDBraxJ7Ecs/0hGQ7sljIj8WBvlRDU5fU1xfF35aw56T8POQRq F4E6RVJW3YGuTpSwgtGZOTfygcLRhAiq3dFC3JNLaTVTpM8PjOinJyt9AU6RoITGOKwDABEB AAHNHkp1bmctdWsgS2ltIDxqa2ltQEZyZWVCU0Qub3JnPsLAfQQTAQoAJwUCUkHO1QIbAwUJ E0/POwULCQgHAwUVCgkICwUWAgMBAAIeAQIXgAAKCRB8n5Ym/NvxRqyzB/wL7QtsIpeGfGIA ZPMtgXMucM3NWzomyQMln2j2efUkDKthzh9jBxgF53TjOr7imwIt0PT2k1bqctPrq5IRqnu9 mGroqaCLE3LG2/E3jEaao4k9PO6efwlioyivUo5NrqIQOQ4k3EAXw7d2y0Dk1VpTgdMrnUAB hj7lGlLqS4ydcrf24DdbCRGdEQwqd9DBeBgbWynxAJMgbZBhYVEyIHuQKkJ8qY0ibIPXXuF0 KYDeH0qUHtWV2K3srNyPtymUkBQD84Pl1GWRYx05XdUHDmnX0JV3lg0BfYJZgZv0ehPQrMfY Fd9abTkf9FHQYz1JtsC8wUuRgqElRd6+YAGf8Tt9zsBNBFJBztUBCADLtSrP44El2VoJmH14 OFrlOgxzZnbn+Y/Gf1k12mJBiR+A+pBeRLD50p7AiTrjHRxO3cHcl9Dh0uf1VSbXgp8Or0ye iP/86fZPd4k5HXNmDTLL0HecPE08SCqGZ0W8vllQrokB1QxxRUB+fFMPJyMCjDAZ7P9fFTOS dTw1bJSTtOD8Sx8MpZUa9ti06bXFlVYDlaqSdgk181SSx+ZbSKkQR8CIMARlHwiLsa3Z9q9O EJr20HPyxe0AlTvwvFndH61hg7ds63eRvglwRnNON28VXO/lvKXq7Br/CiiyhFdKfINIx2Z5 htYq22tgGTW7mBURbIKoECFBTX9Lv6BXz6w9ABEBAAHCwGUEGAEKAA8FAlJBztUCGwwFCRNP zzsACgkQfJ+WJvzb8UZcJQf+IsTCxUEqY7W/pT84sMg5/QD3s6ufTRncvq14fEOxCNq1Rf4Q 9P+tOFa8GZfKDGB2BFGIrW7uT5mlmKdK1vO6ZIA930y5kUsnCmBUEBJkE2ciSQk01aB/1o62 Q3Gk/F6BwtNY9OXiqF7AcAo+K/BMIaqb26QKeh+IIgK1NN9dQiq3ByTbl4zpGZa6MmsnnRTu mzGKt2nkz7vBzH6+hZp1OzGZikgjjhYWVFoJo1dvf/rv4obs0ZJEqFPQs/1Qa1dbkKBv6odB XJpPH0ssOluTY24d1XxTiKTwmWvHeQkOKRAIfD7VTtF4TesoZYkf7hsh3e3VwXhptSLFnEOi WwYofg== Message-ID: <5a63153e-4001-e4f4-ea64-9692568c934e@FreeBSD.org> Date: Wed, 27 Jun 2018 13:10:49 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ViomFQoC01Vis9GyYUNfpUlzeJx5460mE" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 27 Jun 2018 17:10:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ViomFQoC01Vis9GyYUNfpUlzeJx5460mE Content-Type: multipart/mixed; boundary="PFVwc0NxXOerKKgOwN8RWYpGWyIHkuqWf"; protected-headers="v1" From: Jung-uk Kim To: Ryan Stone , Alan Somers Cc: Andriy Gapon , FreeBSD Current Message-ID: <5a63153e-4001-e4f4-ea64-9692568c934e@FreeBSD.org> Subject: Re: TSC calibration in virtual machines References: <8ac353c5-d188-f432-aab1-86f4ca5fd295@FreeBSD.org> <4d7957f6-9497-19ff-4dbb-436bb6b05a56@FreeBSD.org> In-Reply-To: --PFVwc0NxXOerKKgOwN8RWYpGWyIHkuqWf Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 06/27/2018 13:01, Ryan Stone wrote: > I would guess that the calibration can fail because when running under > the hypervisor, the FreeBSD guest code can be descheduled at the wrong > time. As I recall, the current algorithm looks like: >=20 > 1. Sample rdtsc > 2. Use a fixed-frequency timer to busy-wait for exactly 1 second > 3. Sample rdtsc again > 4. tsc_freq =3D sample2 - sample1; >=20 > If we are descheduled between 2 and 3, the time we spend off-cpu will > not be accounted for at step 4. On bare-metal this is not possible as > neither the scheduler nor interrupts are not running yet. >=20 > Although, come to think of it, I seem to recall something about SMI > interrupts mucking this up long in the past, for exactly the same > reason. I think it was legacy USB device emulation for certain Intel chipset-based motherboards. Jung-uk Kim --PFVwc0NxXOerKKgOwN8RWYpGWyIHkuqWf-- --ViomFQoC01Vis9GyYUNfpUlzeJx5460mE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEl1bqgKaRyqfWXu/CfJ+WJvzb8UYFAlszxRkACgkQfJ+WJvzb 8UZB7gf/Q1735anz4BXShSAwnHoSY/P/40ts9m1G+I53QyjSoiunWJpPo6Rnb35v z1ePaSwSy9ecuVIqyxwJxHNxE5Y9VSWzqmD5v+g5cbF0sLKSylEObOz/sbQyftpi 297VaMBHnt2P52CFI5oc7dq46uzR8Cl0jNV/m9TiUr1PeJeTAQ0g4X5RRO/pnLJT R1S6N8xEpDflPYMqt4c7ynCQY8JNmbUYscAikMaagaC+8GyhoG9DAKlfwCOr9Jxz quyHcoJ3KcevQqWUj3sE6CHrLrQMwJuOcs+/QwEXANp13f19gOwWAIpfb+43sEXC KIN0EPNd61ZeTIJXQ4U8fzDU6kZBQQ== =EAlI -----END PGP SIGNATURE----- --ViomFQoC01Vis9GyYUNfpUlzeJx5460mE-- From owner-freebsd-current@freebsd.org Wed Jun 27 17:13: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 42A8D102E185 for ; Wed, 27 Jun 2018 17:13:17 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7E8BB8878E; Wed, 27 Jun 2018 17:13:16 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from freefall.freebsd.org (static-71-168-218-4.cmdnnj.fios.verizon.net [71.168.218.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jkim/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 365D51F042; Wed, 27 Jun 2018 17:13:16 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Subject: Re: TSC calibration in virtual machines To: "Rodney W. Grimes" , Alan Somers Cc: Andriy Gapon , FreeBSD Current References: <201806271705.w5RH5WZ7009269@pdx.rh.CN85.dnsmgr.net> From: Jung-uk Kim Openpgp: preference=signencrypt Autocrypt: addr=jkim@FreeBSD.org; prefer-encrypt=mutual; keydata= xsBNBFJBztUBCAChqNyGqmFuNo0U7MBzsD+q/G6Cv0l7LGVrOAsgh34M8wIWhD+tztDWMVfn AhxNDd0ceCj2bYOe67sTQxAScEcbt2FfvPOLp9MEXb9qohZj172Gwkk7dnhOhZZKhVGVZKM4 NcsuBDUzgf4f3Vdzj4wg6WlqplnTZo8lPE4hZWvZHoFIyunPTJWenybeV1xnxK7JkUdSvQR0 fA59RfTTECMwTrSEfYGUnxIDBraxJ7Ecs/0hGQ7sljIj8WBvlRDU5fU1xfF35aw56T8POQRq F4E6RVJW3YGuTpSwgtGZOTfygcLRhAiq3dFC3JNLaTVTpM8PjOinJyt9AU6RoITGOKwDABEB AAHNHkp1bmctdWsgS2ltIDxqa2ltQEZyZWVCU0Qub3JnPsLAfQQTAQoAJwUCUkHO1QIbAwUJ E0/POwULCQgHAwUVCgkICwUWAgMBAAIeAQIXgAAKCRB8n5Ym/NvxRqyzB/wL7QtsIpeGfGIA ZPMtgXMucM3NWzomyQMln2j2efUkDKthzh9jBxgF53TjOr7imwIt0PT2k1bqctPrq5IRqnu9 mGroqaCLE3LG2/E3jEaao4k9PO6efwlioyivUo5NrqIQOQ4k3EAXw7d2y0Dk1VpTgdMrnUAB hj7lGlLqS4ydcrf24DdbCRGdEQwqd9DBeBgbWynxAJMgbZBhYVEyIHuQKkJ8qY0ibIPXXuF0 KYDeH0qUHtWV2K3srNyPtymUkBQD84Pl1GWRYx05XdUHDmnX0JV3lg0BfYJZgZv0ehPQrMfY Fd9abTkf9FHQYz1JtsC8wUuRgqElRd6+YAGf8Tt9zsBNBFJBztUBCADLtSrP44El2VoJmH14 OFrlOgxzZnbn+Y/Gf1k12mJBiR+A+pBeRLD50p7AiTrjHRxO3cHcl9Dh0uf1VSbXgp8Or0ye iP/86fZPd4k5HXNmDTLL0HecPE08SCqGZ0W8vllQrokB1QxxRUB+fFMPJyMCjDAZ7P9fFTOS dTw1bJSTtOD8Sx8MpZUa9ti06bXFlVYDlaqSdgk181SSx+ZbSKkQR8CIMARlHwiLsa3Z9q9O EJr20HPyxe0AlTvwvFndH61hg7ds63eRvglwRnNON28VXO/lvKXq7Br/CiiyhFdKfINIx2Z5 htYq22tgGTW7mBURbIKoECFBTX9Lv6BXz6w9ABEBAAHCwGUEGAEKAA8FAlJBztUCGwwFCRNP zzsACgkQfJ+WJvzb8UZcJQf+IsTCxUEqY7W/pT84sMg5/QD3s6ufTRncvq14fEOxCNq1Rf4Q 9P+tOFa8GZfKDGB2BFGIrW7uT5mlmKdK1vO6ZIA930y5kUsnCmBUEBJkE2ciSQk01aB/1o62 Q3Gk/F6BwtNY9OXiqF7AcAo+K/BMIaqb26QKeh+IIgK1NN9dQiq3ByTbl4zpGZa6MmsnnRTu mzGKt2nkz7vBzH6+hZp1OzGZikgjjhYWVFoJo1dvf/rv4obs0ZJEqFPQs/1Qa1dbkKBv6odB XJpPH0ssOluTY24d1XxTiKTwmWvHeQkOKRAIfD7VTtF4TesoZYkf7hsh3e3VwXhptSLFnEOi WwYofg== Message-ID: <4d19ae69-f7bc-1459-24bd-7a9b0940023a@FreeBSD.org> Date: Wed, 27 Jun 2018 13:13:15 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <201806271705.w5RH5WZ7009269@pdx.rh.CN85.dnsmgr.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="HFqF85OUI4tqlS2Z9dctlzv9u5lAkhtPB" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 27 Jun 2018 17:13:17 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HFqF85OUI4tqlS2Z9dctlzv9u5lAkhtPB Content-Type: multipart/mixed; boundary="blWHgfiJZdgGWtJ8XcobeDVNDC9xsZ7Br"; protected-headers="v1" From: Jung-uk Kim To: "Rodney W. Grimes" , Alan Somers Cc: Andriy Gapon , FreeBSD Current Message-ID: <4d19ae69-f7bc-1459-24bd-7a9b0940023a@FreeBSD.org> Subject: Re: TSC calibration in virtual machines References: <201806271705.w5RH5WZ7009269@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <201806271705.w5RH5WZ7009269@pdx.rh.CN85.dnsmgr.net> --blWHgfiJZdgGWtJ8XcobeDVNDC9xsZ7Br Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 06/27/2018 13:05, Rodney W. Grimes wrote: > There are several white papers, including one from VMWare about what > they have done to help with the time keeping problems. https://www.vmware.com/files/pdf/techpaper/Timekeeping-In-VirtualMachines= =2Epdf Jung-uk Kim --blWHgfiJZdgGWtJ8XcobeDVNDC9xsZ7Br-- --HFqF85OUI4tqlS2Z9dctlzv9u5lAkhtPB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEl1bqgKaRyqfWXu/CfJ+WJvzb8UYFAlszxawACgkQfJ+WJvzb 8UbSvwf/fasWDRp7Xc+swthiQ1ETQ/wkHvE4B7Ev/yBdCp9b0FgBgBBJsgkkRbn/ d5GOehJ0qUsaz9M9DHSCkId9Y0ix/wmFaFU8zF8u7xKfGJNqQbGhMwXjF7K9xX5N eDXsHoM4PshlwsipqwU7bUYEJN2dTOuOKOAhqeJ9WQcCRnRxaVtsV27v30+Qewj5 GCn8RZcTWbDz3eTljdCN4HA2lQwYUYzzpMnhAsRSdqiz53jNb72ZzbvN48dYiD4k FHjhUpFG82kM6QDtcJmzqvW43ii09h/P3BDsHN8NOLfDiUgmWmmQlzsTPtkwtKEM xsIRIuwjCx4yu6FWFQ+ARLXkjgDw/Q== =QSlu -----END PGP SIGNATURE----- --HFqF85OUI4tqlS2Z9dctlzv9u5lAkhtPB-- From owner-freebsd-current@freebsd.org Wed Jun 27 17:21: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 4E1A6102E96A for ; Wed, 27 Jun 2018 17:21:36 +0000 (UTC) (envelope-from hackagadget@gmail.com) Received: from mail-ot0-f169.google.com (mail-ot0-f169.google.com [74.125.82.169]) (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 D1DEF89141; Wed, 27 Jun 2018 17:21:35 +0000 (UTC) (envelope-from hackagadget@gmail.com) Received: by mail-ot0-f169.google.com with SMTP id v24-v6so3026500otk.13; Wed, 27 Jun 2018 10:21:35 -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=MnNvhJI8C5LU3CeZGO0TT+aqlCA2oa+m24K6iDuvi4A=; b=gj0qa0bxMiG9kCA/HNi16cTb4aI7QOxVutqGrz6yt1UoBiWSRFs2XQ21IR37th45sT sPKGmyrB/8Ci+CKfaJUDY6/hiXJc2XttDsSlRriPZrjsPoyHWoMNik4TFUfRwle5xz0/ V8RPsKxVBufZKbla1NtJewZdLK76L7KZ0rVw5rxqIremwrqDSWr1yBDs6YCgOTjfzDUQ 6vhMyd7PX6YtW8jE+4OuWy6/nUgv0pq5mU+2mxfbEXVZyzCYmzTQFAV6nyaMhY4d4lWB ThvcxbdABPfnNwzfpViS2UubrydbrsCl+9+mCBL4Opus1TrGVU8ojzo1RbMr+wzNkBzr 0L5g== X-Gm-Message-State: APt69E1HCD+P3iCWoxECjQoyETokKT6h5UMZZ9Ev3O0r4S7AmFte/6xC 41NG/gdvX3chjz69StgZnMBfW2tlLu4= X-Google-Smtp-Source: AAOMgpegpwj8AHxKgPLOL3883bEijPzqJIK8vDoed2+IDBGp2SOY/o/SX3rmaBAU6WhUDUaJLMN1UA== X-Received: by 2002:a9d:6385:: with SMTP id w5-v6mr4167109otk.233.1530118533485; Wed, 27 Jun 2018 09:55:33 -0700 (PDT) Received: from mail-ot0-f176.google.com (mail-ot0-f176.google.com. [74.125.82.176]) by smtp.gmail.com with ESMTPSA id j29-v6sm2221713oth.60.2018.06.27.09.55.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Jun 2018 09:55:33 -0700 (PDT) Received: by mail-ot0-f176.google.com with SMTP id w22-v6so2955587otk.5; Wed, 27 Jun 2018 09:55:33 -0700 (PDT) X-Received: by 2002:a9d:34db:: with SMTP id t27-v6mr4210302otd.316.1530118528154; Wed, 27 Jun 2018 09:55:28 -0700 (PDT) MIME-Version: 1.0 References: <8ac353c5-d188-f432-aab1-86f4ca5fd295@FreeBSD.org> <4d7957f6-9497-19ff-4dbb-436bb6b05a56@FreeBSD.org> In-Reply-To: From: "Stephen J. Kiernan" Date: Wed, 27 Jun 2018 12:55:16 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: TSC calibration in virtual machines To: Alan Somers Cc: Jung-uk Kim , Andriy Gapon , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 27 Jun 2018 17:21:36 -0000 On Wed, Jun 27, 2018, 12:48 PM Alan Somers wrote: > On Wed, Jun 27, 2018 at 10:36 AM, Jung-uk Kim wrote: > > > On 06/27/2018 03:14, Andriy Gapon wrote: > > > > > > It seems that TSC calibration in virtual machines sometimes can do more > > harm > > > than good. Should we default to trusting the information provided by a > > hypervisor? > > > > > > Specifically, I am observing a problem on GCE instances where > calibrated > > TSC > > > frequency is about 10% lower than advertised frequency. And apparently > > the > > > advertised frequency is the right one. > > > > > > I found this thread with similar reports and a variety of workarounds > > from > > > administratively disabling the calibration to switching to a different > > timecounter: > > > https://lists.freebsd.org/pipermail/freebsd-cloud/2017- > > January/000080.html > > > > We already do that for VMware hosts since r221214. > > > > https://svnweb.freebsd.org/changeset/base/221214 > > > > We should do the same for each hypervisor. > > > > Jung-uk Kim > > > > > We probably should. But why does calibration fail in the first place? If > it can fail in a VM, then it can probably fail on bare metal too. It would > be worth investigating. > The main problem is you can't be assured that the DELAY call will be accurate in those cases. Also the way that some VMs implement the rdtsc insrruction may not be as accurate as we would need. In some cases it can compound the issue. -Steve From owner-freebsd-current@freebsd.org Wed Jun 27 17:53:14 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 5D081102FC8F for ; Wed, 27 Jun 2018 17:53:14 +0000 (UTC) (envelope-from marklmi@yahoo.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 E46C48A67C for ; Wed, 27 Jun 2018 17:53:13 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: by mailman.ysv.freebsd.org (Postfix) id 9E60D102FC86; Wed, 27 Jun 2018 17:53:13 +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 79951102FC85 for ; Wed, 27 Jun 2018 17:53:13 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-22.consmr.mail.gq1.yahoo.com (sonic311-22.consmr.mail.gq1.yahoo.com [98.137.65.203]) (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 DB20B8A679 for ; Wed, 27 Jun 2018 17:53:12 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: shEyRd8VM1lSLR1lCGSQ2xGyCX2IwPbyuYs4MjBcBFW0.qMwNFjKD37T6Wo9A7b Xwl8MUg5qBNjWbLQRsXTNE8As63SXX5v6Rdc2dqZKjAYMGbythDw99kXozd8hvNYUkHz44DOYW.K B9iWOmdkFQ8DQgbik6wlZIZDEk_gddAZgEmPFKbit14l4yHIbSlqXDfYohC7UNpiLMTccDAVXOaK y3.OsCgH5wTaQNwryLs7m5qH4Yix7ffvaorAoqub_nI5MDdWkjI6O9S.mwZ8c5PH7BLVkicFwFkI hIvlewwo1h15bda4YuQOxQ8WKYkrK8xQ4rj2eCuafyCzmPy1jiEtYl8qbnsGAkrHZlK4Rg5GHaAZ C6LSDBlSSKrvMmcGCOsah.VTQIplx3gVN0oMdBLE9Kugc1OM8p.FzxoRUBIKzJL5EbuvJ_tIKbhw zP1nv3Uj0BxsS65k72ciMRGCO06Cq7uAMDkT0soN4xyPUwUK7YnxMhINzntE2bIccW7BjVI9mYUC P5Oe.raLvGM5HD.P1luBZhJAwn_e6z8arNVii6.xZ4.I3hOl2jJkaDADcykPqXRYq.mskxICHu1m yncgNjv18c_jUBqDiHSUoUJO7zjiJz.gH.b76SE53Q3Xvs3A_acDy8G8YCQujzm.rWZi8rr0BC85 CWTaSn2c52uStPLqkva7GenEMGeco9WSKLX5qgConbGe88JZjp2G.znAR2h2NF5x6Bdnp496O6y8 ecc30u.8a8m.kyUvUKXgUAqOlM9iHNl9I2be8lObJ2NN2GVRgy9R0FHoV2BWm22qzveUUWH4ElnC RC8zsW28O6xMDOYSHIve_y2we6XcOlqFVLIr25tJBnnYBfAfMOUvy.LisYJOWFveCZ2DBYvxA6IF G_ND2Jy4CQmfYSQrWAV7DqMSr4bJCwhLGL4gc0YVhnWT729IbNvy6i1kCsnnFt67OsmZBMmAwoqG e2KzG0ha9nawvv38ZgDyAXuGwMxNG4A-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Wed, 27 Jun 2018 17:53:05 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp402.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 404c412715cba164364a536925e4f613; Wed, 27 Jun 2018 17:53:04 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: Build updates [ ci.freebsd.org FreeBSD-head-{aarch64, armv7, armv6}-build failures as of, for example -r335711 and -r335713 ] From: Mark Millard In-Reply-To: <168e5fec-2d38-78e1-6aa4-c51e860ffd55@FreeBSD.org> Date: Wed, 27 Jun 2018 10:53:03 -0700 Cc: "current@freebsd.org" , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <7116FF4C-DFA0-41CC-9906-F8B0B5A951EF@yahoo.com> References: <168e5fec-2d38-78e1-6aa4-c51e860ffd55@FreeBSD.org> To: Bryan Drewery X-Mailer: Apple Mail (2.3445.8.2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 27 Jun 2018 17:53:14 -0000 > On 2018-Jun-27, at 10:01 AM, Bryan Drewery = wrote: >=20 > As of r335704: >=20 > - make tinderbox/universe will now build the bootstrap clang *once*. > Each target clang is still build of course. This support does not = work > with gcc. > - make buildworld (kernel-toolchain and toolchain) will build the > bootstrap clang (if needed per SYSTEM_COMPILER logic) with only the > TARGET.TARGET_ARCH backend support. The installed clang has all still = so > SYSTEM_COMPILER logic works for cross-compling. >=20 > This uses the feature dim@ added in r335558 to selectively disable = LLVM > targets. I've added a new option named WITH[OUT]_LLVM_TARGET_ALL which = I > suggest using rather than the per-arch options. It is default on = (WITH). > Set WITHOUT to only build the needed native arch on your system for = both > bootstrap and compiled clang. Setting WITHOUT disables SYSTEM_COMPILER > support for cross-builds. >=20 > Please CC me directly for any weird tinderbox/universe or clang = failures > for the next few weeks. https://ci.freebsd.org/job/FreeBSD-head-aarch64-build/8324/consoleText --- all_subdir_cloudabi32 --- clang (LLVM option parsing): Unknown command line argument = '-arm-add-build-attributes'. Try: 'clang (LLVM option parsing) -help' clang (LLVM option parsing): Did you mean '-force-attribute'? *** [cloudabi32_vdso.o] Error code 1 https://ci.freebsd.org/job/FreeBSD-head-armv7-build/460/consoleText (armv6 is similar) --- all_subdir_lib/clang/libllvm --- =3D=3D=3D> lib/clang/libllvm (all) [Creating objdir = /usr/obj/usr/src/arm.armv7/tmp/obj-tools/lib/clang/libllvm...] make[4]: "/usr/src/lib/clang/libllvm/Makefile" line 16: Please enable at = least one of: MK_LLVM_TARGET_AARCH64, MK_LLVM_TARGET_ARM, = MK_LLVM_TARGET_MIPS, MK_LLVM_TARGET_POWERPC, MK_LLVM_TARGET_SPARC, or = MK_LLVM_TARGET_X86 *** [all_subdir_lib/clang/libllvm] Error code 1 =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 Jun 27 18:44: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 D66E01000F3E for ; Wed, 27 Jun 2018 18:44:57 +0000 (UTC) (envelope-from bdrewery@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 601148C4FB for ; Wed, 27 Jun 2018 18:44:57 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 207BD1000F37; Wed, 27 Jun 2018 18:44: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 F1CF31000F36; Wed, 27 Jun 2018 18:44:56 +0000 (UTC) (envelope-from bdrewery@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 91F6D8C4F8; Wed, 27 Jun 2018 18:44:56 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (unknown [127.0.1.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 6402F1FC1D; Wed, 27 Jun 2018 18:44:56 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 334CC9874; Wed, 27 Jun 2018 18:44:55 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id nBrLMf4ziyRu; Wed, 27 Jun 2018 18:44:52 +0000 (UTC) To: Dimitry Andric DKIM-Filter: OpenDKIM Filter v2.10.3 mail.xzibition.com 3D1BF986E Cc: Mark Millard , "current@freebsd.org" , FreeBSD Toolchain References: <168e5fec-2d38-78e1-6aa4-c51e860ffd55@FreeBSD.org> <7116FF4C-DFA0-41CC-9906-F8B0B5A951EF@yahoo.com> From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Autocrypt: addr=bdrewery@FreeBSD.org; prefer-encrypt=mutual; keydata= xsBNBFJphmsBCADiFgmS4bIzwZijrS31SjEMzg+n5zNellgM+HkShwehpqCiyhXdWrvH6dTZ a6u50pbUIX7doTR7W7PQHCjCTqtpwvcj0eulZva+iHFp+XrbgSFHn+VVXgkYP2MFySyZRFab D2qqzJBEJofhpv4HvY6uQI5K99pMqKr1Z/lHqsijYYu4RH2OfwB5PinId7xeldzWEonVoCr+ rfxzO/UrgA6v/3layGZcKNHFjmc3NqoN1DXtdaEHqtjIozzbndVkH6lkFvIpIrI6i5ox8pwp VxsxLCr/4Musd5CWgHiet5kSw2SzNeA8FbxdLYCpXNVu+uBACEbCUP+CSNy3NVfEUxsBABEB AAHNJEJyeWFuIERyZXdlcnkgPGJkcmV3ZXJ5QEZyZWVCU0Qub3JnPsLAgAQTAQoAKgIbAwUL CQgHAwUVCgkICwUWAwIBAAIeAQIXgAIZAQUCWujOIgUJCmB7NwAKCRA113G7bkaXz/xpB/9b /UWIPbieY1IeIuHF2pyYPE7Hytkh3HVsxMA0F5Ma2AYQsXZZeKNKWrF7RPyDyDwUklLHJkhm k3EfClBbHxf08kMIm1vWCJRtgxic9knY/bzYGiWMpHjg3cSd1XfrYH1autYqTZAjDwIkgOjU dR//Tbn4V36sY7y2jz+kdMVWvK53U32aZqiwBbCn4DPe1wSZcUs17mV/0uZdIoGdj74B1orN A/0py5vHYo6HcbBNoaR8pKRLf5VZNRsxqGIMhTucx4SJWcHpuRBWYyvJSFzwvxdK4ZD4Yqoc kFGPVtOXktVMai9exrLvP3G77fKMu8DI6j4QRU4wCesnHuIfRPFuzsBNBFJphmsBCACiVFPf kNfaFtUSuY0395ueo/rMyHPGPQ2iwvERFCpeFGSQSgagpenNHLpFQKTg/dl6FOoST5tqyxMq fyHGHDzzU51bvA/IfaGoNi/BIhTe/toZNMRvpcI3PLjiGcnJnuwCCbAVOAGdb+t5cZtpNdOI cKYmrYG3u9RiBpe6dTF+qLrD/8Bs1wjhduQ8fcNNgnkXu8xDH4ZxY0lIc3QgvYWp9vimlQe6 iKjUd2/DX28ETZcD5h6pYV331KMPTrEI0p0yvFijUZce8c1XHFyL1j9sBAha5qpszJl6Uq5i LolhKRcGfcdmtD72vHQjUYglUyudSJUVyo2gMYjdbiFKzJulABEBAAHCwGUEGAEKAA8CGwwF AlrozigFCQpgez0ACgkQNddxu25Gl8+m5Af/R3VEdxNMAcDIes9ADhQyofj20SPV3eCJ3HYR OebTSuNdOudGt4AAyA8Ks94u9hiIp5IGsc6RDsT9W7O2vgXhd6eV3eiY5Oif5xLIYrIDVu1Y 1GyRxRrPEn/QOqDN6uFZCPwK1aOapGcYCrO9lB0gMuTVfgHanU61rgC9tMX0OoAOyRd+V3/M 8lDNhjJdF/IpO3SdYzKfkwduy4qamw4Gphcx/RfYQvYLq/eDkP8d50PphWdboqWBwNRHayro W/07OGzfxM5fJ5mBsXPQcO2QcRjkyHf6xCM6Hi1qQL4OnXMNE/ZTX0lnOj1/pH93TlzSHZMP TaiiA/MBD3vGsXBmBg== Organization: FreeBSD Subject: Re: Build updates [ ci.freebsd.org FreeBSD-head-{aarch64, armv7, armv6}-build failures as of, for example -r335711 and -r335713 ] Message-ID: <555a1ac0-a7e8-3ca1-019e-41cf829cbff0@FreeBSD.org> Date: Wed, 27 Jun 2018 11:44:50 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <7116FF4C-DFA0-41CC-9906-F8B0B5A951EF@yahoo.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8lDovXtvI7prJyplLJsZvEcFWw1mmBOh5" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 27 Jun 2018 18:44:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8lDovXtvI7prJyplLJsZvEcFWw1mmBOh5 Content-Type: multipart/mixed; boundary="wArheKcUXa20en6U7KLrSAMapXswdFDlg"; protected-headers="v1" From: Bryan Drewery To: Dimitry Andric Cc: Mark Millard , "current@freebsd.org" , FreeBSD Toolchain Message-ID: <555a1ac0-a7e8-3ca1-019e-41cf829cbff0@FreeBSD.org> Subject: Re: Build updates [ ci.freebsd.org FreeBSD-head-{aarch64,armv7,armv6}-build failures as of, for example -r335711 and -r335713 ] References: <168e5fec-2d38-78e1-6aa4-c51e860ffd55@FreeBSD.org> <7116FF4C-DFA0-41CC-9906-F8B0B5A951EF@yahoo.com> In-Reply-To: <7116FF4C-DFA0-41CC-9906-F8B0B5A951EF@yahoo.com> --wArheKcUXa20en6U7KLrSAMapXswdFDlg Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 6/27/2018 10:53 AM, Mark Millard wrote: >=20 >> On 2018-Jun-27, at 10:01 AM, Bryan Drewery w= rote: >> >> As of r335704: >> >> - make tinderbox/universe will now build the bootstrap clang *once*. >> Each target clang is still build of course. This support does not wor= k >> with gcc. >> - make buildworld (kernel-toolchain and toolchain) will build the >> bootstrap clang (if needed per SYSTEM_COMPILER logic) with only the >> TARGET.TARGET_ARCH backend support. The installed clang has all still = so >> SYSTEM_COMPILER logic works for cross-compling. >> >> This uses the feature dim@ added in r335558 to selectively disable LLV= M >> targets. I've added a new option named WITH[OUT]_LLVM_TARGET_ALL which= I >> suggest using rather than the per-arch options. It is default on (WITH= ). >> Set WITHOUT to only build the needed native arch on your system for bo= th >> bootstrap and compiled clang. Setting WITHOUT disables SYSTEM_COMPILER= >> support for cross-builds. >> >> Please CC me directly for any weird tinderbox/universe or clang failur= es >> for the next few weeks. Thanks! >=20 > https://ci.freebsd.org/job/FreeBSD-head-aarch64-build/8324/consoleText >=20 > --- all_subdir_cloudabi32 --- > clang (LLVM option parsing): Unknown command line argument '-arm-add-bu= ild-attributes'. Try: 'clang (LLVM option parsing) -help' > clang (LLVM option parsing): Did you mean '-force-attribute'? > *** [cloudabi32_vdso.o] Error code 1 >=20 This was an aarch64 build. It looks like -arm-add-build-attributes is from Target/ARM/AsmParser/ARMAsmParser.cpp which is only built for LLVM_TARGET_ARM but not LLVM_TARGET_AARCH64. Looking in contrib/llvm/tools/clang/lib/Driver/ToolChains/Clang.cpp I see the option is only added for: case llvm::Triple::arm: case llvm::Triple::armeb: case llvm::Triple::thumb: case llvm::Triple::thumbeb: But not llvm::Triple::aarch64. So where is it coming from? >=20 > https://ci.freebsd.org/job/FreeBSD-head-armv7-build/460/consoleText > (armv6 is similar) >=20 > --- all_subdir_lib/clang/libllvm --- > =3D=3D=3D> lib/clang/libllvm (all) > [Creating objdir /usr/obj/usr/src/arm.armv7/tmp/obj-tools/lib/clang/lib= llvm...] > make[4]: "/usr/src/lib/clang/libllvm/Makefile" line 16: Please enable a= t least one of: MK_LLVM_TARGET_AARCH64, MK_LLVM_TARGET_ARM, MK_LLVM_TARGE= T_MIPS, MK_LLVM_TARGET_POWERPC, MK_LLVM_TARGET_SPARC, or MK_LLVM_TARGET_X= 86 > *** [all_subdir_lib/clang/libllvm] Error code 1 >=20 Arm failures fixed in r335718. --=20 Regards, Bryan Drewery --wArheKcUXa20en6U7KLrSAMapXswdFDlg-- --8lDovXtvI7prJyplLJsZvEcFWw1mmBOh5 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 iQEcBAEBAgAGBQJbM9siAAoJEDXXcbtuRpfPQIoH/ivFPq06sSIGl+LxshqQjiwr HZwSJbWxpCaEfPzSMYuqwnY0+we6gNZDYxiG6HxK6AFJMAblCn1hZ2utrDcu/EHO U1h1o9HvkC70qI429CIzIsWhltri42LdOQDkBj2K2GjRJOlrxWJQHcAVwKnweLQI wIL4fstGuStRWazD+OZIGz2lcBJ+i+B8OiGOB2TvN69fbAhC0GNmfno8DH4g9H0+ 2DkFw7/rR/jMNI7s1UrxXZaW7QWz6FIVvWVAenAOIkMY66vL60VBCmL0yyBLdkmi LFAok7MatxCpGbRQEPHggFK28jDeFKuD2kY+WCtiD4JXqhxZsDth5Mgob4Tju+o= =bxGI -----END PGP SIGNATURE----- --8lDovXtvI7prJyplLJsZvEcFWw1mmBOh5-- From owner-freebsd-current@freebsd.org Wed Jun 27 18:49: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 9BE70100171B for ; Wed, 27 Jun 2018 18:49:31 +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 264018C893 for ; Wed, 27 Jun 2018 18:49:30 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-RoutePath: aGlwcGll X-MHO-User: cbecad29-7a3a-11e8-aa1a-954dbaed88ca 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 cbecad29-7a3a-11e8-aa1a-954dbaed88ca; Wed, 27 Jun 2018 18:49:19 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w5RInH82002250; Wed, 27 Jun 2018 12:49:17 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1530125357.24573.101.camel@freebsd.org> Subject: Re: TSC calibration in virtual machines From: Ian Lepore To: "Rodney W. Grimes" , Alan Somers Cc: Jung-uk Kim , Andriy Gapon , FreeBSD Current Date: Wed, 27 Jun 2018 12:49:17 -0600 In-Reply-To: <201806271705.w5RH5WZ7009269@pdx.rh.CN85.dnsmgr.net> References: <201806271705.w5RH5WZ7009269@pdx.rh.CN85.dnsmgr.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.26 Precedence: 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, 27 Jun 2018 18:49:31 -0000 On Wed, 2018-06-27 at 10:05 -0700, Rodney W. Grimes wrote: > > > > On Wed, Jun 27, 2018 at 10:36 AM, Jung-uk Kim > > wrote: > > > > > > > > On 06/27/2018 03:14, Andriy Gapon wrote: > > > > > > > > > > > > It seems that TSC calibration in virtual machines sometimes can > > > > do more > > > harm > > > > > > > > than good.  Should we default to trusting the information > > > > provided by a > > > hypervisor? > > > > > > > > > > > > Specifically, I am observing a problem on GCE instances where > > > > calibrated > > > TSC > > > > > > > > frequency is about 10% lower than advertised frequency.  And > > > > apparently > > > the > > > > > > > > advertised frequency is the right one. > > > > > > > > I found this thread with similar reports and a variety of > > > > workarounds > > > from > > > > > > > > administratively disabling the calibration to switching to a > > > > different > > > timecounter: > > > > > > > > https://lists.freebsd.org/pipermail/freebsd-cloud/2017- > > > January/000080.html > > > > > > We already do that for VMware hosts since r221214. > > > > > > https://svnweb.freebsd.org/changeset/base/221214 > > > > > > We should do the same for each hypervisor. > > > > > > Jung-uk Kim > > > > > > > > We probably should.  But why does calibration fail in the first > > place?  If > > it can fail in a VM, then it can probably fail on bare metal > > too.  It would > > be worth investigating. > No, the failure in a VM is unique to a VM, it has to do with the fact > your have the hypervisor timeslicing a CPU that you believe to be > 100% > dedicated to you. > > There are several white papers, including one from VMWare about what > they have done to help with the time keeping problems. > > What is suggested above would be a correct thing to do. > Bhyve creates these issues as well, and use of certain timers > in a bhyve guest can cause you nightmares with ntp. Iirc, bhyve's arithmetic when doing timer emulation leads to roundoff errors that accumulate to effectively make the emulated timer run off- frequency. The hpet timer was trivial to fix by just redefining it to run at a power-of-2 frequency to eliminate rounding errors. The other timers have to run at fixed frequencies, so better arithmetic will be the way to fix them. I vaguely remember that being harder to do than to say because of the way the code is currently structured, which is why I just did the easy fix to the hpet so that people would have at least one usable timer that didn't give ntpd fits in guest OSes. -- Ian From owner-freebsd-current@freebsd.org Wed Jun 27 18:58: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 3704B1001E10 for ; Wed, 27 Jun 2018 18:58:17 +0000 (UTC) (envelope-from bdrewery@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 AEA878CE93 for ; Wed, 27 Jun 2018 18:58:16 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 6F4CD1001E0B; Wed, 27 Jun 2018 18:58:16 +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 4A1651001E0A; Wed, 27 Jun 2018 18:58:16 +0000 (UTC) (envelope-from bdrewery@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 DB59C8CE91; Wed, 27 Jun 2018 18:58:15 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (unknown [127.0.1.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id AC3515F; Wed, 27 Jun 2018 18:58:15 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id E96CB98BA; Wed, 27 Jun 2018 18:58:14 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id jGShqwqOEyXU; Wed, 27 Jun 2018 18:58:12 +0000 (UTC) Subject: Re: Build updates [ ci.freebsd.org FreeBSD-head-{aarch64, armv7, armv6}-build failures as of, for example -r335711 and -r335713 ] DKIM-Filter: OpenDKIM Filter v2.10.3 mail.xzibition.com 9B24098B5 From: Bryan Drewery To: Dimitry Andric Cc: Mark Millard , "current@freebsd.org" , FreeBSD Toolchain References: <168e5fec-2d38-78e1-6aa4-c51e860ffd55@FreeBSD.org> <7116FF4C-DFA0-41CC-9906-F8B0B5A951EF@yahoo.com> <555a1ac0-a7e8-3ca1-019e-41cf829cbff0@FreeBSD.org> Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Autocrypt: addr=bdrewery@FreeBSD.org; prefer-encrypt=mutual; keydata= xsBNBFJphmsBCADiFgmS4bIzwZijrS31SjEMzg+n5zNellgM+HkShwehpqCiyhXdWrvH6dTZ a6u50pbUIX7doTR7W7PQHCjCTqtpwvcj0eulZva+iHFp+XrbgSFHn+VVXgkYP2MFySyZRFab D2qqzJBEJofhpv4HvY6uQI5K99pMqKr1Z/lHqsijYYu4RH2OfwB5PinId7xeldzWEonVoCr+ rfxzO/UrgA6v/3layGZcKNHFjmc3NqoN1DXtdaEHqtjIozzbndVkH6lkFvIpIrI6i5ox8pwp VxsxLCr/4Musd5CWgHiet5kSw2SzNeA8FbxdLYCpXNVu+uBACEbCUP+CSNy3NVfEUxsBABEB AAHNJEJyeWFuIERyZXdlcnkgPGJkcmV3ZXJ5QEZyZWVCU0Qub3JnPsLAgAQTAQoAKgIbAwUL CQgHAwUVCgkICwUWAwIBAAIeAQIXgAIZAQUCWujOIgUJCmB7NwAKCRA113G7bkaXz/xpB/9b /UWIPbieY1IeIuHF2pyYPE7Hytkh3HVsxMA0F5Ma2AYQsXZZeKNKWrF7RPyDyDwUklLHJkhm k3EfClBbHxf08kMIm1vWCJRtgxic9knY/bzYGiWMpHjg3cSd1XfrYH1autYqTZAjDwIkgOjU dR//Tbn4V36sY7y2jz+kdMVWvK53U32aZqiwBbCn4DPe1wSZcUs17mV/0uZdIoGdj74B1orN A/0py5vHYo6HcbBNoaR8pKRLf5VZNRsxqGIMhTucx4SJWcHpuRBWYyvJSFzwvxdK4ZD4Yqoc kFGPVtOXktVMai9exrLvP3G77fKMu8DI6j4QRU4wCesnHuIfRPFuzsBNBFJphmsBCACiVFPf kNfaFtUSuY0395ueo/rMyHPGPQ2iwvERFCpeFGSQSgagpenNHLpFQKTg/dl6FOoST5tqyxMq fyHGHDzzU51bvA/IfaGoNi/BIhTe/toZNMRvpcI3PLjiGcnJnuwCCbAVOAGdb+t5cZtpNdOI cKYmrYG3u9RiBpe6dTF+qLrD/8Bs1wjhduQ8fcNNgnkXu8xDH4ZxY0lIc3QgvYWp9vimlQe6 iKjUd2/DX28ETZcD5h6pYV331KMPTrEI0p0yvFijUZce8c1XHFyL1j9sBAha5qpszJl6Uq5i LolhKRcGfcdmtD72vHQjUYglUyudSJUVyo2gMYjdbiFKzJulABEBAAHCwGUEGAEKAA8CGwwF AlrozigFCQpgez0ACgkQNddxu25Gl8+m5Af/R3VEdxNMAcDIes9ADhQyofj20SPV3eCJ3HYR OebTSuNdOudGt4AAyA8Ks94u9hiIp5IGsc6RDsT9W7O2vgXhd6eV3eiY5Oif5xLIYrIDVu1Y 1GyRxRrPEn/QOqDN6uFZCPwK1aOapGcYCrO9lB0gMuTVfgHanU61rgC9tMX0OoAOyRd+V3/M 8lDNhjJdF/IpO3SdYzKfkwduy4qamw4Gphcx/RfYQvYLq/eDkP8d50PphWdboqWBwNRHayro W/07OGzfxM5fJ5mBsXPQcO2QcRjkyHf6xCM6Hi1qQL4OnXMNE/ZTX0lnOj1/pH93TlzSHZMP TaiiA/MBD3vGsXBmBg== Organization: FreeBSD Message-ID: <2a7b1ecb-b647-d09b-4bd7-5c2df62b0846@FreeBSD.org> Date: Wed, 27 Jun 2018 11:58:10 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <555a1ac0-a7e8-3ca1-019e-41cf829cbff0@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kblqXkkf3rRGvC9WwNVcqFDSRcBWQmyeX" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 27 Jun 2018 18:58:17 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kblqXkkf3rRGvC9WwNVcqFDSRcBWQmyeX Content-Type: multipart/mixed; boundary="jFx8TT88Sy9QJ8uHrcEMeNbJwt3gSbY0W"; protected-headers="v1" From: Bryan Drewery To: Dimitry Andric Cc: Mark Millard , "current@freebsd.org" , FreeBSD Toolchain Message-ID: <2a7b1ecb-b647-d09b-4bd7-5c2df62b0846@FreeBSD.org> Subject: Re: Build updates [ ci.freebsd.org FreeBSD-head-{aarch64,armv7,armv6}-build failures as of, for example -r335711 and -r335713 ] References: <168e5fec-2d38-78e1-6aa4-c51e860ffd55@FreeBSD.org> <7116FF4C-DFA0-41CC-9906-F8B0B5A951EF@yahoo.com> <555a1ac0-a7e8-3ca1-019e-41cf829cbff0@FreeBSD.org> In-Reply-To: <555a1ac0-a7e8-3ca1-019e-41cf829cbff0@FreeBSD.org> --jFx8TT88Sy9QJ8uHrcEMeNbJwt3gSbY0W Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 6/27/2018 11:44 AM, Bryan Drewery wrote: > On 6/27/2018 10:53 AM, Mark Millard wrote: >> >>> On 2018-Jun-27, at 10:01 AM, Bryan Drewery = wrote: >>> >>> As of r335704: >>> >>> - make tinderbox/universe will now build the bootstrap clang *once*. >>> Each target clang is still build of course. This support does not wo= rk >>> with gcc. >>> - make buildworld (kernel-toolchain and toolchain) will build the >>> bootstrap clang (if needed per SYSTEM_COMPILER logic) with only the >>> TARGET.TARGET_ARCH backend support. The installed clang has all still= so >>> SYSTEM_COMPILER logic works for cross-compling. >>> >>> This uses the feature dim@ added in r335558 to selectively disable LL= VM >>> targets. I've added a new option named WITH[OUT]_LLVM_TARGET_ALL whic= h I >>> suggest using rather than the per-arch options. It is default on (WIT= H). >>> Set WITHOUT to only build the needed native arch on your system for b= oth >>> bootstrap and compiled clang. Setting WITHOUT disables SYSTEM_COMPILE= R >>> support for cross-builds. >>> >>> Please CC me directly for any weird tinderbox/universe or clang failu= res >>> for the next few weeks. >=20 > Thanks! >=20 >> >> https://ci.freebsd.org/job/FreeBSD-head-aarch64-build/8324/consoleText= >> >> --- all_subdir_cloudabi32 --- >> clang (LLVM option parsing): Unknown command line argument '-arm-add-b= uild-attributes'. Try: 'clang (LLVM option parsing) -help' >> clang (LLVM option parsing): Did you mean '-force-attribute'? >> *** [cloudabi32_vdso.o] Error code 1 >> >=20 > This was an aarch64 build. It looks like -arm-add-build-attributes is > from Target/ARM/AsmParser/ARMAsmParser.cpp which is only built for > LLVM_TARGET_ARM but not LLVM_TARGET_AARCH64. >=20 > Looking in contrib/llvm/tools/clang/lib/Driver/ToolChains/Clang.cpp I > see the option is only added for: >=20 > case llvm::Triple::arm: > case llvm::Triple::armeb: > case llvm::Triple::thumb: > case llvm::Triple::thumbeb: >=20 > But not llvm::Triple::aarch64. So where is it coming from? >=20 cc -target aarch64-unknown-freebsd12.0 --sysroot=3D/usr/obj/usr/src/arm64.aarch64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -x assembler-with-cpp -m32 -shared -nostdinc -nostdlib -Wl,-T/usr/src/sys/compat/cloudabi/cloudabi_vdso.lds /usr/src/sys/contrib/cloudabi/cloudabi_vdso_armv6_on_64bit.S -o cloudabi32_vdso.o It must be the -m32 here making it build with llvm::Triple::arm. So we may need to include more of LLVM_TARGET_ARM in LLVM_TARGET_AARCH64.= I'm testing locally to see how much is needed. >> >> https://ci.freebsd.org/job/FreeBSD-head-armv7-build/460/consoleText >> (armv6 is similar) >> >> --- all_subdir_lib/clang/libllvm --- >> =3D=3D=3D> lib/clang/libllvm (all) >> [Creating objdir /usr/obj/usr/src/arm.armv7/tmp/obj-tools/lib/clang/li= bllvm...] >> make[4]: "/usr/src/lib/clang/libllvm/Makefile" line 16: Please enable = at least one of: MK_LLVM_TARGET_AARCH64, MK_LLVM_TARGET_ARM, MK_LLVM_TARG= ET_MIPS, MK_LLVM_TARGET_POWERPC, MK_LLVM_TARGET_SPARC, or MK_LLVM_TARGET_= X86 >> *** [all_subdir_lib/clang/libllvm] Error code 1 >> >=20 > Arm failures fixed in r335718. >=20 >=20 >=20 --=20 Regards, Bryan Drewery --jFx8TT88Sy9QJ8uHrcEMeNbJwt3gSbY0W-- --kblqXkkf3rRGvC9WwNVcqFDSRcBWQmyeX 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 iQEcBAEBAgAGBQJbM95CAAoJEDXXcbtuRpfP8F8H/iN0RAj1EPJe/4zU5EIivbX5 mv55NLQ0jm7cukOwssw4aqsqDlouP6vUyFKsO7VKGFmOiHq0OYkGfCkhZqOuec1C NvOocDFQmsIun7E5eBBo6HcFhpqAyd7+9rL94/QVKzzmWmer90fRCQxGtLM8oU3v KIP0B44T9VCh3gDDwfKvRobqh5Qv8iiqGtnGV4US/yNZ1c1L1w6R6EWQC2pe4Gcp BNYSMrhRHlghfenzsCc5VTZxkPeJt3niAnGGOfEvc7U21dPeNVZjMFiAtgGzgy6A 4VHqeqOI6upHcxkYRTp+X776iFVEi8ku8FxGww+AIrRCfNt3T62Zzm9ctrAeIzo= =v3bf -----END PGP SIGNATURE----- --kblqXkkf3rRGvC9WwNVcqFDSRcBWQmyeX-- From owner-freebsd-current@freebsd.org Wed Jun 27 21:38: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 9FA5D1012FC0 for ; Wed, 27 Jun 2018 21:38:00 +0000 (UTC) (envelope-from bdrewery@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 1844D74C99 for ; Wed, 27 Jun 2018 21:38:00 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id C5D601012FB9; Wed, 27 Jun 2018 21:37:59 +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 A36CA1012FB2; Wed, 27 Jun 2018 21:37:59 +0000 (UTC) (envelope-from bdrewery@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 3F56274C8E; Wed, 27 Jun 2018 21:37:59 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (unknown [127.0.1.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 108193F56; Wed, 27 Jun 2018 21:37:59 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id DB41B9BE5; Wed, 27 Jun 2018 21:37:57 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id mO187FixkeBS; Wed, 27 Jun 2018 21:37:54 +0000 (UTC) Subject: Re: Build updates [ ci.freebsd.org FreeBSD-head-{aarch64, armv7, armv6}-build failures as of, for example -r335711 and -r335713 ] DKIM-Filter: OpenDKIM Filter v2.10.3 mail.xzibition.com 83AC29BE0 From: Bryan Drewery To: Dimitry Andric Cc: Mark Millard , "current@freebsd.org" , FreeBSD Toolchain References: <168e5fec-2d38-78e1-6aa4-c51e860ffd55@FreeBSD.org> <7116FF4C-DFA0-41CC-9906-F8B0B5A951EF@yahoo.com> <555a1ac0-a7e8-3ca1-019e-41cf829cbff0@FreeBSD.org> <2a7b1ecb-b647-d09b-4bd7-5c2df62b0846@FreeBSD.org> Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Autocrypt: addr=bdrewery@FreeBSD.org; prefer-encrypt=mutual; keydata= xsBNBFJphmsBCADiFgmS4bIzwZijrS31SjEMzg+n5zNellgM+HkShwehpqCiyhXdWrvH6dTZ a6u50pbUIX7doTR7W7PQHCjCTqtpwvcj0eulZva+iHFp+XrbgSFHn+VVXgkYP2MFySyZRFab D2qqzJBEJofhpv4HvY6uQI5K99pMqKr1Z/lHqsijYYu4RH2OfwB5PinId7xeldzWEonVoCr+ rfxzO/UrgA6v/3layGZcKNHFjmc3NqoN1DXtdaEHqtjIozzbndVkH6lkFvIpIrI6i5ox8pwp VxsxLCr/4Musd5CWgHiet5kSw2SzNeA8FbxdLYCpXNVu+uBACEbCUP+CSNy3NVfEUxsBABEB AAHNJEJyeWFuIERyZXdlcnkgPGJkcmV3ZXJ5QEZyZWVCU0Qub3JnPsLAgAQTAQoAKgIbAwUL CQgHAwUVCgkICwUWAwIBAAIeAQIXgAIZAQUCWujOIgUJCmB7NwAKCRA113G7bkaXz/xpB/9b /UWIPbieY1IeIuHF2pyYPE7Hytkh3HVsxMA0F5Ma2AYQsXZZeKNKWrF7RPyDyDwUklLHJkhm k3EfClBbHxf08kMIm1vWCJRtgxic9knY/bzYGiWMpHjg3cSd1XfrYH1autYqTZAjDwIkgOjU dR//Tbn4V36sY7y2jz+kdMVWvK53U32aZqiwBbCn4DPe1wSZcUs17mV/0uZdIoGdj74B1orN A/0py5vHYo6HcbBNoaR8pKRLf5VZNRsxqGIMhTucx4SJWcHpuRBWYyvJSFzwvxdK4ZD4Yqoc kFGPVtOXktVMai9exrLvP3G77fKMu8DI6j4QRU4wCesnHuIfRPFuzsBNBFJphmsBCACiVFPf kNfaFtUSuY0395ueo/rMyHPGPQ2iwvERFCpeFGSQSgagpenNHLpFQKTg/dl6FOoST5tqyxMq fyHGHDzzU51bvA/IfaGoNi/BIhTe/toZNMRvpcI3PLjiGcnJnuwCCbAVOAGdb+t5cZtpNdOI cKYmrYG3u9RiBpe6dTF+qLrD/8Bs1wjhduQ8fcNNgnkXu8xDH4ZxY0lIc3QgvYWp9vimlQe6 iKjUd2/DX28ETZcD5h6pYV331KMPTrEI0p0yvFijUZce8c1XHFyL1j9sBAha5qpszJl6Uq5i LolhKRcGfcdmtD72vHQjUYglUyudSJUVyo2gMYjdbiFKzJulABEBAAHCwGUEGAEKAA8CGwwF AlrozigFCQpgez0ACgkQNddxu25Gl8+m5Af/R3VEdxNMAcDIes9ADhQyofj20SPV3eCJ3HYR OebTSuNdOudGt4AAyA8Ks94u9hiIp5IGsc6RDsT9W7O2vgXhd6eV3eiY5Oif5xLIYrIDVu1Y 1GyRxRrPEn/QOqDN6uFZCPwK1aOapGcYCrO9lB0gMuTVfgHanU61rgC9tMX0OoAOyRd+V3/M 8lDNhjJdF/IpO3SdYzKfkwduy4qamw4Gphcx/RfYQvYLq/eDkP8d50PphWdboqWBwNRHayro W/07OGzfxM5fJ5mBsXPQcO2QcRjkyHf6xCM6Hi1qQL4OnXMNE/ZTX0lnOj1/pH93TlzSHZMP TaiiA/MBD3vGsXBmBg== Organization: FreeBSD Message-ID: Date: Wed, 27 Jun 2018 14:37:52 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <2a7b1ecb-b647-d09b-4bd7-5c2df62b0846@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EDBzPO8NpXYdNleVxzVf2DakFa9XFrM4l" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 27 Jun 2018 21:38:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --EDBzPO8NpXYdNleVxzVf2DakFa9XFrM4l Content-Type: multipart/mixed; boundary="SDb6VyYRUtHFw3PUu6H4O1RdKgtsmzsQd"; protected-headers="v1" From: Bryan Drewery To: Dimitry Andric Cc: Mark Millard , "current@freebsd.org" , FreeBSD Toolchain Message-ID: Subject: Re: Build updates [ ci.freebsd.org FreeBSD-head-{aarch64,armv7,armv6}-build failures as of, for example -r335711 and -r335713 ] References: <168e5fec-2d38-78e1-6aa4-c51e860ffd55@FreeBSD.org> <7116FF4C-DFA0-41CC-9906-F8B0B5A951EF@yahoo.com> <555a1ac0-a7e8-3ca1-019e-41cf829cbff0@FreeBSD.org> <2a7b1ecb-b647-d09b-4bd7-5c2df62b0846@FreeBSD.org> In-Reply-To: <2a7b1ecb-b647-d09b-4bd7-5c2df62b0846@FreeBSD.org> --SDb6VyYRUtHFw3PUu6H4O1RdKgtsmzsQd Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 6/27/2018 11:58 AM, Bryan Drewery wrote: > On 6/27/2018 11:44 AM, Bryan Drewery wrote: >> On 6/27/2018 10:53 AM, Mark Millard wrote: >>> >>>> On 2018-Jun-27, at 10:01 AM, Bryan Drewery = wrote: >>>> >>>> As of r335704: >>>> >>>> - make tinderbox/universe will now build the bootstrap clang *once*.= >>>> Each target clang is still build of course. This support does not w= ork >>>> with gcc. >>>> - make buildworld (kernel-toolchain and toolchain) will build the >>>> bootstrap clang (if needed per SYSTEM_COMPILER logic) with only the >>>> TARGET.TARGET_ARCH backend support. The installed clang has all stil= l so >>>> SYSTEM_COMPILER logic works for cross-compling. >>>> >>>> This uses the feature dim@ added in r335558 to selectively disable L= LVM >>>> targets. I've added a new option named WITH[OUT]_LLVM_TARGET_ALL whi= ch I >>>> suggest using rather than the per-arch options. It is default on (WI= TH). >>>> Set WITHOUT to only build the needed native arch on your system for = both >>>> bootstrap and compiled clang. Setting WITHOUT disables SYSTEM_COMPIL= ER >>>> support for cross-builds. >>>> >>>> Please CC me directly for any weird tinderbox/universe or clang fail= ures >>>> for the next few weeks. >> >> Thanks! >> >>> >>> https://ci.freebsd.org/job/FreeBSD-head-aarch64-build/8324/consoleTex= t >>> >>> --- all_subdir_cloudabi32 --- >>> clang (LLVM option parsing): Unknown command line argument '-arm-add-= build-attributes'. Try: 'clang (LLVM option parsing) -help' >>> clang (LLVM option parsing): Did you mean '-force-attribute'? >>> *** [cloudabi32_vdso.o] Error code 1 >>> >> >> This was an aarch64 build. It looks like -arm-add-build-attributes is >> from Target/ARM/AsmParser/ARMAsmParser.cpp which is only built for >> LLVM_TARGET_ARM but not LLVM_TARGET_AARCH64. >> >> Looking in contrib/llvm/tools/clang/lib/Driver/ToolChains/Clang.cpp I >> see the option is only added for: >> >> case llvm::Triple::arm: >> case llvm::Triple::armeb: >> case llvm::Triple::thumb: >> case llvm::Triple::thumbeb: >> >> But not llvm::Triple::aarch64. So where is it coming from? >> >=20 > cc -target aarch64-unknown-freebsd12.0 > --sysroot=3D/usr/obj/usr/src/arm64.aarch64/tmp > -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -x assembler-with-cpp -m32= > -shared -nostdinc -nostdlib > -Wl,-T/usr/src/sys/compat/cloudabi/cloudabi_vdso.lds > /usr/src/sys/contrib/cloudabi/cloudabi_vdso_armv6_on_64bit.S -o > cloudabi32_vdso.o >=20 > It must be the -m32 here making it build with llvm::Triple::arm. > So we may need to include more of LLVM_TARGET_ARM in LLVM_TARGET_AARCH6= 4. > I'm testing locally to see how much is needed. >=20 r335747 should fix aarch64 but it's not necessarily the best fix. It may be possible to reduce how much of MK_LLVM_TARGET_ARM is needed for -m32 support for arm64. I didn't look into that too much. --=20 Regards, Bryan Drewery --SDb6VyYRUtHFw3PUu6H4O1RdKgtsmzsQd-- --EDBzPO8NpXYdNleVxzVf2DakFa9XFrM4l 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 iQEcBAEBAgAGBQJbNAOwAAoJEDXXcbtuRpfPUQAH/RF2rqWR4d/8NZcgj0gYdmva wJnl+3HK6Ty+EiJEpd8x/YlQTSCLGpoZC2AvyOzRWyYPoj9GvlZaxPRcWYXYknbP OEXRoMyg5wMtzvrTFL4KGpGwImMzsoFOB93aaUvXnd0G/i3Uad7X/yxhB+9/pSCP BVGc+/8afd9UfYzCaZipM++KGNb9PTk2jbhLw3ytBnmOA0os2BEpi22SqW4oaJhY PtohyRhK++WMknoeeSZil4o7v0ELaswS7NZhLoJZDFuEahZ5aZd+226KFbnxg+xh hBCecXNC5sG7wQ6ppdyi3jnHbnVYOWnC6Sd3FOJEgLdG1ae93R19MiGsRWMVpl4= =z1NL -----END PGP SIGNATURE----- --EDBzPO8NpXYdNleVxzVf2DakFa9XFrM4l-- From owner-freebsd-current@freebsd.org Thu Jun 28 01:32:01 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 5345F10257B4 for ; Thu, 28 Jun 2018 01:32:01 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::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 DC8627E4B7 for ; Thu, 28 Jun 2018 01:32:00 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x230.google.com with SMTP id a195-v6so10322374itd.3 for ; Wed, 27 Jun 2018 18:32:00 -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=Y171on4PnONujMJUv9CsNTwzepmycb6A/sutI06Ta18=; b=Yg352s6p/ar75J0HMRj+8KEM+HEqitIlOj2A3lZS5FFqdov4wgBcB6/k5/q0g/fIRh gERRvpJ6CxQOGaOW62gs9o11jceQyCw4DA7VL231J64PG2CzymyCDSsxSsDY4ya2GgC7 ocx1R299Ovn4NruxZvoeHiGGJ9rTz2bUyWoEs6mtEFqchJdzMVZpeSVNwg5yHyVOIR+f rSeRx44v7Ohf2N096MKmuZFbbv4UyKlrs/eg+WEVnFeItJ1M7lvQChGVgH4tXwQSIALs efPFF3vF3sC+zgk7DRrMv3lXTv7BxnCQicjLvwr0Bw2E6IMSAPX6xJb0EVXUrnx9TF3u dI6w== 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=Y171on4PnONujMJUv9CsNTwzepmycb6A/sutI06Ta18=; b=kUBvcIZNvv4eXlv7EcV2kxKQxQiDn4MQyMXEZJJGHseDe1YmR76S1azXwbDWtNYuhK 1xphNmXktAFeedc1sMouSi4z+HshQXR4SHeru7Tjkt00OGrFtmlcADeRb7L+1fBdIh4f TKDIvG9hBopP8xhjwCwVEzJawxcdzbrPqiOq7K86waq0fvPY/7wstt1XgugmnPr3W7xz 74PGvIy0rDLj4RJCXi6tbdv9qYsrjBVXbGuFNEUVBAx9Jyfj23rNeADPGzAcf2dFYGYB zLIPOXtf9YSS+QGTYrAwVNsWgtWvkWZo19DBSEAD5Xh6rQjUjkEhsja+HhtQcV0/uI1V G7bQ== X-Gm-Message-State: APt69E3KcrjndilxmmuXBaqs02sa2wL7uCjH9qJVsopBGnkU3dR/KXGi db6Nqe1G16s3gQaY0ZbecN2ScrxWmKeqe+Ht+jAi7w== X-Google-Smtp-Source: AAOMgpeKCmgMRNkZ9mXptg1SiWGc8W07aCjTzF4hjtvpd/J//AgjzDzkt6YWm0QyqiRvtBHzG3jN7hHfgpcivLHdTu4= X-Received: by 2002:a02:6001:: with SMTP id i1-v6mr7148513jac.5.1530149520126; Wed, 27 Jun 2018 18:32:00 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Wed, 27 Jun 2018 19:31:36 -0600 Message-ID: Subject: Re: svn commit: r335753 - head/sbin/devd [ broke the ci.freebsd.org FreeBSD-head-{mips,mip64,powerpcpowerpc64,powerpcspe,sparc64}-build ] To: Mark Millard Cc: Warner Losh , svn-src-head@freebsd.org, FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 28 Jun 2018 01:32:01 -0000 On Wed, Jun 27, 2018, 7:27 PM Mark Millard wrote: > These are the gcc/g++ 4.2.1 based targets. > > For example . . . > > https://ci.freebsd.org/job/FreeBSD-head-powerpc64-build/6261/consoleText > > --- all_subdir_sbin/devd --- > /usr/src/sbin/devd/devd.cc: In member function 'std::string > config::shell_quote(const std::string&)': > /usr/src/sbin/devd/devd.cc:652: error: a function-definition is not > allowed here before ':' token > /usr/src/sbin/devd/devd.cc:1327: error: expected primary-expression at end > of input > /usr/src/sbin/devd/devd.cc:1327: error: expected `;' at end of input > /usr/src/sbin/devd/devd.cc:1327: error: expected primary-expression at end > of input > /usr/src/sbin/devd/devd.cc:1327: error: expected `)' at end of input > /usr/src/sbin/devd/devd.cc:1327: error: expected statement at end of input > /usr/src/sbin/devd/devd.cc:1327: error: expected `}' at end of input > --- all_subdir_kerberos5 --- > > > The following is modern C++ syntax that is being rejected: > > . . . > for (const char &c : s) { > . . . > > (At least if I understand right.) > C++11 I thought was required. If not. That the issue. Warner > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > > From owner-freebsd-current@freebsd.org Thu Jun 28 02:10: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 E8F391029D61 for ; Thu, 28 Jun 2018 02:10:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-21.consmr.mail.gq1.yahoo.com (sonic306-21.consmr.mail.gq1.yahoo.com [98.137.68.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 7395A80BA2 for ; Thu, 28 Jun 2018 02:10:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 8VrzPN0VM1loPUwCfchFZcUtNsBX3xCvKYGVHcuQBzt9ElOyzwcdOUW8rvDyvs6 xL9p0QiP_H1z5QZ5sp7LwEte70GGB2W7G35qNmyJyU4JiXZ81wodCpKH9iwMLA1nq3kD8IK_Mrct P..PRxLeHBgcILA6qMhgVVaZzYlwgNinBZ.ZlVvuwVY3U6qBSpwrQtuA6nEZyJaN9fFfOtRcgVCp aFpk1dnroPokzBITkZ5tv4fXRxIv1C6l2.50EyHF64RIhyIEjO4bBVEu5dQuewzoWMDGHS5MStDM UI.zzXynR0C.D7CVfP3ziORdAjVF32qASxTT7MdTH6seP_pjd0KzBrMz3dK2oCac1F8lU47IUvof n7SYHDWfu1KGrmrcFc91qd1m5bEaiDuLwUKaibyjgc1GPxX5bFQktiYaCNUW3XzKE_RdE4N1LmA8 dE.L0RTkHf5lN3cUHoT_zYJQPIzTg5iQlxHTVfLOSA6Yq3E9Q6yWfONeT4fRlIKrgHWM2Ed59.am X9oW3fa3PYclxBBhM8J5T.KOXn33MdouUZyX0pwOvuiXgrjaUjwqcKgXYqVDLQKWQE0nUqWq8zUL oFEBMZp6fWikhD_xwkhMU2fZwlxxqNFmYGchutDiqxuhPTvMpQt0SEo.p2OrIVNMRLXWydyFhZYc iQ1TPrmZhVBwLxvJdW8u._bD2V_Ekty90UhRpeeIpQLHq47ymaShNtOa9kIDRdj32KMj84tWgoYA MKrx19PHCh6bsFNll7niHA7OAedQelZcrLumyz5ZKdVDL0BPFGBUhjgAHV3ECF1Lc8Pc8aLuKnuS EMJNcotaSj0_CR.CdE9zPp6ku1ZAu0ZuldMRY9Cva.osfftB.rwdDx6TouEf_rx2J4PHcllvdZoe AAcWCsXmvVNgRtgclUHsc7lfi56S7SaGRF48od5vFPvFbq3kEAdPOLUmWmz3q632qP4kxjmCI.YA Z9H89keD38jU8I2QUKan5AIqelyid Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Thu, 28 Jun 2018 02:10:51 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp427.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 512eccaaade6fd164f4aed6a55c6334b; Thu, 28 Jun 2018 01:40:28 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: svn commit: r335753 - head/sbin/devd [ broke the ci.freebsd.org FreeBSD-head-{mips,mip64,powerpcpowerpc64,powerpcspe,sparc64}-build ] From: Mark Millard In-Reply-To: Date: Wed, 27 Jun 2018 18:40:27 -0700 Cc: svn-src-head@freebsd.org, FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <5DCB8E46-964D-4590-B1B8-31523D6834BE@yahoo.com> References: To: Warner Losh X-Mailer: Apple Mail (2.3445.8.2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 28 Jun 2018 02:10:53 -0000 [I used the wrong Email address the first time.] On 2018-Jun-27, at 6:31 PM, Warner Losh wrote: >=20 >=20 >=20 > On Wed, Jun 27, 2018, 7:27 PM Mark Millard = wrote: > These are the gcc/g++ 4.2.1 based targets. >=20 > For example . . . >=20 > = https://ci.freebsd.org/job/FreeBSD-head-powerpc64-build/6261/consoleText >=20 > --- all_subdir_sbin/devd --- > /usr/src/sbin/devd/devd.cc: In member function 'std::string = config::shell_quote(const std::string&)': > /usr/src/sbin/devd/devd.cc:652: error: a function-definition is not = allowed here before ':' token > /usr/src/sbin/devd/devd.cc:1327: error: expected primary-expression at = end of input > /usr/src/sbin/devd/devd.cc:1327: error: expected `;' at end of input > /usr/src/sbin/devd/devd.cc:1327: error: expected primary-expression at = end of input > /usr/src/sbin/devd/devd.cc:1327: error: expected `)' at end of input > /usr/src/sbin/devd/devd.cc:1327: error: expected statement at end of = input > /usr/src/sbin/devd/devd.cc:1327: error: expected `}' at end of input > --- all_subdir_kerberos5 --- >=20 >=20 > The following is modern C++ syntax that is being rejected: >=20 > . . . > for (const char &c : s) { > . . . >=20 > (At least if I understand right.) >=20 > C++11 I thought was required. If not. That the issue.=20 Looking at "C++11 Support in GCC" in: https://gcc.gnu.org/projects/cxx-status.html shows almost nothing is supported prior to gcc 4.3 . Some things require gcc 4.8.1 . As for "Range-based for": it requires gcc 4.6 . The SD-6 feature test listed is: __cpp_range_based_for >=3D 200907 =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 Jun 28 12:03: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 4B7E1102FEFA for ; Thu, 28 Jun 2018 12:03:39 +0000 (UTC) (envelope-from alexvpetrov@gmail.com) Received: from mail-lf0-x242.google.com (mail-lf0-x242.google.com [IPv6:2a00:1450:4010:c07::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 8BD8F78E02 for ; Thu, 28 Jun 2018 12:03:38 +0000 (UTC) (envelope-from alexvpetrov@gmail.com) Received: by mail-lf0-x242.google.com with SMTP id j26-v6so4006056lfb.11 for ; Thu, 28 Jun 2018 05:03:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=dgSecJJLal61yenGia9hIqaAjjtLfsUqSvbl0cqKSlw=; b=atCx8M12JBHyGpxhHx0ylxzJEoT3qbCW25ODZUdCpHpSfS6406ApBglImzx1bHtMHO dtysY6txEri/Q+UGiuAutE4wKv3Ie5c8cgaWPnOGcVS0Ev4I0lx/42WWawMUI7gpKvM8 Xmz3HclJyMbSBFPJfgNrOXnKUJj2xLD5yiqxu4QK71/y83HNpcCw8ixj8AAGGEhHMWY9 BvpPT34DpMbCEhAgMc3JodzgraNDhXHlFbk5NPhow5jdh/uzx3RNl7FWkm4Kljw+hG5A HVys/W1qkGy4aK6FBfCSdwhuhcMky0nfb3dB/4o3lAujozYXINQ8mhrZNI7IdWBTnvV5 hwjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=dgSecJJLal61yenGia9hIqaAjjtLfsUqSvbl0cqKSlw=; b=qRLFbv1Rt/XdIB3RG51/ppFr4LMdXXm0yVsQLeGTLUyvXxyBcTqsL/pz7QGABTE3NZ lYw97EjkUcxNTMkUBKMT/D4bTEn9PwxWXCIDubEadMUpX8r35ALbmfhUc7HgkzYHtLKp won9sBKmhaWzuIPFpUiLAC399zsnCv/bpEtYfTFlRqNbo58J0RfhJZ8HGAipAHqkCNej cHz2KCRDHtpGe37h4RUxZKV7d9x5eb8NrG2kP27CkcyO1DIO1meM+SiA2C9BFbrrNHrR LeC1gnx/JS8BHMBvLHCtNlFLO9kkxEgbkWs9GaSFTyHcXpbMmflpKCAYtlw+vjXn9sF5 z7Qg== X-Gm-Message-State: APt69E1ovshaUMAV1g/walGLM5huhvzTxfhgckeDgvv3BNmlA7qD2Toc /2/gzBjTb/EsTLX08ZtwBIKAYA== X-Google-Smtp-Source: AAOMgpclukf8FpOjq5hjoMp0Xm5xFKzhw/cjCNF7GDLlbwKnwSwPfX1IA1Fx5WSHum5a2BrXRYCQKw== X-Received: by 2002:a19:2601:: with SMTP id m1-v6mr7209971lfm.106.1530187416830; Thu, 28 Jun 2018 05:03:36 -0700 (PDT) Received: from alex.super (stone.g-service.ru. [84.22.141.217]) by smtp.googlemail.com with ESMTPSA id h11-v6sm644521lfj.47.2018.06.28.05.03.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Jun 2018 05:03:35 -0700 (PDT) Subject: Re: Help USB keyboard trouble To: Hans Petter Selasky , freebsd-current@freebsd.org References: <20fe1b1c-1563-ca86-a10d-a91684244c2c@gmail.com> From: "Alex V. Petrov" Openpgp: preference=signencrypt Autocrypt: addr=alexvpetrov@gmail.com; prefer-encrypt=mutual; keydata= xsFNBFr3oA0BEADMSXiVd/IwYhJPMQ6LXbZ7jTA/RXuzrGYaR++UENx5QJ6/HJ/3myTeMnZE nNa0Zme+oKw/9s5x7rBTP6mL5ta7VSYpnPX932mAjT9J4nS7iW/wWNBqcXn7wDCog2TV8Ww3 13SUP2YaKoJKJLxddiZD6AJrkafB9EE/AycMQ8XxMao1lVS+/KAo0yciOsnSlIJCWhF00b3j xDlHLvehrDa4S3EB13bF6uE0XU5nFfMNHtBav2mwD9t01hNioCNTV1hXwmsS/L1n5PR5FyJJ yYtjeohrAUiGKGJU9lJJ6tROBhzV/k3OsOGPyajFOVsW0vUueYfgw+IAPYdOZIAONgNdxkvs tRLQxYPCBMN1FvQ7GlIhq7ob+mxuA1imXx3xzlYy5tu4QzB383qZtLqQnZpysjYooAbHl+eN vB2ldvH9TZxm3fxxNL6zgYAXE/pNgFoqg/ILmhDwvvHzApHqVCKU3g6yii0KPxD7susaUWcL JYgrmt2BIE0RuiQRGWyS0L277D/YGmVnPNHxPi58DBs2iexDm7jw7PhlmfOw44N9w+O09D2S gqmBHySAtsq9Z5LoM81F+LrOoVmpYczZWErS917Gua1X7K3wrXoqQC8qcSiHZpEcBl/Uohii QWzjQJot5LT7rvfFHpnSOXAKgN7enVM7KxTJAYK1U343GGdepQARAQABzTZBbGV4VlBldHJv diAoZmlyc3QgZ2xvYmFsIGtleSkgPGFsZXh2cGV0cm92QGdtYWlsLmNvbT7CwY4EEwEIADgW IQRvKPTT2TJuh37ANx313p8aVpVkcAUCWvegDQIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIX gAAKCRD13p8aVpVkcLLeEADClYAElEInGGjtLfH4jdjvTDaQTsrwT5/1E5/h8yxI4yn7hCt1 Dh+iCSUNLdPO88nZV2jP8bMQXFBKSbC0nAJXd8O+8t9AfSWoUC6IMzncxKTK/jZuJTCToCUR XZ+47+uJaBp51rpw3pFX8UrFlYSF6Dz97dI2cGHfx3xAOnowKxyHfthxS8waKWgbMOceds78 BP2+Q0iLCpoC9rO4KDc+w+h8z21eHIE9VHadTHpnKVF82voPH8XWvznTOCpYrdBwUtIyD/DV XRb0xcFsOSkvmReYX7u4QuOPLSc86sEWh4hXTFLAOdfeTjrDTDmBcmFpltmW1j+5t4mI1dK8 gptREM8gMJVJw3jjcO6jADeXX9q5C8/lX0sEGz9uC4oU5nkOMyfzd9Anb+9bCs7pMxhqAKjA 8tqJPPkmJU8WzMCs+uudIiQ8W9qIETwUJWxizQ3kvlzLfWRz5n93Y9kzSmjw81aiIJK/HFY8 wsW5zNo6JBn57cMPx8nBC4E2zM09ffmqSpjDwXfvZF2IIR8L4VTiKi3ovwLglJP+Qbs5HXNn 6K40cPNqfnHzPLwXwd/co04B/VVr+cKZuE58kYGty9Xs9q/SEpObDnxnLxMNHUNJJuRgOiti TKDkteHuKm6NA8v05o3TDQ5HU9szEoE5uoi/3pQ1ktfA/K3LkDwbotXL+87BTQRa96ANARAA w5+/xcaCP6iwsi2CFQ4pAWksdmPBEHA2VPn1ym3C6opjbyWUp6sn25eTWppdhA9rUqbM/zV/ hAFRT67oZJKBYNRaMoDdO8BsVZsg/u76QF/GuhbUjIk0tFFdpddMXl0zKAJJMCfDRxURRWv7 NW6sY/EZ4Dal5s4xOT+UrWGag3qoaIRdzw5bJRP+o75L90cE8pd7+Pd9cVJOOtTAwx0E4bPq dPSa6CPDSvzd9D3mw37dPzXysyQkQTy0OM7255E2wjYz3RbJxB3utybPVN3XJBD5EyA8IYeS ic1/03UrkRNv4XrLnlg7xLv96ZeCrf/BDNQW23iVwbISUAk4TXL7xs2TGYOmowZ89mMEcbfW ChX3YLAuAeWzgpMcrDC00izOxG0spkkrHL7/i1iSu2MKhv5qMTVgchlSktdd+KTba5keleHv ULQ3feGUKf9eTkKgES6q4rKrae0tIwByTLhhDVbkXqR6v8zrpJSscrvJ3tMNgquJKy5ATIUB nvUE2hMkSwtnJ2vQ/Z0zGt6c5KxI57/hsb148tXp1v3gAq9d6i8c8ChxSR/kUlqAvzl2QGcn CFVN6nfOzyNfBPZ61abNzkzjzyhOK4Gq4gQvx4QXhDp3jEME7rPM0Tqf0venb1Dp7SIHwggV yJglGApwoUvD4kKNIC7KDr+s/UjbBp4ExFMAEQEAAcLBdgQYAQgAIBYhBG8o9NPZMm6HfsA3 HfXenxpWlWRwBQJa96ANAhsMAAoJEPXenxpWlWRwAaEQAKm0imG5Fm37JZi+5faXJv/ZLZGl r4TVg4u1kMktdTQRrTXa3Qs0i3wTtOZe1p3xCCzPx+97iYETHragDTdAFUO+v+Llin26L1Zl z4huyIqgGSuTuekQfn6eoMZbcF+wzah4j/mvXQVpJBF2qQi1YdHSapWDlweuiuk01y8C3eHv 3qfFB/OJwXhwj0HKhkGkB2dLXuLtIk4GCXh4/g22tWz/SB0gsSXU7WhJFb0CyxETGR9YKxM8 CNl5tVRLqsBC6yQLvcAJgJci73PfMiHKnjxrz//+0xQO1TPeruWsd8nLYvziT38CyX42Mbaj 01WpvB0qOeTGtwGFmyyrnE8fYpd3CE0uAl9BnHqafAabl9+09x3wf+lEkkO2bK59akZz3BPU 8Lz2BAgskyS81WZCthQYUrUozFEx/31x8JJ95EQFNW9t8HBa51r4QhedSNKxLbT3Sx8hH0iq Z8wYkGw0og9U1DqgFzxE2HSGZSDG3I1DrPDqhcM/6Y0V98wS+XreuS88DYYck37+L7bTGiyZ WYFNZk1ChcIBk8hgKn5nFOCWO2rX06RI9zorzSpEg6lB2STae1Up5oEj8QqfYmfO3cp2Qhvj F3c2/i8KpWkJQkAgNrv428FIlx9SiPu9gvNTTYuLIOdZLQvInTmKs2uCoB6JDAW75axDhBbR FvM3Vpv/ Message-ID: <611ac686-9be4-0663-023b-d0fca2c6a8ce@gmail.com> Date: Thu, 28 Jun 2018 19:03:33 +0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; 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-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 28 Jun 2018 12:03:39 -0000 The result of my new research: In Frenzy (livecd on FreeBSD 6.1), the keyboard works fine. In the system console(current), when connecting to my problem keyboard, the output is working, and keyboard input is not. And after disabling the keyboard input does not work. 09.05.2018 14:08, Hans Petter Selasky пишет: > On 05/09/18 05:52, Alex V. Petrov wrote: >> The new USB-keyboard "Qumo Dragon War Mechanicus K11" continues to print >> "A" when connected, as if the "a" key is pressed. >> But in Windows and Linux keyboard work normaly. >> >> In log: >> >> May  9 10:43:38 alex kernel: ugen2.3: at usbus2 >> May  9 10:43:38 alex kernel: ukbd0 on uhub6 >> May  9 10:43:38 alex kernel: ukbd0: > 2.00/1.00, addr 3> on usbus2 >> May  9 10:43:38 alex kernel: kbd2 at ukbd0 >> May  9 10:43:38 alex kernel: ukbd1 on uhub6 >> May  9 10:43:38 alex kernel: ukbd1: > 2.00/1.00, addr 3> on usbus2 >> May  9 10:43:38 alex kernel: kbd3 at ukbd1 >> ^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^AMay >> >>   9 10:43:46 alex kernel: ugen2.3: at usbus2 >> (disconnected) >> May  9 10:43:46 alex kernel: ukbd0: at uhub6, port 3, addr 3 >> (disconnected) >> May  9 10:43:46 alex kernel: ukbd0: detached >> May  9 10:43:46 alex kernel: ukbd1: at uhub6, port 3, addr 3 >> (disconnected) >> May  9 10:43:46 alex kernel: ukbd1: detached >> > > Hi, > > Can you show the output from: > > usbconfig -d ugen2.3 dump_device_desc dump_curr_config_desc > > And also have a look at: > > usbdump -i usbus2 -f 3 -vvv -s 65536 > > --HPS -- ----- Alex. From owner-freebsd-current@freebsd.org Fri Jun 29 00:39: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 1ABFF102DF9D for ; Fri, 29 Jun 2018 00:39:50 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-11.consmr.mail.ne1.yahoo.com (sonic313-11.consmr.mail.ne1.yahoo.com [66.163.185.34]) (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 9322E7594C for ; Fri, 29 Jun 2018 00:39:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 598XcdoVM1kwYkiVoQRlSQVSImXI_ANlNskKc_YH0m_AYtQlpyw8WghXqggmeIZ I1s_Jao9mhckgH2LCB8BeopGt7Yu5Qz.814ZGeFJdmtNQWIzi71fWcrvGiXZS8MEQm6n3v.Tu0mS g3xATj5p.4xy9SlUvQCxYulZw3DGoB07Sl7xB5jaXVKKc0XtIBONfg9keTf9_OohwNsGTy43y7iH onvAbdJd6kjWL9Z09XJVdoBoepxLC.La5qIYuuHiZnc0IFuqUhrROL5myeVLpvxJfKOupqpauKIu KqCV4jTKp9Fa3hneNT4HF3QSnVTxPyvC2tQ6F4kGNGQIQICnUih1Wl3RsBdIEMUwi3HzdtQKwfzL NKiJDcrVM0K8yHMHN6TXd1kFd3ej.ZUzTLXWrrE3qYRnhKSXL6LYqT9QKJeSp2paIuMGt97TpPmD PhUbLPnpGp0frJ6XMU3wBx55o2zj65s5xt5Ab9RxXi4Lzz5cMLJV5yofaS.W.pBrZf2qRMbieJh1 IjHbOvegjVvtQapc4cx9FQkTn01DlrI3dTOknWNleRp2WtZ0KirfhiJEQh9mQT_Sg6SGRIoDfaQt adqcaputMnuE5RCCPpQK1uC7k3Ei08XmjtiZyOapTXTft1ncIvxgOf5daCAvI4fg20IuisNn01KC AvCVXfk9KluPTtjj4uPQnJZer9pcWXBBcBfkxxzEHlWNvBnEjIfJuXDqTawGDvD3y_3Tqze1f9Tv S3c5wqTLr8uxJUmuvXi40NCrhSiu2Lgi76YmZGOkbThuHR2arctS_TFYfISK5NqRlFbZNVl66jgr zEzFar5Fw3liwt7HBRAVlFspRkIRRlizORp8ibvnJc9FrerCAiimRY14ut9OxtAoajG7AYLx7_bu ebxky8ywCt..DybmViAUVOWktFZKYYIuK3KHgWqf16THxi4FouHx63wsFppGTX1kWrVQREbAmcQl 35z73qOes4NIfF0dS1Hs0bTqn_XXY_M6k8us_ Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.ne1.yahoo.com with HTTP; Fri, 29 Jun 2018 00:39:43 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp414.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID f117e9f8911bcf030321b581cb8923ba; Fri, 29 Jun 2018 00:39:42 +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.4 \(3445.8.2\)) Subject: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build) Message-Id: <00D1127A-1F0E-4E0E-B86C-1C5AA5B2E085@yahoo.com> Date: Thu, 28 Jun 2018 17:39:40 -0700 To: John Baldwin , svn-src-head@freebsd.org, FreeBSD Current X-Mailer: Apple Mail (2.3445.8.2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 29 Jun 2018 00:39:50 -0000 [ ci.free.bsd.org jumped from -r335773 (built) to -r335784 (failed) for FreeBSD-head-amd64-gcc. It looked to me like the most likely breaking-change was the following but I've not tried personal builds to confirm. ] It looks to me that: > Author: jhb > Date: Thu Jun 28 21:26:14 2018 > New Revision: 335782 > URL:=20 > https://svnweb.freebsd.org/changeset/base/335782 >=20 >=20 > Log: > Remove the various build flag hacks for GCC cross-compile. > =20 > The xtoolchain GCC packages have not required these flags since = ports > commits r465416 and r466701. The in-tree GCC 4.2.1 has also been = patched > in r335716 and r335717 to correctly honor --sysroot when looking for > includes and libraries. > =20 > Reviewed by: bdrewery > Sponsored by: DARPA / AFRL > Differential Revision:=09 > https://reviews.freebsd.org/D16055 . . . broke ci.freebsd.org's FreeBSD-head-amd64-gcc build. https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6331/consoleText = shows: --- catrigl.o --- /usr/local/bin/x86_64-unknown-freebsd11.1-gcc -DCOMPAT_32BIT -march=3Di686= -mmmx -msse -msse2 -m32 = -L/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/lib32 = --sysroot=3D/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp = -B/usr/local/x86_64-unknown-freebsd11.1/bin/ = -B/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/lib32 -O2 = -pipe -I/workspace/src/lib/msun/x86 -I/workspace/src/lib/msun/ld80 = -I/workspace/src/lib/msun/i387 -I/workspace/src/lib/msun/src = -I/workspace/src/lib/libc/include -I/workspace/src/lib/libc/i386 -g = -MD -MF.depend.catrigl.o -MTcatrigl.o -std=3Dgnu99 = -fstack-protector-strong -Wsystem-headers -Werror -Wno-pointer-sign = -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 -Wno-unknown-pragmas -c = /workspace/src/lib/msun/src/catrigl.c -o catrigl.o /workspace/src/lib/msun/src/catrigl.c:90:2: error: #error "Unsupported = long double format" #error "Unsupported long double format" ^~~~~ /workspace/src/lib/msun/src/catrigl.c: In function 'casinhl': /workspace/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; ^~~~~ /workspace/src/lib/msun/src/catrigl.c:190:35: note: each undeclared = identifier is reported only once for each function it appears in /workspace/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) ^~~~~~~~~~~~~~ /workspace/src/lib/msun/src/catrigl.c: In function 'cacosl': /workspace/src/lib/msun/src/catrigl.c:250:20: error: 'm_ln2' undeclared = (first use in this function) ry =3D creall(w) + m_ln2; ^~~~~ /workspace/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 /workspace/src/lib/msun/src/catrigl.c:45:0: /workspace/src/lib/msun/src/catrigl.c: In function = 'clog_for_large_values': /workspace/src/lib/msun/src/catrigl.c:316:34: error: 'm_e' undeclared = (first use in this function) return (CMPLXL(logl(hypotl(x / m_e, y / m_e)) + 1, ^ /workspace/src/lib/msun/src/catrigl.c:316:11: error: '__builtin_complex' = operand not of real binary floating-point type return (CMPLXL(logl(hypotl(x / m_e, y / m_e)) + 1, ^ /workspace/src/lib/msun/src/catrigl.c: In function 'catanhl': /workspace/src/lib/msun/src/catrigl.c:390:11: error: 'SQRT_3_EPSILON' = undeclared (first use in this function) if (ax < SQRT_3_EPSILON / 2 && ay < SQRT_3_EPSILON / 2) { ^~~~~~~~~~~~~~ /workspace/src/lib/msun/src/catrigl.c:396:9: error: 'm_ln2' undeclared = (first use in this function) rx =3D (m_ln2 - logl(ay)) / 2; ^~~~~ *** [catrigl.o] Error code 1 =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 Jun 29 01:15: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 3ACB6102EC05 for ; Fri, 29 Jun 2018 01:15:17 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-35.consmr.mail.ne1.yahoo.com (sonic317-35.consmr.mail.ne1.yahoo.com [66.163.184.46]) (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 B98FB76AE5 for ; Fri, 29 Jun 2018 01:15:16 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: YYf1xk8VM1mm0gWbxCFbx2WDPgKIJo5a0T165e.R0ClpFYkgOJv6x3s_RiiwjSq iCpfwrQxOe_M4zrzazO9GZJvyiZTSaTmaascPO4GOizzHBp5m3zouc7s6QgkXUxy6IN94zezVMgr dpSLQbSXiR_vHLbWrAeANra1sBfH_oP1ifmTFj3oeX1y9_msG8R1SdIurodOURH9Tzwqh7EMYmqi KqqR0.YvZg1rHy2DjRVSTnlLxZcFx05.vSP0BCVsyTg26OiwO0Uo2c5GXc2BEPX8Th9QHUxzsRiB S3d7i1XeP9jBkrN.W1EjOGs9pq2A8oKM0uJ.kcgfjVbd3ffysuSECFoT4bQaZfyt_gYbr88X1Ui8 WOb5hg_OIyO5wqD67hPaOT38ok9ck7hMSUcpnBmMyWXifnK_m.jG87ZuUVVYvQKsQ7BQkQVv4xMi 2pVZfBNb0alHArTHWcR0_MzJoP7pDWzxHe9hIaHtvKnE6MLHLS9g7fcI5Tqf_zDr8pGv0FotiChT bgNBle_XzW65S0I9YjumuHxa5.dMpDE9zx9.Cvvr_tCaFAVLe9BHe0gbZripc4b670e.JqoS4nFA DlJNSMfxWxE6paTan.XnJ.TMO32QCD3uz96ucmLAERTbbCFSEFGk3RbnfvdYeU3GBlJ7Ej.6JtwQ bUJnzB5Yys1kXFyXgTg4KrZ2MdSB9eovF8TVmRv.BkzVqxTNaCDk3InOXbrmFPPRVocg.yTyKVfM rb22iVO0O2BlD7hiTbbGJNOXqmYl9DD4YjuEu3bVU1L2ZKgfxGcE4_hLV35UG3KtJtLH4YneKfAc FYCR.gUAqrMsxSPQGkz2g2DHSL8SesGPYVxsUnlIe98QLPiU0vI7VQveZ9b5GVdN0W7mU3hp9Ii. OWJvS6fhTtW8TAtEcLQExzLJtHvRVisJ82a7JUqn7WHEvSljoEN8HSebyJfPDn5Xkzw2786ZUV.D 83OzAsWdSd7vYuh6wCSi6YJv9nIBNc3q14MrtXDdWZj4m Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.ne1.yahoo.com with HTTP; Fri, 29 Jun 2018 01:15:10 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp404.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID c38efee9d6e0c07aa84e0bf10ab38f06; Fri, 29 Jun 2018 01:04:59 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build) From: Mark Millard In-Reply-To: <00D1127A-1F0E-4E0E-B86C-1C5AA5B2E085@yahoo.com> Date: Thu, 28 Jun 2018 18:04:57 -0700 Cc: svn-src-head@freebsd.org, FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <00D1127A-1F0E-4E0E-B86C-1C5AA5B2E085@yahoo.com> To: John Baldwin , Bryan Drewery X-Mailer: Apple Mail (2.3445.8.2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 29 Jun 2018 01:15:17 -0000 On 2018-Jun-28, at 5:39 PM, Mark Millard wrote: > [ ci.free.bsd.org jumped from -r335773 (built) to -r335784 (failed) > for FreeBSD-head-amd64-gcc. It looked to me like the most likely > breaking-change was the following but I've not tried personal > builds to confirm. > ] >=20 > It looks to me that: >=20 >> Author: jhb >> Date: Thu Jun 28 21:26:14 2018 >> New Revision: 335782 >> URL:=20 >> https://svnweb.freebsd.org/changeset/base/335782 >>=20 >>=20 >> Log: >> Remove the various build flag hacks for GCC cross-compile. >>=20 >> The xtoolchain GCC packages have not required these flags since = ports >> commits r465416 and r466701. The in-tree GCC 4.2.1 has also been = patched >> in r335716 and r335717 to correctly honor --sysroot when looking for >> includes and libraries. >>=20 >> Reviewed by: bdrewery >> Sponsored by: DARPA / AFRL >> Differential Revision:=09 >> https://reviews.freebsd.org/D16055 > . . . >=20 > broke ci.freebsd.org's FreeBSD-head-amd64-gcc build. >=20 > https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6331/consoleText = shows: >=20 > --- catrigl.o --- > /usr/local/bin/x86_64-unknown-freebsd11.1-gcc -DCOMPAT_32BIT = -march=3Di686 -mmmx -msse -msse2 -m32 = -L/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/lib32 = --sysroot=3D/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp = -B/usr/local/x86_64-unknown-freebsd11.1/bin/ = -B/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/lib32 -O2 = -pipe -I/workspace/src/lib/msun/x86 -I/workspace/src/lib/msun/ld80 = -I/workspace/src/lib/msun/i387 -I/workspace/src/lib/msun/src = -I/workspace/src/lib/libc/include -I/workspace/src/lib/libc/i386 -g = -MD -MF.depend.catrigl.o -MTcatrigl.o -std=3Dgnu99 = -fstack-protector-strong -Wsystem-headers -Werror -Wno-pointer-sign = -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 -Wno-unknown-pragmas -c = /workspace/src/lib/msun/src/catrigl.c -o catrigl.o > /workspace/src/lib/msun/src/catrigl.c:90:2: error: #error "Unsupported = long double format" > #error "Unsupported long double format" > ^~~~~ > /workspace/src/lib/msun/src/catrigl.c: In function 'casinhl': > /workspace/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; > ^~~~~ > /workspace/src/lib/msun/src/catrigl.c:190:35: note: each undeclared = identifier is reported only once for each function it appears in > /workspace/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) > ^~~~~~~~~~~~~~ > /workspace/src/lib/msun/src/catrigl.c: In function 'cacosl': > /workspace/src/lib/msun/src/catrigl.c:250:20: error: 'm_ln2' = undeclared (first use in this function) > ry =3D creall(w) + m_ln2; > ^~~~~ > /workspace/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 /workspace/src/lib/msun/src/catrigl.c:45:0: > /workspace/src/lib/msun/src/catrigl.c: In function = 'clog_for_large_values': > /workspace/src/lib/msun/src/catrigl.c:316:34: error: 'm_e' undeclared = (first use in this function) > return (CMPLXL(logl(hypotl(x / m_e, y / m_e)) + 1, > ^ > /workspace/src/lib/msun/src/catrigl.c:316:11: error: = '__builtin_complex' operand not of real binary floating-point type > return (CMPLXL(logl(hypotl(x / m_e, y / m_e)) + 1, > ^ > /workspace/src/lib/msun/src/catrigl.c: In function 'catanhl': > /workspace/src/lib/msun/src/catrigl.c:390:11: error: 'SQRT_3_EPSILON' = undeclared (first use in this function) > if (ax < SQRT_3_EPSILON / 2 && ay < SQRT_3_EPSILON / 2) { > ^~~~~~~~~~~~~~ > /workspace/src/lib/msun/src/catrigl.c:396:9: error: 'm_ln2' undeclared = (first use in this function) > rx =3D (m_ln2 - logl(ay)) / 2; > ^~~~~ > *** [catrigl.o] Error code 1 Later below expand the failing and previoly good commands, one option per line. The summary of the distinction in content is a one line difference, the working example ( -r335773 )had the option: -isystem = /workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/include but the failing one did not. Working ( -r335773 ) is shown first. --- catrigl.o --- /usr/local/bin/x86_64-unknown-freebsd11.1-gcc -DCOMPAT_32BIT -march=3Di686 -mmmx -msse -msse2 -m32 -L/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/lib32 --sysroot=3D/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp -B/usr/local/x86_64-unknown-freebsd11.1/bin/ -B/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/lib32 -isystem = /workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/include -O2 -pipe -I/workspace/src/lib/msun/x86 -I/workspace/src/lib/msun/ld80 -I/workspace/src/lib/msun/i387 -I/workspace/src/lib/msun/src -I/workspace/src/lib/libc/include -I/workspace/src/lib/libc/i386 -g -MD -MF.depend.catrigl.o -MTcatrigl.o -std=3Dgnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wno-pointer-sign -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 -Wno-unknown-pragmas -c /workspace/src/lib/msun/src/catrigl.c -o catrigl.o --- catrigl.o --- /usr/local/bin/x86_64-unknown-freebsd11.1-gcc -DCOMPAT_32BIT -march=3Di686 -mmmx -msse -msse2 -m32 -L/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/lib32 --sysroot=3D/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp -B/usr/local/x86_64-unknown-freebsd11.1/bin/ -B/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/lib32 -O2 -pipe -I/workspace/src/lib/msun/x86 -I/workspace/src/lib/msun/ld80 -I/workspace/src/lib/msun/i387 -I/workspace/src/lib/msun/src -I/workspace/src/lib/libc/include=20 -I/workspace/src/lib/libc/i386 -g -MD -MF.depend.catrigl.o -MTcatrigl.o -std=3Dgnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wno-pointer-sign -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 -Wno-unknown-pragmas -c /workspace/src/lib/msun/src/catrigl.c -o catrigl.o =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 Jun 29 02:47: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 3FD48102FE9A for ; Fri, 29 Jun 2018 02:47:25 +0000 (UTC) (envelope-from kiri@kx.openedu.org) Received: from kx.openedu.org (flets-sg1027.kamome.or.jp [202.216.24.27]) (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 34261788E8; Fri, 29 Jun 2018 02:47:23 +0000 (UTC) (envelope-from kiri@kx.openedu.org) Received: from kx.openedu.org (kx.openedu.org [202.216.24.27]) by kx.openedu.org (8.14.5/8.14.5) with ESMTP id w5T2lDd6065483; Fri, 29 Jun 2018 11:47:13 +0900 (JST) (envelope-from kiri@kx.openedu.org) Message-Id: <201806290247.w5T2lDd6065483@kx.openedu.org> Date: Fri, 29 Jun 2018 11:47:13 +0900 From: KIRIYAMA Kazuhiko To: Toomas Soome Cc: KIRIYAMA Kazuhiko , Allan Jude , freebsd-current@freebsd.org Subject: Re: ZFS: I/O error - blocks larger than 16777216 are not supported In-Reply-To: <63C1AB52-1A4B-430E-9D88-6406107785BA@me.com> References: <201806210136.w5L1a5Nv074194@kx.openedu.org> <21493592-4eb2-59c5-1b0d-e1d08217a96b@freebsd.org> <201806210600.w5L60mYn079435@kx.openedu.org> <1CDD5AFE-F115-406C-AB92-9DC58B57E1D5@me.com> <201806260208.w5Q28Una093666@kx.openedu.org> <63C1AB52-1A4B-430E-9D88-6406107785BA@me.com> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.6 MULE XEmacs/21.4 (patch 22) (Instant Classic) (amd64--freebsd) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 29 Jun 2018 02:47:25 -0000 At Tue, 26 Jun 2018 09:48:10 +0300, Toomas Soome wrote: > > > > > On 26 Jun 2018, at 05:08, KIRIYAMA Kazuhiko wrote: > > > > At Thu, 21 Jun 2018 10:48:28 +0300, > > Toomas Soome wrote: > >> > >> > >> > >>> On 21 Jun 2018, at 09:00, KIRIYAMA Kazuhiko wrote: > >>> > >>> At Wed, 20 Jun 2018 23:34:48 -0400, > >>> Allan Jude wrote: > >>>> > >>>> On 2018-06-20 21:36, KIRIYAMA Kazuhiko wrote: > >>>>> Hi all, > >>>>> > >>>>> I've been reported ZFS boot disable problem [1], and found > >>>>> that this issue occers form RAID configuration [2]. So I > >>>>> rebuit with RAID5 and re-installed 12.0-CURRENT > >>>>> (r333982). But failed to boot with: > >>>>> > >>>>> ZFS: i/o error - all block copies unavailable > >>>>> ZFS: can't read MOS of pool zroot > >>>>> gptzfsboot: failed to mount default pool zroot > >>>>> > >>>>> FreeBSD/x86 boot > >>>>> ZFS: I/O error - blocks larger than 16777216 are not supported > >>>>> ZFS: can't find dataset u > >>>>> Default: zroot/<0x0>: > >>>>> > >>>>> In this case, the reason is "blocks larger than 16777216 are > >>>>> not supported" and I guess this means datasets that have > >>>>> recordsize greater than 8GB is NOT supported by the > >>>>> FreeBSD boot loader(zpool-features(7)). Is that true ? > >>>>> > >>>>> My zpool featues are as follows: > >>>>> > >>>>> # kldload zfs > >>>>> # zpool import > >>>>> pool: zroot > >>>>> id: 13407092850382881815 > >>>>> state: ONLINE > >>>>> status: The pool was last accessed by another system. > >>>>> action: The pool can be imported using its name or numeric identifier and > >>>>> the '-f' flag. > >>>>> see: http://illumos.org/msg/ZFS-8000-EY > >>>>> config: > >>>>> > >>>>> zroot ONLINE > >>>>> mfid0p3 ONLINE > >>>>> # zpool import -fR /mnt zroot > >>>>> # zpool list > >>>>> NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT > >>>>> zroot 19.9T 129G 19.7T - 0% 0% 1.00x ONLINE /mnt > >>>>> # zpool get all zroot > >>>>> NAME PROPERTY VALUE SOURCE > >>>>> zroot size 19.9T - > >>>>> zroot capacity 0% - > >>>>> zroot altroot /mnt local > >>>>> zroot health ONLINE - > >>>>> zroot guid 13407092850382881815 default > >>>>> zroot version - default > >>>>> zroot bootfs zroot/ROOT/default local > >>>>> zroot delegation on default > >>>>> zroot autoreplace off default > >>>>> zroot cachefile none local > >>>>> zroot failmode wait default > >>>>> zroot listsnapshots off default > >>>>> zroot autoexpand off default > >>>>> zroot dedupditto 0 default > >>>>> zroot dedupratio 1.00x - > >>>>> zroot free 19.7T - > >>>>> zroot allocated 129G - > >>>>> zroot readonly off - > >>>>> zroot comment - default > >>>>> zroot expandsize - - > >>>>> zroot freeing 0 default > >>>>> zroot fragmentation 0% - > >>>>> zroot leaked 0 default > >>>>> zroot feature@async_destroy enabled local > >>>>> zroot feature@empty_bpobj active local > >>>>> zroot feature@lz4_compress active local > >>>>> zroot feature@multi_vdev_crash_dump enabled local > >>>>> zroot feature@spacemap_histogram active local > >>>>> zroot feature@enabled_txg active local > >>>>> zroot feature@hole_birth active local > >>>>> zroot feature@extensible_dataset enabled local > >>>>> zroot feature@embedded_data active local > >>>>> zroot feature@bookmarks enabled local > >>>>> zroot feature@filesystem_limits enabled local > >>>>> zroot feature@large_blocks enabled local > >>>>> zroot feature@sha512 enabled local > >>>>> zroot feature@skein enabled local > >>>>> zroot unsupported@com.delphix:device_removal inactive local > >>>>> zroot unsupported@com.delphix:obsolete_counts inactive local > >>>>> zroot unsupported@com.delphix:zpool_checkpoint inactive local > >>>>> # > >>>>> > >>>>> Regards > >>>>> > >>>>> [1] https://lists.freebsd.org/pipermail/freebsd-current/2018-March/068886.html > >>>>> [2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=151910 > >>>>> > >>>>> --- > >>>>> KIRIYAMA Kazuhiko > >>>>> _______________________________________________ > >>>>> 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" > >>>>> > >>>> > >>>> I am guessing it means something is corrupt, as 16MB is the maximum size > >>>> of a record in ZFS. Also, the 'large_blocks' feature is 'enabled', not > >>>> 'active', so this suggest you do not have any records larger than 128kb > >>>> on your pool. > >>> > >>> As I mentioned above, [2] says ZFS on RAID disks have any > >>> serious bugs except for mirror. Anyway I gave up to use ZFS > >>> on RAID{5,6}* until Bug 151910 [2] fixed. > >>> > >> > >> if you boot from usb stick (or cd), press esc at boot loader menu and enter lsdev -v. what sector and disk sizes are reported? > > > > OK lsdev -v > > disk devices: > > disk0: BIOS drive C (31588352 X 512) > > disk0p1: FreeBSD boot 512KB > > disk0p2: FreeBSD UFS 13GB > > disk0p3: FreeBSD swap 771MB > > disk1: BIOS drive D (4294967295 X 512) > > disk0p1: FreeBSD boot 512KB > > disk0p2: FreeBSD swap 128GB > > disk0p3: FreeBSD ZFS 19TB > > OK > > > > Does this means whole disk size that I can use is > > 2TB (4294967295 X 512) ? > > > Yes, or to be exact, that is the disk size reported by the INT13; and as below you do get the same value from UEFI, the limit seems to be set by the RAID controller itself. In this case it means that the best way to address the issue is to create one smaller lun for boot disk (zroot pool) and larger for data. Or of course you can have separate FreeBSD ZFS partition for zroot, just make sure it will fit inside the first 2TB. > > Of course there may be option for RAID firmware update, or configuration settings for lun, or use JBOD mode (if supported by the card). JBOD would be the best because in the current setup, the pool is vulnerable against silent data corruption (checksum errors) and has no way to recover (this is the reason why RAID setups are not preferred with zfs). My RAID card is AVAGO MegaRAID (SAS-MFI BIOS Version 6.36.00.0) and find it to be enable JBOD-mode. So I change RAID-mode to JBOD-mode and make each disk to JBOD. Then reboot and checked at loader prompt 'lsdev -v', all disk is recognized as single device 'mfidx' (x=0,2,..,11). Anyway I re-installed as ZFS RAIDZ-3 with UEFI boot. Result is fine !!! Each disk was recoginized up to 2TB as a ZFS file system and built a zpool (zroot) as raidz3 from those disks: OK lsdev -v PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/VenHw(CF31FAC5-C24E-11D2-85F3-00A0C93EC93B,80) disk0: 3907029168 X 512 blocks disk0p1: EFI 200MB disk0p2: FreeBSD swap 8192MBB disk0p3: FreeBSD ZFS 1854GBB PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/VenHw(CF31FAC5-C24E-11D2-85F3-00A0C93EC93B,81) disk1: 3907029168 X 512 blocks disk1p1: EFI 200MB disk1p2: FreeBSD swap 8192MBB disk1p3: FreeBSD ZFS 1854GBB PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/VenHw(CF31FAC5-C24E-11D2-85F3-00A0C93EC93B,82) disk1: 3907029168 X 512 blocks disk1p1: EFI 200MB disk1p2: FreeBSD swap 8192MBB disk1p3: FreeBSD ZFS 1854GBB : PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/VenHw(CF31FAC5-C24E-11D2-85F3-00A0C93EC93B,8B) disk11: 3907029168 X 512 blocks disk11p1: EFI 200MB disk11p2: FreeBSD swap 8192MBB disk11p3: FreeBSD ZFS 1854GBB net devices: zfs devices: pool: zroot bootfs: zroot/ROOT/default config: NAME STATE zroot ONLINE raidz3 ONLINE mfid0p3 ONLINE mfid1p3 ONLINE mfid2p3 ONLINE mfid3p3 ONLINE mfid4p3 ONLINE mfid5p3 ONLINE mfid6p3 ONLINE mfid7p3 ONLINE mfid8p3 ONLINE mfid9p3 ONLINE mfid10p3 ONLINE mfid11p3 ONLINE OK Built-up ZFS file system on FreeBSD 12.0-CURRENT (r335317) is as follwos: # gpart show mfid0 => 40 3907029088 mfid0 GPT (1.8T) 40 409600 1 efi (200M) 409640 2008 - free - (1.0M) 411648 16777216 2 freebsd-swap (8.0G) 17188864 3889840128 3 freebsd-zfs (1.8T) 3907028992 136 - free - (68K) # zpool status pool: zroot state: ONLINE scan: none requested config: NAME STATE READ WRITE CKSUM zroot ONLINE 0 0 0 raidz3-0 ONLINE 0 0 0 mfid0p3 ONLINE 0 0 0 mfid1p3 ONLINE 0 0 0 mfid2p3 ONLINE 0 0 0 mfid3p3 ONLINE 0 0 0 mfid4p3 ONLINE 0 0 0 mfid5p3 ONLINE 0 0 0 mfid6p3 ONLINE 0 0 0 mfid7p3 ONLINE 0 0 0 mfid8p3 ONLINE 0 0 0 mfid9p3 ONLINE 0 0 0 mfid10p3 ONLINE 0 0 0 mfid11p3 ONLINE 0 0 0 errors: No known data errors # zpool list NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT zroot 21.6T 2.55G 21.6T - - 0% 0% 1.00x ONLINE - # zpool get all zroot NAME PROPERTY VALUE SOURCE zroot size 21.6T - zroot capacity 0% - zroot altroot - default zroot health ONLINE - zroot guid 2002381236893751526 default zroot version - default zroot bootfs zroot/ROOT/default local zroot delegation on default zroot autoreplace off default zroot cachefile - default zroot failmode wait default zroot listsnapshots off default zroot autoexpand off default zroot dedupditto 0 default zroot dedupratio 1.00x - zroot free 21.6T - zroot allocated 2.55G - zroot readonly off - zroot comment - default zroot expandsize - - zroot freeing 0 default zroot fragmentation 0% - zroot leaked 0 default zroot bootsize - default zroot checkpoint - - zroot feature@async_destroy enabled local zroot feature@empty_bpobj active local zroot feature@lz4_compress active local zroot feature@multi_vdev_crash_dump enabled local zroot feature@spacemap_histogram active local zroot feature@enabled_txg active local zroot feature@hole_birth active local zroot feature@extensible_dataset enabled local zroot feature@embedded_data active local zroot feature@bookmarks enabled local zroot feature@filesystem_limits enabled local zroot feature@large_blocks enabled local zroot feature@sha512 enabled local zroot feature@skein enabled local zroot feature@device_removal enabled local zroot feature@obsolete_counts enabled local zroot feature@zpool_checkpoint enabled local # uname -a FreeBSD vm.openedu.org 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r335317: Mon Jun 18 16:21:17 UTC 2018 root@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 # df -h Filesystem Size Used Avail Capacity Mounted on zroot/ROOT/default 15T 191M 15T 0% / devfs 1.0K 1.0K 0B 100% /dev zroot/.dake 15T 256K 15T 0% /.dake zroot/ds 15T 279K 15T 0% /ds zroot/ds/backup 15T 256K 15T 0% /ds/backup zroot/ds/distfiles 15T 256K 15T 0% /ds/distfiles zroot/ds/obj 15T 256K 15T 0% /ds/obj zroot/ds/packages 15T 256K 15T 0% /ds/packages zroot/ds/ports 15T 256K 15T 0% /ds/ports zroot/ds/src 15T 256K 15T 0% /ds/src zroot/tmp 15T 302K 15T 0% /tmp zroot/usr 15T 1.6G 15T 0% /usr zroot/usr/home 15T 372K 15T 0% /usr/home zroot/usr/local 15T 256K 15T 0% /usr/local zroot/var 15T 395K 15T 0% /var zroot/var/audit 15T 256K 15T 0% /var/audit zroot/var/crash 15T 256K 15T 0% /var/crash zroot/var/db 15T 9.2M 15T 0% /var/db zroot/var/empty 15T 256K 15T 0% /var/empty zroot/var/log 15T 337K 15T 0% /var/log zroot/var/mail 15T 256K 15T 0% /var/mail zroot/var/ports 15T 256K 15T 0% /var/ports zroot/var/run 15T 442K 15T 0% /var/run zroot/var/tmp 15T 256K 15T 0% /var/tmp zroot/vm 15T 256K 15T 0% /vm zroot 15T 256K 15T 0% /zroot # Thankx for benignant advice ! > > rgds, > toomas > > > > > > >> > >> the issue [2] is mix of ancient freebsd (v 8.1 is mentioned there), and RAID luns with 512B sector size and 15TB!!! total size - are you really sure your BIOS can actually address 15TB lun (with 512B sector size)? Note that the problem with large disks can hide itself till you have pool filled up enough till the essential files will be stored above the limit~ meaning that you may have ~perfectly working~ setup till at some point in time, after next update, it is suddenly not working any more. > >> > > > > I see why I could use for a while. > > > >> Note that for boot loader we have only INT13h for BIOS version, and it really is limited. The UEFI version is using EFI_BLOCK_IO API, which usually can handle large sectors and disk sizes better. > > > > I re-installed the machine with UEFI boot: > > > > # gpart show mfid0 > > => 40 42965401520 mfid0 GPT (20T) > > 40 409600 1 efi (200M) > > 409640 2008 - free - (1.0M) > > 411648 268435456 2 freebsd-swap (128G) > > 268847104 42696552448 3 freebsd-zfs (20T) > > 42965399552 2008 - free - (1.0M) > > > > # uname -a > > FreeBSD vm.openedu.org 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r335317: Mon Jun 18 16:21:17 UTC 2018 root@releng3.nyi.freebsd.org :/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 > > # zpool get all zroot > > NAME PROPERTY VALUE SOURCE > > zroot size 19.9T - > > zroot capacity 0% - > > zroot altroot - default > > zroot health ONLINE - > > zroot guid 11079446129259852576 default > > zroot version - default > > zroot bootfs zroot/ROOT/default local > > zroot delegation on default > > zroot autoreplace off default > > zroot cachefile - default > > zroot failmode wait default > > zroot listsnapshots off default > > zroot autoexpand off default > > zroot dedupditto 0 default > > zroot dedupratio 1.00x - > > zroot free 19.9T - > > zroot allocated 1.67G - > > zroot readonly off - > > zroot comment - default > > zroot expandsize - - > > zroot freeing 0 default > > zroot fragmentation 0% - > > zroot leaked 0 default > > zroot bootsize - default > > zroot checkpoint - - > > zroot feature@async_destroy enabled local > > zroot feature@empty_bpobj active local > > zroot feature@lz4_compress active local > > zroot feature@multi_vdev_crash_dump enabled local > > zroot feature@spacemap_histogram active local > > zroot feature@enabled_txg active local > > zroot feature@hole_birth active local > > zroot feature@extensible_dataset enabled local > > zroot feature@embedded_data active local > > zroot feature@bookmarks enabled local > > zroot feature@filesystem_limits enabled local > > zroot feature@large_blocks enabled local > > zroot feature@sha512 enabled local > > zroot feature@skein enabled local > > zroot feature@device_removal enabled local > > zroot feature@obsolete_counts enabled local > > zroot feature@zpool_checkpoint enabled local > > # > > > > and checked 'lsdev -v' at loader prompt: > > > > OK lsdev -v > > PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/VenHw(CF31FAC5-C24E-11D2-85F3-00A0C93EC93B,80) > > disk0: 4294967295 X 512 blocks > > disk0p1: EFI 200MB > > disk0p2: FreeBSD swap 128GB > > disk0p2: FreeBSD ZFS 19TB > > net devices: > > zfs devices: > > pool: zroot > > bootfs: zroot/ROOT/default > > config: > > > > NAME STATE > > zroot ONLINE > > mfid0p3 ONLINE > > OK > > > > but disk size (4294967295 X 512) still not changed or this > > means 4294967295 X 512 X 512 bytes ? > > > >> > >> 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 " > > > > Regards > > > > --- > > KIRIYAMA Kazuhiko > > _______________________________________________ > 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" > --- KIRIYAMA Kazuhiko From owner-freebsd-current@freebsd.org Fri Jun 29 02:54: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 419651030106 for ; Fri, 29 Jun 2018 02:54:22 +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 B4D2079124 for ; Fri, 29 Jun 2018 02:54:21 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 3X3SCZsVM1lhRsZIVQEvFtkj3So1MradXbAFqYwNcrOJ_cCWRQz2TzuJgMBmHXk CBJvCDqqtONsAuWZURtq30qAZYz4MqyI2IdZm9UQ4fLHBxWEHISMHQ_QzHhtDrbYyMOJmF7Lo_h5 TVDbh6WBu_k.9c56R.CYnw58wiAU6GFywaZbYDmvMQh5WAomf1JR5kZ8utZq4JouEYBBzggZJN5W _AOX4nCaw9lyr3fbcgxHRuwmUdSqKsQSS5dG6DcwtFiJUTygWC39ZySmKTfXhPWdx44gL9QWoPJ3 fOtkbtYlcJEL39Qyz1lXp5w.6tCr3BnughvOBZZvTGYNEklorUT9.Wclo_JSC5ck9nf1MStZY5iY 8TFFMQyfuGsJlSmPS.M4Yrxn5pmXq7Vup8l9lpRTerF.sXBFVlz80QtK_QEIW0WlB1iha0HHs_pM cz8LGWoyCtxUjvtaRACjbFDQf6juwfPjXD6xoqVlMeAaqlk3jqDrlQ_WbNFiBXNAJBTDffnHYJJi Nhmo0Gj3c1mGsRlArom5xTpk7aMOGJWg5lkL_HVq4qGDQA8_udjwUnY5K_JbR_SMADYYyufe.I5C SV8RKhANxrp1ROLA93clxG5UDKlwRZc.iP2jhXFvT_FBLeMVQA9yNpiUbMYveJFaz0sqnIDHSkDB 11EzfNKWFPxrDql8tG43VmoZJO4gCzKZnfYq_Jt1_ivfhc8qb63PjL1sLtn3C1gmOsChmwAU4d2B SsAZJDp8c92TgRjHme4U9Fw06UzT0JWxba.hOAaLf5k3KWoOOXAXSKJK6OqEgxZy1lQeyfiSvlIB o2XHvQX9NDAIWLRuB4JlTzjNDE8VuYcK8HbXlfckQ0iHDnjixsjnjeXUFILgrp0Y0z1mifE5w2Gg Wiw20KGDnymMDwvlKKsXua9Qh17CLUOxwFYVQsfo0gHC0BHqy0dQFpPSFfnmPNOG2O96lqcKfC_Q Gagyr1eIrROmf_ZhiE_ZcszdGAeSUoHnkeq09_sg6 Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Fri, 29 Jun 2018 02:54:20 +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 570b07594d9674c1461421b894b43d2c; Fri, 29 Jun 2018 02:54:19 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build) From: Mark Millard In-Reply-To: Date: Thu, 28 Jun 2018 19:54:17 -0700 Cc: svn-src-head@freebsd.org, FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <7A845F2C-C994-4828-823D-33A97B7B6EB0@yahoo.com> References: <00D1127A-1F0E-4E0E-B86C-1C5AA5B2E085@yahoo.com> To: John Baldwin , Bryan Drewery X-Mailer: Apple Mail (2.3445.8.2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 29 Jun 2018 02:54:22 -0000 On 2018-Jun-28, at 6:04 PM, Mark Millard wrote: > On 2018-Jun-28, at 5:39 PM, Mark Millard wrote: >=20 >> [ ci.free.bsd.org jumped from -r335773 (built) to -r335784 (failed) >> for FreeBSD-head-amd64-gcc. It looked to me like the most likely >> breaking-change was the following but I've not tried personal >> builds to confirm. >> ] >>=20 >> It looks to me that: >>=20 >>> Author: jhb >>> Date: Thu Jun 28 21:26:14 2018 >>> New Revision: 335782 >>> URL:=20 >>> https://svnweb.freebsd.org/changeset/base/335782 >>>=20 >>>=20 >>> Log: >>> Remove the various build flag hacks for GCC cross-compile. >>>=20 >>> The xtoolchain GCC packages have not required these flags since = ports >>> commits r465416 and r466701. The in-tree GCC 4.2.1 has also been = patched >>> in r335716 and r335717 to correctly honor --sysroot when looking for >>> includes and libraries. >>>=20 >>> Reviewed by: bdrewery >>> Sponsored by: DARPA / AFRL >>> Differential Revision:=09 >>> https://reviews.freebsd.org/D16055 >> . . . >>=20 >> broke ci.freebsd.org's FreeBSD-head-amd64-gcc build. >>=20 >> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6331/consoleText = shows: >>=20 >> --- catrigl.o --- >> /usr/local/bin/x86_64-unknown-freebsd11.1-gcc -DCOMPAT_32BIT = -march=3Di686 -mmmx -msse -msse2 -m32 = -L/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/lib32 = --sysroot=3D/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp = -B/usr/local/x86_64-unknown-freebsd11.1/bin/ = -B/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/lib32 -O2 = -pipe -I/workspace/src/lib/msun/x86 -I/workspace/src/lib/msun/ld80 = -I/workspace/src/lib/msun/i387 -I/workspace/src/lib/msun/src = -I/workspace/src/lib/libc/include -I/workspace/src/lib/libc/i386 -g = -MD -MF.depend.catrigl.o -MTcatrigl.o -std=3Dgnu99 = -fstack-protector-strong -Wsystem-headers -Werror -Wno-pointer-sign = -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 -Wno-unknown-pragmas -c = /workspace/src/lib/msun/src/catrigl.c -o catrigl.o >> /workspace/src/lib/msun/src/catrigl.c:90:2: error: #error = "Unsupported long double format" >> #error "Unsupported long double format" >> ^~~~~ >> /workspace/src/lib/msun/src/catrigl.c: In function 'casinhl': >> /workspace/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; >> ^~~~~ >> /workspace/src/lib/msun/src/catrigl.c:190:35: note: each undeclared = identifier is reported only once for each function it appears in >> /workspace/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) >> ^~~~~~~~~~~~~~ >> /workspace/src/lib/msun/src/catrigl.c: In function 'cacosl': >> /workspace/src/lib/msun/src/catrigl.c:250:20: error: 'm_ln2' = undeclared (first use in this function) >> ry =3D creall(w) + m_ln2; >> ^~~~~ >> /workspace/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 /workspace/src/lib/msun/src/catrigl.c:45:0: >> /workspace/src/lib/msun/src/catrigl.c: In function = 'clog_for_large_values': >> /workspace/src/lib/msun/src/catrigl.c:316:34: error: 'm_e' undeclared = (first use in this function) >> return (CMPLXL(logl(hypotl(x / m_e, y / m_e)) + 1, >> ^ >> /workspace/src/lib/msun/src/catrigl.c:316:11: error: = '__builtin_complex' operand not of real binary floating-point type >> return (CMPLXL(logl(hypotl(x / m_e, y / m_e)) + 1, >> ^ >> /workspace/src/lib/msun/src/catrigl.c: In function 'catanhl': >> /workspace/src/lib/msun/src/catrigl.c:390:11: error: 'SQRT_3_EPSILON' = undeclared (first use in this function) >> if (ax < SQRT_3_EPSILON / 2 && ay < SQRT_3_EPSILON / 2) { >> ^~~~~~~~~~~~~~ >> /workspace/src/lib/msun/src/catrigl.c:396:9: error: 'm_ln2' = undeclared (first use in this function) >> rx =3D (m_ln2 - logl(ay)) / 2; >> ^~~~~ >> *** [catrigl.o] Error code 1 >=20 > Later below expand the failing and previoly good commands, one > option per line. The summary of the distinction in content is > a one line difference, the working example ( -r335773 )had the > option: >=20 > -isystem = /workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/include >=20 > but the failing one did not. Working ( -r335773 ) is shown first. >=20 > --- catrigl.o --- > /usr/local/bin/x86_64-unknown-freebsd11.1-gcc > -DCOMPAT_32BIT > -march=3Di686 > -mmmx > -msse > -msse2 > -m32 > -L/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/lib32 > --sysroot=3D/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp > -B/usr/local/x86_64-unknown-freebsd11.1/bin/ > -B/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/lib32 > -isystem = /workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/include > -O2 > -pipe > -I/workspace/src/lib/msun/x86 > -I/workspace/src/lib/msun/ld80 > -I/workspace/src/lib/msun/i387 > -I/workspace/src/lib/msun/src > -I/workspace/src/lib/libc/include > -I/workspace/src/lib/libc/i386 > -g > -MD > -MF.depend.catrigl.o > -MTcatrigl.o > -std=3Dgnu99 > -fstack-protector-strong > -Wsystem-headers > -Werror > -Wno-pointer-sign > -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 > -Wno-unknown-pragmas > -c /workspace/src/lib/msun/src/catrigl.c > -o catrigl.o >=20 >=20 > --- catrigl.o --- > /usr/local/bin/x86_64-unknown-freebsd11.1-gcc > -DCOMPAT_32BIT > -march=3Di686 > -mmmx > -msse > -msse2 > -m32 > -L/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/lib32 > --sysroot=3D/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp > -B/usr/local/x86_64-unknown-freebsd11.1/bin/ > -B/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/lib32 > -O2 > -pipe > -I/workspace/src/lib/msun/x86 > -I/workspace/src/lib/msun/ld80 > -I/workspace/src/lib/msun/i387 > -I/workspace/src/lib/msun/src > -I/workspace/src/lib/libc/include=20 > -I/workspace/src/lib/libc/i386 > -g > -MD > -MF.depend.catrigl.o > -MTcatrigl.o > -std=3Dgnu99 > -fstack-protector-strong > -Wsystem-headers > -Werror > -Wno-pointer-sign > -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 > -Wno-unknown-pragmas > -c /workspace/src/lib/msun/src/catrigl.c > -o catrigl.o For the report: > The xtoolchain GCC packages have not required these flags since ports > commits r465416 and r466701 Looking at = https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6331/consoleText there is: > Updating FreeBSD repository catalogue... > FreeBSD repository is up to date. > All repositories are up to date. > The following 6 package(s) will be affected (of 0 checked): >=20 > New packages to be INSTALLED: > amd64-xtoolchain-gcc: 0.4_1 > amd64-gcc: 6.4.0 > mpfr: 4.0.1 > gmp: 6.1.2 > mpc: 1.1.0_1 > amd64-binutils: 2.30_3,1 and amd64-gcc being 6.4.0 (via powerpc64-gcc) is from -r466834 (via looking up in https://svnweb.freebsd.org/ports/head/devel/ ). This indicates that -r465416 and -r466701 did not cause: --sysroot=3D/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp to lead to include files being looked up in: /workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/include Thus there appears to still be a need for: -isystem = /workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/include unless more is done to the devel/*-gcc to make them look in that additional place automatically (based on --sysroot). =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 Jun 29 06:22: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 9326F1032AD0 for ; Fri, 29 Jun 2018 06:22:12 +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 119CC7DF14; Fri, 29 Jun 2018 06:22:12 +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 <0PB200G00MTKOJ00@st13p35im-asmtp002.me.com>; Fri, 29 Jun 2018 06:21:55 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=04042017; t=1530253315; bh=7Q5TgLc+g36IaJQY1vtezrcym/ZE7tyyD9II1WsxyDQ=; h=From:Message-id:Content-type:MIME-version:Subject:Date:To; b=XF6BvOQx1ZyJI7WbcisYD+LxstWZ8+58UOECjotaaFatjVasTlkYXvNDTLuA5v+Ui Tr2d2k8ERKQC9sBp9eYN6yYPaD9AQFWzLviuyqZmhhHgHBCId4elfHIc9v9iY8dFw4 gCQdZQy2ho8mosl70bmUN41Y/Xb/CziWdRmGoYqumGVlY3kCS+susGY8AObbwe7P+K 1FnWxMM7M9ly3nQsWm9joN1R5wXaLsZS73wUjt78YlN4fgAXUqPMBmBq1A3nrekEDQ dG9r+9QiXcxUi5jSGW7tIHL68ympIkqwt6cRPt27txwnPY+ifrbD6qlp7kXpJ2rfZl MhDYB+R1rA8CA== 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 <0PB200FPSN0AXM20@st13p35im-asmtp002.me.com>; Fri, 29 Jun 2018 06:21:54 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-06-29_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-1806290071 From: Toomas Soome Message-id: <21645D05-EE5F-4BC3-B9F2-6AE4E851BCFE@me.com> MIME-version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: ZFS: I/O error - blocks larger than 16777216 are not supported Date: Fri, 29 Jun 2018 09:21:45 +0300 In-reply-to: <201806290247.w5T2lDd6065483@kx.openedu.org> Cc: Allan Jude , freebsd-current@freebsd.org To: KIRIYAMA Kazuhiko References: <201806210136.w5L1a5Nv074194@kx.openedu.org> <21493592-4eb2-59c5-1b0d-e1d08217a96b@freebsd.org> <201806210600.w5L60mYn079435@kx.openedu.org> <1CDD5AFE-F115-406C-AB92-9DC58B57E1D5@me.com> <201806260208.w5Q28Una093666@kx.openedu.org> <63C1AB52-1A4B-430E-9D88-6406107785BA@me.com> <201806290247.w5T2lDd6065483@kx.openedu.org> X-Mailer: Apple Mail (2.3445.8.2) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 29 Jun 2018 06:22:13 -0000 > On 29 Jun 2018, at 05:47, KIRIYAMA Kazuhiko = wrote: >=20 > At Tue, 26 Jun 2018 09:48:10 +0300, > Toomas Soome wrote: >>=20 >>=20 >>=20 >>> On 26 Jun 2018, at 05:08, KIRIYAMA Kazuhiko = wrote: >>>=20 >>> At Thu, 21 Jun 2018 10:48:28 +0300, >>> Toomas Soome wrote: >>>>=20 >>>>=20 >>>>=20 >>>>> On 21 Jun 2018, at 09:00, KIRIYAMA Kazuhiko = wrote: >>>>>=20 >>>>> At Wed, 20 Jun 2018 23:34:48 -0400, >>>>> Allan Jude wrote: >>>>>>=20 >>>>>> On 2018-06-20 21:36, KIRIYAMA Kazuhiko wrote: >>>>>>> Hi all, >>>>>>>=20 >>>>>>> I've been reported ZFS boot disable problem [1], and found >>>>>>> that this issue occers form RAID configuration [2]. So I >>>>>>> rebuit with RAID5 and re-installed 12.0-CURRENT >>>>>>> (r333982). But failed to boot with: >>>>>>>=20 >>>>>>> ZFS: i/o error - all block copies unavailable >>>>>>> ZFS: can't read MOS of pool zroot >>>>>>> gptzfsboot: failed to mount default pool zroot >>>>>>>=20 >>>>>>> FreeBSD/x86 boot >>>>>>> ZFS: I/O error - blocks larger than 16777216 are not supported >>>>>>> ZFS: can't find dataset u >>>>>>> Default: zroot/<0x0>: >>>>>>>=20 >>>>>>> In this case, the reason is "blocks larger than 16777216 are >>>>>>> not supported" and I guess this means datasets that have >>>>>>> recordsize greater than 8GB is NOT supported by the >>>>>>> FreeBSD boot loader(zpool-features(7)). Is that true ? >>>>>>>=20 >>>>>>> My zpool featues are as follows: >>>>>>>=20 >>>>>>> # kldload zfs >>>>>>> # zpool import=20 >>>>>>> pool: zroot >>>>>>> id: 13407092850382881815 >>>>>>> state: ONLINE >>>>>>> status: The pool was last accessed by another system. >>>>>>> action: The pool can be imported using its name or numeric = identifier and >>>>>>> the '-f' flag. >>>>>>> see: http://illumos.org/msg/ZFS-8000-EY >>>>>>> config: >>>>>>>=20 >>>>>>> zroot ONLINE >>>>>>> mfid0p3 ONLINE >>>>>>> # zpool import -fR /mnt zroot >>>>>>> # zpool list >>>>>>> NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP = HEALTH ALTROOT >>>>>>> zroot 19.9T 129G 19.7T - 0% 0% 1.00x = ONLINE /mnt >>>>>>> # zpool get all zroot >>>>>>> NAME PROPERTY VALUE = SOURCE >>>>>>> zroot size 19.9T = - >>>>>>> zroot capacity 0% = - >>>>>>> zroot altroot /mnt = local >>>>>>> zroot health ONLINE = - >>>>>>> zroot guid = 13407092850382881815 default >>>>>>> zroot version - = default >>>>>>> zroot bootfs = zroot/ROOT/default local >>>>>>> zroot delegation on = default >>>>>>> zroot autoreplace off = default >>>>>>> zroot cachefile none = local >>>>>>> zroot failmode wait = default >>>>>>> zroot listsnapshots off = default >>>>>>> zroot autoexpand off = default >>>>>>> zroot dedupditto 0 = default >>>>>>> zroot dedupratio 1.00x = - >>>>>>> zroot free 19.7T = - >>>>>>> zroot allocated 129G = - >>>>>>> zroot readonly off = - >>>>>>> zroot comment - = default >>>>>>> zroot expandsize - = - >>>>>>> zroot freeing 0 = default >>>>>>> zroot fragmentation 0% = - >>>>>>> zroot leaked 0 = default >>>>>>> zroot feature@async_destroy enabled = local >>>>>>> zroot feature@empty_bpobj active = local >>>>>>> zroot feature@lz4_compress active = local >>>>>>> zroot feature@multi_vdev_crash_dump enabled = local >>>>>>> zroot feature@spacemap_histogram active = local >>>>>>> zroot feature@enabled_txg active = local >>>>>>> zroot feature@hole_birth active = local >>>>>>> zroot feature@extensible_dataset enabled = local >>>>>>> zroot feature@embedded_data active = local >>>>>>> zroot feature@bookmarks enabled = local >>>>>>> zroot feature@filesystem_limits enabled = local >>>>>>> zroot feature@large_blocks enabled = local >>>>>>> zroot feature@sha512 enabled = local >>>>>>> zroot feature@skein enabled = local >>>>>>> zroot unsupported@com.delphix:device_removal inactive = local >>>>>>> zroot unsupported@com.delphix:obsolete_counts inactive = local >>>>>>> zroot unsupported@com.delphix:zpool_checkpoint inactive = local >>>>>>> #=20 >>>>>>>=20 >>>>>>> Regards >>>>>>>=20 >>>>>>> [1] = https://lists.freebsd.org/pipermail/freebsd-current/2018-March/068886.html= >>>>>>> [2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D151910 >>>>>>>=20 >>>>>>> --- >>>>>>> KIRIYAMA Kazuhiko >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>> I am guessing it means something is corrupt, as 16MB is the = maximum size >>>>>> of a record in ZFS. Also, the 'large_blocks' feature is = 'enabled', not >>>>>> 'active', so this suggest you do not have any records larger than = 128kb >>>>>> on your pool. >>>>>=20 >>>>> As I mentioned above, [2] says ZFS on RAID disks have any >>>>> serious bugs except for mirror. Anyway I gave up to use ZFS >>>>> on RAID{5,6}* until Bug 151910 [2] fixed. >>>>>=20 >>>>=20 >>>> if you boot from usb stick (or cd), press esc at boot loader menu = and enter lsdev -v. what sector and disk sizes are reported? >>>=20 >>> OK lsdev -v >>> disk devices: >>> disk0: BIOS drive C (31588352 X 512) >>> disk0p1: FreeBSD boot 512KB >>> disk0p2: FreeBSD UFS 13GB >>> disk0p3: FreeBSD swap 771MB >>> disk1: BIOS drive D (4294967295 X 512) >>> disk0p1: FreeBSD boot 512KB >>> disk0p2: FreeBSD swap 128GB >>> disk0p3: FreeBSD ZFS 19TB >>> OK >>>=20 >>> Does this means whole disk size that I can use is >>> 2TB (4294967295 X 512) ?=20 >>=20 >>=20 >> Yes, or to be exact, that is the disk size reported by the INT13; and = as below you do get the same value from UEFI, the limit seems to be set = by the RAID controller itself. In this case it means that the best way = to address the issue is to create one smaller lun for boot disk (zroot = pool) and larger for data. Or of course you can have separate FreeBSD = ZFS partition for zroot, just make sure it will fit inside the first = 2TB. >>=20 >> Of course there may be option for RAID firmware update, or = configuration settings for lun, or use JBOD mode (if supported by the = card). JBOD would be the best because in the current setup, the pool is = vulnerable against silent data corruption (checksum errors) and has no = way to recover (this is the reason why RAID setups are not preferred = with zfs). >=20 > My RAID card is AVAGO MegaRAID (SAS-MFI BIOS Version > 6.36.00.0) and find it to be enable JBOD-mode. So I change > RAID-mode to JBOD-mode and make each disk to JBOD. Then > reboot and checked at loader prompt 'lsdev -v', all disk is > recognized as single device 'mfidx' (x=3D0,2,..,11). Anyway I > re-installed as ZFS RAIDZ-3 with UEFI boot. Result is fine !!! >=20 > Each disk was recoginized up to 2TB as a ZFS file system and > built a zpool (zroot) as raidz3 from those disks: >=20 > OK lsdev -v > = PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/VenHw(CF31FAC5-C24E-11D2-85F3-00A0C= 93EC93B,80) > disk0: 3907029168 X 512 blocks > disk0p1: EFI 200MB > disk0p2: FreeBSD swap 8192MBB > disk0p3: FreeBSD ZFS 1854GBB > = PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/VenHw(CF31FAC5-C24E-11D2-85F3-00A0C= 93EC93B,81) > disk1: 3907029168 X 512 blocks > disk1p1: EFI 200MB > disk1p2: FreeBSD swap 8192MBB > disk1p3: FreeBSD ZFS 1854GBB > = PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/VenHw(CF31FAC5-C24E-11D2-85F3-00A0C= 93EC93B,82) > disk1: 3907029168 X 512 blocks > disk1p1: EFI 200MB > disk1p2: FreeBSD swap 8192MBB > disk1p3: FreeBSD ZFS 1854GBB > : > = PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/VenHw(CF31FAC5-C24E-11D2-85F3-00A0C= 93EC93B,8B) > disk11: 3907029168 X 512 blocks > disk11p1: EFI 200MB > disk11p2: FreeBSD swap 8192MBB > disk11p3: FreeBSD ZFS 1854GBB > net devices: > zfs devices: > pool: zroot > bootfs: zroot/ROOT/default > config: >=20 > NAME STATE > zroot ONLINE > raidz3 ONLINE > mfid0p3 ONLINE > mfid1p3 ONLINE > mfid2p3 ONLINE > mfid3p3 ONLINE > mfid4p3 ONLINE > mfid5p3 ONLINE > mfid6p3 ONLINE > mfid7p3 ONLINE > mfid8p3 ONLINE > mfid9p3 ONLINE > mfid10p3 ONLINE > mfid11p3 ONLINE > OK >=20 > Built-up ZFS file system on FreeBSD 12.0-CURRENT (r335317) > is as follwos: >=20 > # gpart show mfid0 > =3D> 40 3907029088 mfid0 GPT (1.8T) > 40 409600 1 efi (200M) > 409640 2008 - free - (1.0M) > 411648 16777216 2 freebsd-swap (8.0G) > 17188864 3889840128 3 freebsd-zfs (1.8T) > 3907028992 136 - free - (68K) >=20 > # zpool status > pool: zroot > state: ONLINE > scan: none requested > config: >=20 > NAME STATE READ WRITE CKSUM > zroot ONLINE 0 0 0 > raidz3-0 ONLINE 0 0 0 > mfid0p3 ONLINE 0 0 0 > mfid1p3 ONLINE 0 0 0 > mfid2p3 ONLINE 0 0 0 > mfid3p3 ONLINE 0 0 0 > mfid4p3 ONLINE 0 0 0 > mfid5p3 ONLINE 0 0 0 > mfid6p3 ONLINE 0 0 0 > mfid7p3 ONLINE 0 0 0 > mfid8p3 ONLINE 0 0 0 > mfid9p3 ONLINE 0 0 0 > mfid10p3 ONLINE 0 0 0 > mfid11p3 ONLINE 0 0 0 >=20 > errors: No known data errors > # zpool list > NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP = HEALTH ALTROOT > zroot 21.6T 2.55G 21.6T - - 0% 0% 1.00x = ONLINE - > # zpool get all zroot > NAME PROPERTY VALUE = SOURCE > zroot size 21.6T - > zroot capacity 0% - > zroot altroot - = default > zroot health ONLINE - > zroot guid 2002381236893751526 = default > zroot version - = default > zroot bootfs zroot/ROOT/default = local > zroot delegation on = default > zroot autoreplace off = default > zroot cachefile - = default > zroot failmode wait = default > zroot listsnapshots off = default > zroot autoexpand off = default > zroot dedupditto 0 = default > zroot dedupratio 1.00x - > zroot free 21.6T - > zroot allocated 2.55G - > zroot readonly off - > zroot comment - = default > zroot expandsize - - > zroot freeing 0 = default > zroot fragmentation 0% - > zroot leaked 0 = default > zroot bootsize - = default > zroot checkpoint - - > zroot feature@async_destroy enabled = local > zroot feature@empty_bpobj active = local > zroot feature@lz4_compress active = local > zroot feature@multi_vdev_crash_dump enabled = local > zroot feature@spacemap_histogram active = local > zroot feature@enabled_txg active = local > zroot feature@hole_birth active = local > zroot feature@extensible_dataset enabled = local > zroot feature@embedded_data active = local > zroot feature@bookmarks enabled = local > zroot feature@filesystem_limits enabled = local > zroot feature@large_blocks enabled = local > zroot feature@sha512 enabled = local > zroot feature@skein enabled = local > zroot feature@device_removal enabled = local > zroot feature@obsolete_counts enabled = local > zroot feature@zpool_checkpoint enabled = local > # uname -a > FreeBSD vm.openedu.org 12.0-CURRENT FreeBSD = 12.0-CURRENT #0 r335317: Mon Jun 18 16:21:17 UTC 2018 = root@releng3.nyi.freebsd.org = :/usr/obj/usr/src/amd64.amd64/sys/GEN= ERIC amd64 > # df -h > Filesystem Size Used Avail Capacity Mounted on > zroot/ROOT/default 15T 191M 15T 0% / > devfs 1.0K 1.0K 0B 100% /dev > zroot/.dake 15T 256K 15T 0% /.dake > zroot/ds 15T 279K 15T 0% /ds > zroot/ds/backup 15T 256K 15T 0% /ds/backup > zroot/ds/distfiles 15T 256K 15T 0% /ds/distfiles > zroot/ds/obj 15T 256K 15T 0% /ds/obj > zroot/ds/packages 15T 256K 15T 0% /ds/packages > zroot/ds/ports 15T 256K 15T 0% /ds/ports > zroot/ds/src 15T 256K 15T 0% /ds/src > zroot/tmp 15T 302K 15T 0% /tmp > zroot/usr 15T 1.6G 15T 0% /usr > zroot/usr/home 15T 372K 15T 0% /usr/home > zroot/usr/local 15T 256K 15T 0% /usr/local > zroot/var 15T 395K 15T 0% /var > zroot/var/audit 15T 256K 15T 0% /var/audit > zroot/var/crash 15T 256K 15T 0% /var/crash > zroot/var/db 15T 9.2M 15T 0% /var/db > zroot/var/empty 15T 256K 15T 0% /var/empty > zroot/var/log 15T 337K 15T 0% /var/log > zroot/var/mail 15T 256K 15T 0% /var/mail > zroot/var/ports 15T 256K 15T 0% /var/ports > zroot/var/run 15T 442K 15T 0% /var/run > zroot/var/tmp 15T 256K 15T 0% /var/tmp > zroot/vm 15T 256K 15T 0% /vm > zroot 15T 256K 15T 0% /zroot > #=20 >=20 > Thankx for benignant advice ! >=20 Glad to hear! There is still an issue - you got the error about too = large block, meaning that somehow the read result is not validated or = something else is going on - it is good the dnode_read() has this check, = but I think, we should not have had got that far at all=E2=80=A6=20 rgds, toomas From owner-freebsd-current@freebsd.org Fri Jun 29 11:34: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 E9267103812F for ; Fri, 29 Jun 2018 11:34:06 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) 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 89B888726C for ; Fri, 29 Jun 2018 11:34:06 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: by mailman.ysv.freebsd.org (Postfix) id 46754103812E; Fri, 29 Jun 2018 11:34:06 +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 33FE5103812D for ; Fri, 29 Jun 2018 11:34:06 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from mailin.dlr.de (mailin.dlr.de [194.94.201.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailin.dlr.de", Issuer "DFN-Verein Global Issuing CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A6EB18726B for ; Fri, 29 Jun 2018 11:34:05 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) X-IronPort-AV: E=Sophos;i="5.51,285,1526335200"; d="scan'208";a="4591240" From: To: Subject: RiscV tinderbox fails Thread-Topic: RiscV tinderbox fails Thread-Index: AdQPnHbvv4fSWqqnSTKlCTty6E58Zg== Date: Fri, 29 Jun 2018 11:33:57 +0000 Deferred-Delivery: Fri, 29 Jun 2018 11:33:00 +0000 Message-ID: <611243783F62AF48AFB07BC25FA4B10629917799@DLDEFFMIMP01EXC.intra.dlr.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 29 Jun 2018 11:34:07 -0000 Hi, is it supposed not to fail? I get: /usr/obj/usr/src/riscv.riscv64sf/tmp/usr/lib/libgcc.a(comparedf2.o): In fun= ction `__gedf2': /usr/src/contrib/compiler-rt/lib/builtins/comparedf2.c:101: multiple defini= tion of `__gedf2' /usr/obj/usr/src/riscv.riscv64sf/tmp/usr/lib/libc.a(gedf2.o):/usr/src/lib/l= ibc/s oftfloat/gedf2.c:18: first defined here /usr/obj/usr/src/riscv.riscv64sf/tmp/usr/lib/libgcc.a(comparedf2.o): In fun= ction `__eqdf2': /usr/src/contrib/compiler-rt/lib/builtins/comparedf2.c:127: multiple defini= tion of `__eqdf2' /usr/obj/usr/src/riscv.riscv64sf/tmp/usr/lib/libc.a(eqdf2.o):/usr/src/lib/l= ibc/s oftfloat/eqdf2.c:18: first defined here /usr/obj/usr/src/riscv.riscv64sf/tmp/usr/lib/libgcc.a(comparedf2.o): In fun= ction `__ltdf2': /usr/src/contrib/compiler-rt/lib/builtins/comparedf2.c:127: multiple defini= tion of `__ltdf2' /usr/obj/usr/src/riscv.riscv64sf/tmp/usr/lib/libc.a(ltdf2.o):/usr/src/lib/l= ibc/s oftfloat/ltdf2.c:18: first defined here /usr/obj/usr/src/riscv.riscv64sf/tmp/usr/lib/libgcc.a(comparedf2.o): In fun= ction `__nedf2': /usr/src/contrib/compiler-rt/lib/builtins/comparedf2.c:127: multiple defini= tion of `__nedf2' /usr/obj/usr/src/riscv.riscv64sf/tmp/usr/lib/libc.a(nedf2.o):/usr/src/lib/l= ibc/s oftfloat/nedf2.c:18: first defined here /usr/obj/usr/src/riscv.riscv64sf/tmp/usr/lib/libgcc.a(comparedf2.o): In fun= ction `__gtdf2': /usr/src/contrib/compiler-rt/lib/builtins/comparedf2.c:142: multiple defini= tion of `__gtdf2' /usr/obj/usr/src/riscv.riscv64sf/tmp/usr/lib/libc.a(gtdf2.o):/usr/src/lib/l= ibc/s oftfloat/gtdf2.c:18: first defined here collect2: error: ld returned 1 exit status *** [nologin.full] Error code 1 make[6]: stopped in /usr/src/usr.sbin/nologin 1 error Regards, harti From owner-freebsd-current@freebsd.org Fri Jun 29 14:50: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 22C98EF9902 for ; Fri, 29 Jun 2018 14:50:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-13.consmr.mail.bf2.yahoo.com (sonic311-13.consmr.mail.bf2.yahoo.com [74.6.131.123]) (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 B84D18DD46 for ; Fri, 29 Jun 2018 14:50:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: oTC3__MVM1muTGrwH74cKbTMhxRbb3arkeNFiVPG7XUNs65pnnQHZ.KHLadpI.m rZ1Ty6NT.RMdlOCu3cW22_V.go0S3IDZOH2bVnUbDJLHOSC4NzhYGozr2nfFBkNTr5rLRTbAQCOJ sPh57jqp4M819SKCup3bFCpEEgqV_MKmE40QbbbQRZncR7CFSQkhDH1XtXnEmt9cN.dGJIIhrtTE DbXWjhcQXt9CtYqWc827y2tR4zhiRssNfAA9j4XQ3Z6C0lU0Khp_mUAJlJz3exFL_CTuf8cQAZc. eUPHvqxCcqamZvNmDdklVby9fFYrktRwNCubrZgUr_t34ucZJ0.7LgluFKGMHHeI0xQTXpVJgmaB n0.0HvrUNxJtg337uSGuxuvtYUheJb0Ln2gIipas20eu.uZJhvrrx3GHLhUjYZsDPBLlexvmLck5 ZpRm89h2igu2wz46QKAgoYbFikDl3CeUpsfv_kz7tlvQrkxxJXyDIr7nhph32yz88x9K8JqHt2Ux 1AKIBX.81VTXPpUqMKg8VUeP.MkBJC3d4MXqkQeqkspKgGF03ETqUgKs6wV.tYusZkqL96t3zvQJ NnG7tE2QvW3UrYUi3VdoxHjdqd0HAQFSS_Kll9AE6amtzIcEXDwpHWHRoBGHYXLFiMzFk0f7A6tq enQTW0bYQrJXDry5BmDoLLRpILHRI3byd4gBHNianiHoqImiqDIbyDUxbiHuy1pFjUOgda8GW.f3 OfPywJ9WHuT7tc1SYJQeVjnIj7uZ2bMnAHH9SwtBWfL_cTbtBxVt7JFwaS1VWyUQ5T3SNJw.eaL1 EKAsNVer4ESEOFMOQ.h9fTKqvv6i1LiYjEQVh2Naf1it5d6EAFEsih7bOv8oLXxpj5_98mVAeI78 UX6yGOBUZPFJj3rMINcVxsFfvtggLQPgqnTSfWdsJ_jncE7JpoIpaJOrx6Djm8m6g7U.5a8ZcO76 gOagEpPrFq.y5z5q5d8OmbWEOCYW28giWyKGRdynS3oEr1Bo6vZDusvJSeQCzxBMb.PmbYA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.bf2.yahoo.com with HTTP; Fri, 29 Jun 2018 14:50:44 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp405.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 7e235119bc02ca8724c4031421d0783e; Fri, 29 Jun 2018 14:50:40 +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.4 \(3445.8.2\)) Subject: head -r335795 broke the builds for ci.freebsd.org 's FreeBSD-head-{amd64,i386,powerpc,risc64,sparc64}-build Message-Id: Date: Fri, 29 Jun 2018 07:50:38 -0700 To: ae@FreeBSD.org, FreeBSD Current , svn-src-head@freebsd.org X-Mailer: Apple Mail (2.3445.8.2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 29 Jun 2018 14:50:46 -0000 clang example: ( https://ci.freebsd.org/job/FreeBSD-head-amd64-build/9257/consoleText ) --- key_debug.o --- /usr/src/sys/netipsec/key_debug.c:89:1: error: no previous prototype for = function 'kdebug_sadb_type' [-Werror,-Wmissing-prototypes] kdebug_sadb_type(uint8_t type) ^ /usr/src/sys/netipsec/key_debug.c:124:1: error: no previous prototype = for function 'kdebug_sadb_exttype' [-Werror,-Wmissing-prototypes] kdebug_sadb_exttype(uint16_t type) ^ 2 errors generated. *** [key_debug.o] Error code 1 gcc 4.2.1 example: ( https://ci.freebsd.org/job/FreeBSD-head-sparc64-build/8445/consoleText = ) --- key_debug.o --- cc1: warnings being treated as errors /usr/src/sys/netipsec/key_debug.c:90: warning: no previous prototype for = 'kdebug_sadb_type' [-Wmissing-prototypes] /usr/src/sys/netipsec/key_debug.c:125: warning: no previous prototype = for 'kdebug_sadb_exttype' [-Wmissing-prototypes] *** [key_debug.o] Error code 1 Side note: All I get for the lists that I normally look at is: Error 503 Backend fetch failed Backend status: Backend fetch failed Transaction ID: . . . =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 Jun 29 15:56:42 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 440F6EFC359; Fri, 29 Jun 2018 15:56:42 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B3F2F70310; Fri, 29 Jun 2018 15:56:41 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from [192.168.0.6] (67-0-234-146.albq.qwest.net [67.0.234.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 7BAEF1AF636; Fri, 29 Jun 2018 08:01:50 +0000 (UTC) Subject: Re: head -r335795 broke the builds for ci.freebsd.org 's FreeBSD-head-{amd64,i386,powerpc,risc64,sparc64}-build To: Mark Millard , FreeBSD Current , svn-src-head@freebsd.org References: From: Sean Bruno Openpgp: preference=signencrypt Autocrypt: addr=sbruno@freebsd.org; prefer-encrypt=mutual; keydata= xsBNBFk+0UEBCADaf4bgxxKvMOhRV5NPoGWRCCGm49d6+1VFNlQ77WsY/+Zvf95TPULdRlnG w648KfxWt7+O3kdKhdRwnqlXWC7zA2Qt0dRE1yIqOGJ4jp4INvp/bcxWzgr0aoKOjrlnfxRV bh+s0rzdZt6TsNL3cVYxkC8oezjaUkHdW4mFJU249U1QJogkF8g0FeKNfEcjEkwJNX6lQJH+ EzCWT0NCk6J+Xyo+zOOljxPp1OUfdvZi3ulkU/qTZstGVWxFVsP8xQklV/y3AFcbIYx6iGJ4 5L7WuB0IWhO7Z4yHENr8wFaNYwpod9i4egX2BugbrM8pOfhN2/qqdeG1L5LMtXw3yyAhABEB AAHNN1NlYW4gQnJ1bm8gKEZyZWVCU0QgRGV2ZWxvcGVyIEtleSkgPHNicnVub0BmcmVlYnNk Lm9yZz7CwJQEEwEKAD4WIQToxOn4gDUE4eP0ujS95PX+ibX8tgUCWT7RQQIbAwUJBaOagAUL CQgHAwUVCgkICwUWAwIBAAIeAQIXgAAKCRC95PX+ibX8ttKTCACFKzRc56EBAlVotq02EjZP SfX+unlk6AuPBzShxqRxeK+bGYVCigrYd1M8nnskv0dEiZ5iYeND9HIxbpEyopqgpVTibA7w gBXaZ7SOEhNX1wXwg14JrralfSmPFMYni+sWegPMX/zwfAsn1z4mG1Nn44Xqo3o7CfpkMPy6 M5Bow2IDzIhEYISLR+urxs74/aHU35PLtBSDtu18914SEMDdva27MARN8mbeCDbuJVfGCPWy YHuy2t+9u2Zn5Dd+t3sBXLM9gpeaMm+4x6TNPpESygbVdh4tDdjVZ9DK/bWFg0kMgfZoaq6J l0jNsQXrZV3bzYNFbVw04pFcvA2GIJ7xzsBNBFk+0UEBCADIXBmQOaKMHGbc9vwjhV4Oj5aZ DdhNedn12FVeTdOXJvuTOusgxS29lla0RenHGDsgD08UiFpasBXWq/E+BhQ19d+iRbLLR17O KKc1ZGefoVbLARLXD68J5j4XAyK+6k2KqBLlqzAEpHTzsksM9naARkVXiEVcrt6ciw0FSm8n kuK3gDKKe93XfzfP+TQdbvvzJc7Fa+appLbXz61TM1aikaQlda8bWubDegwXbuoJdB34xU1m yjr/N4o+raL0x7QrzdH+wwgrTTo+H4S2c1972Skt5K5tbxLowfHicRl23V8itVQr3sBtlX4+ 66q+Apm7+R36bUS/k+G45Sp6iPpxABEBAAHCwHwEGAEKACYWIQToxOn4gDUE4eP0ujS95PX+ ibX8tgUCWT7RQQIbDAUJBaOagAAKCRC95PX+ibX8trrIB/9Pljqt/JGamD9tx4dOVmxSyFg9 z2xzgklTLuDgS73MM120mM7ao9AQUeWiSle/H0UCK7xPOzC/aeUC4oygDQKAfkkNbCNTo3+A qDjBRA8qx0e9a/QjDL+RFgD4L5kLT4tToY8T8HaBp8h03LBfk510IaI8oL/Jg7vpM3PDtJMW tUi2H+yNFmL3NfM2oBToWKLFsoP54f/eeeImrNnrlLjLHPzqS+/9apgYqX2Jwiv3tHBc4FTO GuY8VvF7BpixJs8Pc2RUuCfSyodrp1YG1kRGlXAH0cqwwr0Zmk4+7dZvtVQMCl6kS6q1+84q JwtItxS2eXSEA4NO0sQ3BXUywANh Message-ID: <07054dd3-7d1f-88a8-f489-bfe9663b2a5f@freebsd.org> Date: Fri, 29 Jun 2018 09:56:37 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="jbcO3VRmIBXfDmKHyWMwogIzzknOImJcY" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 29 Jun 2018 15:56:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jbcO3VRmIBXfDmKHyWMwogIzzknOImJcY Content-Type: multipart/mixed; boundary="esTg2uO22avk07yig6GZkJcFf3WhPDmVD"; protected-headers="v1" From: Sean Bruno To: Mark Millard , FreeBSD Current , svn-src-head@freebsd.org Message-ID: <07054dd3-7d1f-88a8-f489-bfe9663b2a5f@freebsd.org> Subject: Re: head -r335795 broke the builds for ci.freebsd.org 's FreeBSD-head-{amd64,i386,powerpc,risc64,sparc64}-build References: In-Reply-To: --esTg2uO22avk07yig6GZkJcFf3WhPDmVD Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 06/29/18 08:50, Mark Millard wrote: > Side note: >=20 > All I get for the lists that I normally look at is: >=20 > Error 503 Backend fetch failed >=20 > Backend status: Backend fetch failed >=20 > Transaction ID: . . . I think I fixed that about an hour ago. Try again. sean --esTg2uO22avk07yig6GZkJcFf3WhPDmVD-- --jbcO3VRmIBXfDmKHyWMwogIzzknOImJcY Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEE6MTp+IA1BOHj9Lo0veT1/om1/LYFAls2VrVfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEU4 QzRFOUY4ODAzNTA0RTFFM0Y0QkEzNEJERTRGNUZFODlCNUZDQjYACgkQveT1/om1 /LbQBQgA0NvZAE/KGbGobi+qidzamxZ/NwYA5Y1QGN+tK+wg5+v/xOKnWwqIkDox gbplGnU9esfC8tfwlyzu3o50cr7i/VI6xbaDZkGG/cLrPjyANgTSSnV72RwurWAl ESRVdcnWJ+XwKVWdRqb4QGhfqk+BYFsfYOOlgMvJjUFJrSiN9yjPGrW5hdzUwbQw /glCBVECbCKv9YCcjU36oo83Ef3Y8xwADsr/p8hpIb6nbdWbiKsVO23bbYMVGKL1 8WXcXQ6uAEaA35XM/yjkVzzM9XKKNX6XnAoRi6IrlsD7LydMDLZXapVcasZUhkM+ kwIquYdwA4Ta52T6Rm5y5dPxBYRDuQ== =DMTW -----END PGP SIGNATURE----- --jbcO3VRmIBXfDmKHyWMwogIzzknOImJcY-- From owner-freebsd-current@freebsd.org Fri Jun 29 17:38: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 30882F719C5; Fri, 29 Jun 2018 17:38:08 +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 C153A73E65; Fri, 29 Jun 2018 17:38:07 +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 BFBE910AFD2; Fri, 29 Jun 2018 13:38:05 -0400 (EDT) Subject: Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build) To: Mark Millard , Bryan Drewery References: <00D1127A-1F0E-4E0E-B86C-1C5AA5B2E085@yahoo.com> <7A845F2C-C994-4828-823D-33A97B7B6EB0@yahoo.com> Cc: svn-src-head@freebsd.org, FreeBSD Current From: John Baldwin Message-ID: <72081b02-cf23-82ec-32df-7f5793c35f57@FreeBSD.org> Date: Fri, 29 Jun 2018 10:38:03 -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: <7A845F2C-C994-4828-823D-33A97B7B6EB0@yahoo.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: base64 X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Fri, 29 Jun 2018 13:38:06 -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.26 Precedence: 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, 29 Jun 2018 17:38:08 -0000 T24gNi8yOC8xOCA3OjU0IFBNLCBNYXJrIE1pbGxhcmQgd3JvdGU6DQo+IE9uIDIwMTgtSnVu LTI4LCBhdCA2OjA0IFBNLCBNYXJrIE1pbGxhcmQgPG1hcmtsbWkgYXQgeWFob28uY29tPiB3 cm90ZToNCj4gDQo+PiBPbiAyMDE4LUp1bi0yOCwgYXQgNTozOSBQTSwgTWFyayBNaWxsYXJk IDxtYXJrbG1pIGF0IHlhaG9vLmNvbT4gd3JvdGU6DQo+Pg0KPj4+IFsgY2kuZnJlZS5ic2Qu b3JnIGp1bXBlZCBmcm9tIC1yMzM1NzczIChidWlsdCkgdG8gLXIzMzU3ODQgKGZhaWxlZCkN Cj4+PiBmb3IgRnJlZUJTRC1oZWFkLWFtZDY0LWdjYy4gSXQgbG9va2VkIHRvIG1lIGxpa2Ug dGhlIG1vc3QgbGlrZWx5DQo+Pj4gYnJlYWtpbmctY2hhbmdlIHdhcyB0aGUgZm9sbG93aW5n IGJ1dCBJJ3ZlIG5vdCB0cmllZCBwZXJzb25hbA0KPj4+IGJ1aWxkcyB0byBjb25maXJtLg0K Pj4+IF0NCj4+Pg0KPj4+IEl0IGxvb2tzIHRvIG1lIHRoYXQ6DQo+Pj4NCj4+Pj4gQXV0aG9y OiBqaGINCj4+Pj4gRGF0ZTogVGh1IEp1biAyOCAyMToyNjoxNCAyMDE4DQo+Pj4+IE5ldyBS ZXZpc2lvbjogMzM1NzgyDQo+Pj4+IFVSTDogDQo+Pj4+IGh0dHBzOi8vc3Zud2ViLmZyZWVi c2Qub3JnL2NoYW5nZXNldC9iYXNlLzMzNTc4Mg0KPj4+Pg0KPj4+Pg0KPj4+PiBMb2c6DQo+ Pj4+IFJlbW92ZSB0aGUgdmFyaW91cyBidWlsZCBmbGFnIGhhY2tzIGZvciBHQ0MgY3Jvc3Mt Y29tcGlsZS4NCj4+Pj4NCj4+Pj4gVGhlIHh0b29sY2hhaW4gR0NDIHBhY2thZ2VzIGhhdmUg bm90IHJlcXVpcmVkIHRoZXNlIGZsYWdzIHNpbmNlIHBvcnRzDQo+Pj4+IGNvbW1pdHMgcjQ2 NTQxNiBhbmQgcjQ2NjcwMS4gIFRoZSBpbi10cmVlIEdDQyA0LjIuMSBoYXMgYWxzbyBiZWVu IHBhdGNoZWQNCj4+Pj4gaW4gcjMzNTcxNiBhbmQgcjMzNTcxNyB0byBjb3JyZWN0bHkgaG9u b3IgLS1zeXNyb290IHdoZW4gbG9va2luZyBmb3INCj4+Pj4gaW5jbHVkZXMgYW5kIGxpYnJh cmllcy4NCj4+Pj4NCj4+Pj4gUmV2aWV3ZWQgYnk6CWJkcmV3ZXJ5DQo+Pj4+IFNwb25zb3Jl ZCBieToJREFSUEEgLyBBRlJMDQo+Pj4+IERpZmZlcmVudGlhbCBSZXZpc2lvbjoJDQo+Pj4+ IGh0dHBzOi8vcmV2aWV3cy5mcmVlYnNkLm9yZy9EMTYwNTUNCj4+PiAuIC4gLg0KPj4+DQo+ Pj4gYnJva2UgY2kuZnJlZWJzZC5vcmcncyBGcmVlQlNELWhlYWQtYW1kNjQtZ2NjIGJ1aWxk Lg0KPj4+DQo+Pj4gaHR0cHM6Ly9jaS5mcmVlYnNkLm9yZy9qb2IvRnJlZUJTRC1oZWFkLWFt ZDY0LWdjYy82MzMxL2NvbnNvbGVUZXh0IHNob3dzOg0KPj4+DQo+Pj4gLS0tIGNhdHJpZ2wu byAtLS0NCj4+PiAvdXNyL2xvY2FsL2Jpbi94ODZfNjQtdW5rbm93bi1mcmVlYnNkMTEuMS1n Y2MgLURDT01QQVRfMzJCSVQgLW1hcmNoPWk2ODYgLW1tbXggLW1zc2UgLW1zc2UyIC1tMzIg IC1ML3dvcmtzcGFjZS9vYmovd29ya3NwYWNlL3NyYy9hbWQ2NC5hbWQ2NC9vYmotbGliMzIv dG1wL3Vzci9saWIzMiAgLS1zeXNyb290PS93b3Jrc3BhY2Uvb2JqL3dvcmtzcGFjZS9zcmMv YW1kNjQuYW1kNjQvb2JqLWxpYjMyL3RtcCAgLUIvdXNyL2xvY2FsL3g4Nl82NC11bmtub3du LWZyZWVic2QxMS4xL2Jpbi8gLUIvd29ya3NwYWNlL29iai93b3Jrc3BhY2Uvc3JjL2FtZDY0 LmFtZDY0L29iai1saWIzMi90bXAvdXNyL2xpYjMyICAtTzIgLXBpcGUgLUkvd29ya3NwYWNl L3NyYy9saWIvbXN1bi94ODYgLUkvd29ya3NwYWNlL3NyYy9saWIvbXN1bi9sZDgwIC1JL3dv cmtzcGFjZS9zcmMvbGliL21zdW4vaTM4NyAtSS93b3Jrc3BhY2Uvc3JjL2xpYi9tc3VuL3Ny YyAtSS93b3Jrc3BhY2Uvc3JjL2xpYi9saWJjL2luY2x1ZGUgIC1JL3dvcmtzcGFjZS9zcmMv bGliL2xpYmMvaTM4NiAgLWcgLU1EICAtTUYuZGVwZW5kLmNhdHJpZ2wubyAtTVRjYXRyaWds Lm8gLXN0ZD1nbnU5OSAtZnN0YWNrLXByb3RlY3Rvci1zdHJvbmcgLVdzeXN0ZW0taGVhZGVy cyAtV2Vycm9yIC1Xbm8tcG9pbnRlci1zaWduIC1Xbm8tZXJyb3I9YWRkcmVzcyAtV25vLWVy cm9yPWFycmF5LWJvdW5kcyAtV25vLWVycm9yPWF0dHJpYnV0ZXMgLVduby1lcnJvcj1ib29s LWNvbXBhcmUgLVduby1lcnJvcj1jYXN0LWFsaWduIC1Xbm8tZXJyb3I9Y2xvYmJlcmVkIC1X bm8tZXJyb3I9ZW51bS1jb21wYXJlIC1Xbm8tZXJyb3I9ZXh0cmEgLVduby1lcnJvcj1pbmxp bmUgLVduby1lcnJvcj1sb2dpY2FsLW5vdC1wYXJlbnRoZXNlcyAtV25vLWVycm9yPXN0cmlj dC1hbGlhc2luZyAtV25vLWVycm9yPXVuaW5pdGlhbGl6ZWQgLVduby1lcnJvcj11bnVzZWQt YnV0LXNldC12YXJpYWJsZSAtV25vLWVycm9yPXVudXNlZC1mdW5jdGlvbiAtV25vLWVycm9y PXVudXNlZC12YWx1ZSAtV25vLWVycm9yPW1pc2xlYWRpbmctaW5kZW50YXRpb24gLVduby1l cnJvcj1ub25udWxsLWNvbXBhcmUgLVduby1lcnJvcj1zaGlmdC1uZWdhdGl2ZS12YWx1ZSAt V25vLWVycm9yPXRhdXRvbG9naWNhbC1jb21wYXJlIC1Xbm8tZXJyb3I9dW51c2VkLWNvbnN0 LXZhcmlhYmxlIC1Xbm8tdW5rbm93bi1wcmFnbWFzICAgICAtYyAvd29ya3NwYWNlL3NyYy9s aWIvbXN1bi9zcmMvY2F0cmlnbC5jIC1vIGNhdHJpZ2wubw0KPj4+IC93b3Jrc3BhY2Uvc3Jj L2xpYi9tc3VuL3NyYy9jYXRyaWdsLmM6OTA6MjogZXJyb3I6ICNlcnJvciAiVW5zdXBwb3J0 ZWQgbG9uZyBkb3VibGUgZm9ybWF0Ig0KPj4+ICNlcnJvciAiVW5zdXBwb3J0ZWQgbG9uZyBk b3VibGUgZm9ybWF0Ig0KPj4+IF5+fn5+DQo+Pj4gL3dvcmtzcGFjZS9zcmMvbGliL21zdW4v c3JjL2NhdHJpZ2wuYzogSW4gZnVuY3Rpb24gJ2Nhc2luaGwnOg0KPj4+IC93b3Jrc3BhY2Uv c3JjL2xpYi9tc3VuL3NyYy9jYXRyaWdsLmM6MTkwOjM1OiBlcnJvcjogJ21fbG4yJyB1bmRl Y2xhcmVkIChmaXJzdCB1c2UgaW4gdGhpcyBmdW5jdGlvbikNCj4+PiAgIHcgPSBjbG9nX2Zv cl9sYXJnZV92YWx1ZXMoeikgKyBtX2xuMjsNCj4+PiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBefn5+fg0KPj4+IC93b3Jrc3BhY2Uvc3JjL2xpYi9tc3VuL3NyYy9jYXRy aWdsLmM6MTkwOjM1OiBub3RlOiBlYWNoIHVuZGVjbGFyZWQgaWRlbnRpZmllciBpcyByZXBv cnRlZCBvbmx5IG9uY2UgZm9yIGVhY2ggZnVuY3Rpb24gaXQgYXBwZWFycyBpbg0KPj4+IC93 b3Jrc3BhY2Uvc3JjL2xpYi9tc3VuL3NyYy9jYXRyaWdsLmM6MjAyOjExOiBlcnJvcjogJ1NR UlRfNl9FUFNJTE9OJyB1bmRlY2xhcmVkIChmaXJzdCB1c2UgaW4gdGhpcyBmdW5jdGlvbikN Cj4+PiBpZiAoYXggPCBTUVJUXzZfRVBTSUxPTiAvIDQgJiYgYXkgPCBTUVJUXzZfRVBTSUxP TiAvIDQpDQo+Pj4gICAgICAgICAgXn5+fn5+fn5+fn5+fn4NCj4+PiAvd29ya3NwYWNlL3Ny Yy9saWIvbXN1bi9zcmMvY2F0cmlnbC5jOiBJbiBmdW5jdGlvbiAnY2Fjb3NsJzoNCj4+PiAv d29ya3NwYWNlL3NyYy9saWIvbXN1bi9zcmMvY2F0cmlnbC5jOjI1MDoyMDogZXJyb3I6ICdt X2xuMicgdW5kZWNsYXJlZCAoZmlyc3QgdXNlIGluIHRoaXMgZnVuY3Rpb24pDQo+Pj4gIHJ5 ID0gY3JlYWxsKHcpICsgbV9sbjI7DQo+Pj4gICAgICAgICAgICAgICAgICAgXn5+fn4NCj4+ PiAvd29ya3NwYWNlL3NyYy9saWIvbXN1bi9zcmMvY2F0cmlnbC5jOjI2MToxMTogZXJyb3I6 ICdTUVJUXzZfRVBTSUxPTicgdW5kZWNsYXJlZCAoZmlyc3QgdXNlIGluIHRoaXMgZnVuY3Rp b24pDQo+Pj4gaWYgKGF4IDwgU1FSVF82X0VQU0lMT04gLyA0ICYmIGF5IDwgU1FSVF82X0VQ U0lMT04gLyA0KQ0KPj4+ICAgICAgICAgIF5+fn5+fn5+fn5+fn5+DQo+Pj4gSW4gZmlsZSBp bmNsdWRlZCBmcm9tIC93b3Jrc3BhY2Uvc3JjL2xpYi9tc3VuL3NyYy9jYXRyaWdsLmM6NDU6 MDoNCj4+PiAvd29ya3NwYWNlL3NyYy9saWIvbXN1bi9zcmMvY2F0cmlnbC5jOiBJbiBmdW5j dGlvbiAnY2xvZ19mb3JfbGFyZ2VfdmFsdWVzJzoNCj4+PiAvd29ya3NwYWNlL3NyYy9saWIv bXN1bi9zcmMvY2F0cmlnbC5jOjMxNjozNDogZXJyb3I6ICdtX2UnIHVuZGVjbGFyZWQgKGZp cnN0IHVzZSBpbiB0aGlzIGZ1bmN0aW9uKQ0KPj4+ICByZXR1cm4gKENNUExYTChsb2dsKGh5 cG90bCh4IC8gbV9lLCB5IC8gbV9lKSkgKyAxLA0KPj4+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgXg0KPj4+IC93b3Jrc3BhY2Uvc3JjL2xpYi9tc3VuL3NyYy9jYXRyaWds LmM6MzE2OjExOiBlcnJvcjogJ19fYnVpbHRpbl9jb21wbGV4JyBvcGVyYW5kIG5vdCBvZiBy ZWFsIGJpbmFyeSBmbG9hdGluZy1wb2ludCB0eXBlDQo+Pj4gIHJldHVybiAoQ01QTFhMKGxv Z2woaHlwb3RsKHggLyBtX2UsIHkgLyBtX2UpKSArIDEsDQo+Pj4gICAgICAgICAgXg0KPj4+ IC93b3Jrc3BhY2Uvc3JjL2xpYi9tc3VuL3NyYy9jYXRyaWdsLmM6IEluIGZ1bmN0aW9uICdj YXRhbmhsJzoNCj4+PiAvd29ya3NwYWNlL3NyYy9saWIvbXN1bi9zcmMvY2F0cmlnbC5jOjM5 MDoxMTogZXJyb3I6ICdTUVJUXzNfRVBTSUxPTicgdW5kZWNsYXJlZCAoZmlyc3QgdXNlIGlu IHRoaXMgZnVuY3Rpb24pDQo+Pj4gaWYgKGF4IDwgU1FSVF8zX0VQU0lMT04gLyAyICYmIGF5 IDwgU1FSVF8zX0VQU0lMT04gLyAyKSB7DQo+Pj4gICAgICAgICAgXn5+fn5+fn5+fn5+fn4N Cj4+PiAvd29ya3NwYWNlL3NyYy9saWIvbXN1bi9zcmMvY2F0cmlnbC5jOjM5Njo5OiBlcnJv cjogJ21fbG4yJyB1bmRlY2xhcmVkIChmaXJzdCB1c2UgaW4gdGhpcyBmdW5jdGlvbikNCj4+ PiAgcnggPSAobV9sbjIgLSBsb2dsKGF5KSkgLyAyOw0KPj4+ICAgICAgICBefn5+fg0KPj4+ ICoqKiBbY2F0cmlnbC5vXSBFcnJvciBjb2RlIDENCj4+DQo+PiBMYXRlciBiZWxvdyBleHBh bmQgdGhlIGZhaWxpbmcgYW5kIHByZXZpb2x5IGdvb2QgY29tbWFuZHMsIG9uZQ0KPj4gb3B0 aW9uIHBlciBsaW5lLiBUaGUgc3VtbWFyeSBvZiB0aGUgZGlzdGluY3Rpb24gaW4gY29udGVu dCBpcw0KPj4gYSBvbmUgbGluZSBkaWZmZXJlbmNlLCB0aGUgd29ya2luZyBleGFtcGxlICgg LXIzMzU3NzMgKWhhZCB0aGUNCj4+IG9wdGlvbjoNCj4+DQo+PiAtaXN5c3RlbSAvd29ya3Nw YWNlL29iai93b3Jrc3BhY2Uvc3JjL2FtZDY0LmFtZDY0L29iai1saWIzMi90bXAvdXNyL2lu Y2x1ZGUNCj4+DQo+PiBidXQgdGhlIGZhaWxpbmcgb25lIGRpZCBub3QuIFdvcmtpbmcgKCAt cjMzNTc3MyApIGlzIHNob3duIGZpcnN0Lg0KPj4NCj4+IC0tLSBjYXRyaWdsLm8gLS0tDQo+ PiAvdXNyL2xvY2FsL2Jpbi94ODZfNjQtdW5rbm93bi1mcmVlYnNkMTEuMS1nY2MNCj4+IC1E Q09NUEFUXzMyQklUDQo+PiAtbWFyY2g9aTY4Ng0KPj4gLW1tbXgNCj4+IC1tc3NlDQo+PiAt bXNzZTINCj4+IC1tMzINCj4+IC1ML3dvcmtzcGFjZS9vYmovd29ya3NwYWNlL3NyYy9hbWQ2 NC5hbWQ2NC9vYmotbGliMzIvdG1wL3Vzci9saWIzMg0KPj4gLS1zeXNyb290PS93b3Jrc3Bh Y2Uvb2JqL3dvcmtzcGFjZS9zcmMvYW1kNjQuYW1kNjQvb2JqLWxpYjMyL3RtcA0KPj4gLUIv dXNyL2xvY2FsL3g4Nl82NC11bmtub3duLWZyZWVic2QxMS4xL2Jpbi8NCj4+IC1CL3dvcmtz cGFjZS9vYmovd29ya3NwYWNlL3NyYy9hbWQ2NC5hbWQ2NC9vYmotbGliMzIvdG1wL3Vzci9s aWIzMg0KPj4gLWlzeXN0ZW0gL3dvcmtzcGFjZS9vYmovd29ya3NwYWNlL3NyYy9hbWQ2NC5h bWQ2NC9vYmotbGliMzIvdG1wL3Vzci9pbmNsdWRlDQo+PiAtTzINCj4+IC1waXBlDQo+PiAt SS93b3Jrc3BhY2Uvc3JjL2xpYi9tc3VuL3g4Ng0KPj4gLUkvd29ya3NwYWNlL3NyYy9saWIv bXN1bi9sZDgwDQo+PiAtSS93b3Jrc3BhY2Uvc3JjL2xpYi9tc3VuL2kzODcNCj4+IC1JL3dv cmtzcGFjZS9zcmMvbGliL21zdW4vc3JjDQo+PiAtSS93b3Jrc3BhY2Uvc3JjL2xpYi9saWJj L2luY2x1ZGUNCj4+IC1JL3dvcmtzcGFjZS9zcmMvbGliL2xpYmMvaTM4Ng0KPj4gLWcNCj4+ IC1NRA0KPj4gLU1GLmRlcGVuZC5jYXRyaWdsLm8NCj4+IC1NVGNhdHJpZ2wubw0KPj4gLXN0 ZD1nbnU5OQ0KPj4gLWZzdGFjay1wcm90ZWN0b3Itc3Ryb25nDQo+PiAtV3N5c3RlbS1oZWFk ZXJzDQo+PiAtV2Vycm9yDQo+PiAtV25vLXBvaW50ZXItc2lnbg0KPj4gLVduby1lcnJvcj1h ZGRyZXNzDQo+PiAtV25vLWVycm9yPWFycmF5LWJvdW5kcw0KPj4gLVduby1lcnJvcj1hdHRy aWJ1dGVzDQo+PiAtV25vLWVycm9yPWJvb2wtY29tcGFyZQ0KPj4gLVduby1lcnJvcj1jYXN0 LWFsaWduDQo+PiAtV25vLWVycm9yPWNsb2JiZXJlZA0KPj4gLVduby1lcnJvcj1lbnVtLWNv bXBhcmUNCj4+IC1Xbm8tZXJyb3I9ZXh0cmENCj4+IC1Xbm8tZXJyb3I9aW5saW5lDQo+PiAt V25vLWVycm9yPWxvZ2ljYWwtbm90LXBhcmVudGhlc2VzDQo+PiAtV25vLWVycm9yPXN0cmlj dC1hbGlhc2luZw0KPj4gLVduby1lcnJvcj11bmluaXRpYWxpemVkDQo+PiAtV25vLWVycm9y PXVudXNlZC1idXQtc2V0LXZhcmlhYmxlDQo+PiAtV25vLWVycm9yPXVudXNlZC1mdW5jdGlv bg0KPj4gLVduby1lcnJvcj11bnVzZWQtdmFsdWUNCj4+IC1Xbm8tZXJyb3I9bWlzbGVhZGlu Zy1pbmRlbnRhdGlvbg0KPj4gLVduby1lcnJvcj1ub25udWxsLWNvbXBhcmUNCj4+IC1Xbm8t ZXJyb3I9c2hpZnQtbmVnYXRpdmUtdmFsdWUNCj4+IC1Xbm8tZXJyb3I9dGF1dG9sb2dpY2Fs LWNvbXBhcmUNCj4+IC1Xbm8tZXJyb3I9dW51c2VkLWNvbnN0LXZhcmlhYmxlDQo+PiAtV25v LXVua25vd24tcHJhZ21hcw0KPj4gLWMgL3dvcmtzcGFjZS9zcmMvbGliL21zdW4vc3JjL2Nh dHJpZ2wuYw0KPj4gLW8gY2F0cmlnbC5vDQo+Pg0KPj4NCj4+IC0tLSBjYXRyaWdsLm8gLS0t DQo+PiAvdXNyL2xvY2FsL2Jpbi94ODZfNjQtdW5rbm93bi1mcmVlYnNkMTEuMS1nY2MNCj4+ IC1EQ09NUEFUXzMyQklUDQo+PiAtbWFyY2g9aTY4Ng0KPj4gLW1tbXgNCj4+IC1tc3NlDQo+ PiAtbXNzZTINCj4+IC1tMzINCj4+IC1ML3dvcmtzcGFjZS9vYmovd29ya3NwYWNlL3NyYy9h bWQ2NC5hbWQ2NC9vYmotbGliMzIvdG1wL3Vzci9saWIzMg0KPj4gLS1zeXNyb290PS93b3Jr c3BhY2Uvb2JqL3dvcmtzcGFjZS9zcmMvYW1kNjQuYW1kNjQvb2JqLWxpYjMyL3RtcA0KPj4g LUIvdXNyL2xvY2FsL3g4Nl82NC11bmtub3duLWZyZWVic2QxMS4xL2Jpbi8NCj4+IC1CL3dv cmtzcGFjZS9vYmovd29ya3NwYWNlL3NyYy9hbWQ2NC5hbWQ2NC9vYmotbGliMzIvdG1wL3Vz ci9saWIzMg0KPj4gLU8yDQo+PiAtcGlwZQ0KPj4gLUkvd29ya3NwYWNlL3NyYy9saWIvbXN1 bi94ODYNCj4+IC1JL3dvcmtzcGFjZS9zcmMvbGliL21zdW4vbGQ4MA0KPj4gLUkvd29ya3Nw YWNlL3NyYy9saWIvbXN1bi9pMzg3DQo+PiAtSS93b3Jrc3BhY2Uvc3JjL2xpYi9tc3VuL3Ny Yw0KPj4gLUkvd29ya3NwYWNlL3NyYy9saWIvbGliYy9pbmNsdWRlIA0KPj4gLUkvd29ya3Nw YWNlL3NyYy9saWIvbGliYy9pMzg2DQo+PiAtZw0KPj4gLU1EDQo+PiAtTUYuZGVwZW5kLmNh dHJpZ2wubw0KPj4gLU1UY2F0cmlnbC5vDQo+PiAtc3RkPWdudTk5DQo+PiAtZnN0YWNrLXBy b3RlY3Rvci1zdHJvbmcNCj4+IC1Xc3lzdGVtLWhlYWRlcnMNCj4+IC1XZXJyb3INCj4+IC1X bm8tcG9pbnRlci1zaWduDQo+PiAtV25vLWVycm9yPWFkZHJlc3MNCj4+IC1Xbm8tZXJyb3I9 YXJyYXktYm91bmRzDQo+PiAtV25vLWVycm9yPWF0dHJpYnV0ZXMNCj4+IC1Xbm8tZXJyb3I9 Ym9vbC1jb21wYXJlDQo+PiAtV25vLWVycm9yPWNhc3QtYWxpZ24NCj4+IC1Xbm8tZXJyb3I9 Y2xvYmJlcmVkDQo+PiAtV25vLWVycm9yPWVudW0tY29tcGFyZQ0KPj4gLVduby1lcnJvcj1l eHRyYQ0KPj4gLVduby1lcnJvcj1pbmxpbmUNCj4+IC1Xbm8tZXJyb3I9bG9naWNhbC1ub3Qt cGFyZW50aGVzZXMNCj4+IC1Xbm8tZXJyb3I9c3RyaWN0LWFsaWFzaW5nDQo+PiAtV25vLWVy cm9yPXVuaW5pdGlhbGl6ZWQNCj4+IC1Xbm8tZXJyb3I9dW51c2VkLWJ1dC1zZXQtdmFyaWFi bGUNCj4+IC1Xbm8tZXJyb3I9dW51c2VkLWZ1bmN0aW9uDQo+PiAtV25vLWVycm9yPXVudXNl ZC12YWx1ZQ0KPj4gLVduby1lcnJvcj1taXNsZWFkaW5nLWluZGVudGF0aW9uDQo+PiAtV25v LWVycm9yPW5vbm51bGwtY29tcGFyZQ0KPj4gLVduby1lcnJvcj1zaGlmdC1uZWdhdGl2ZS12 YWx1ZQ0KPj4gLVduby1lcnJvcj10YXV0b2xvZ2ljYWwtY29tcGFyZQ0KPj4gLVduby1lcnJv cj11bnVzZWQtY29uc3QtdmFyaWFibGUNCj4+IC1Xbm8tdW5rbm93bi1wcmFnbWFzDQo+PiAt YyAvd29ya3NwYWNlL3NyYy9saWIvbXN1bi9zcmMvY2F0cmlnbC5jDQo+PiAtbyBjYXRyaWds Lm8NCj4gDQo+IA0KPiBGb3IgdGhlIHJlcG9ydDoNCj4gDQo+PiBUaGUgeHRvb2xjaGFpbiBH Q0MgcGFja2FnZXMgaGF2ZSBub3QgcmVxdWlyZWQgdGhlc2UgZmxhZ3Mgc2luY2UgcG9ydHMN Cj4+ICAgY29tbWl0cyByNDY1NDE2IGFuZCByNDY2NzAxDQo+IA0KPiBMb29raW5nIGF0IGh0 dHBzOi8vY2kuZnJlZWJzZC5vcmcvam9iL0ZyZWVCU0QtaGVhZC1hbWQ2NC1nY2MvNjMzMS9j b25zb2xlVGV4dA0KPiB0aGVyZSBpczoNCj4gDQo+PiBVcGRhdGluZyBGcmVlQlNEIHJlcG9z aXRvcnkgY2F0YWxvZ3VlLi4uDQo+PiBGcmVlQlNEIHJlcG9zaXRvcnkgaXMgdXAgdG8gZGF0 ZS4NCj4+IEFsbCByZXBvc2l0b3JpZXMgYXJlIHVwIHRvIGRhdGUuDQo+PiBUaGUgZm9sbG93 aW5nIDYgcGFja2FnZShzKSB3aWxsIGJlIGFmZmVjdGVkIChvZiAwIGNoZWNrZWQpOg0KPj4N Cj4+IE5ldyBwYWNrYWdlcyB0byBiZSBJTlNUQUxMRUQ6DQo+PiAJYW1kNjQteHRvb2xjaGFp bi1nY2M6IDAuNF8xDQo+PiAJYW1kNjQtZ2NjOiA2LjQuMA0KPj4gCW1wZnI6IDQuMC4xDQo+ PiAJZ21wOiA2LjEuMg0KPj4gCW1wYzogMS4xLjBfMQ0KPj4gCWFtZDY0LWJpbnV0aWxzOiAy LjMwXzMsMQ0KPiANCj4gYW5kIGFtZDY0LWdjYyBiZWluZyA2LjQuMCAodmlhIHBvd2VycGM2 NC1nY2MpIGlzIGZyb20gLXI0NjY4MzQNCj4gKHZpYSBsb29raW5nIHVwIGluIGh0dHBzOi8v c3Zud2ViLmZyZWVic2Qub3JnL3BvcnRzL2hlYWQvZGV2ZWwvICkuDQo+IA0KPiBUaGlzIGlu ZGljYXRlcyB0aGF0IC1yNDY1NDE2IGFuZCAtcjQ2NjcwMSBkaWQgbm90IGNhdXNlOg0KPiAN Cj4gLS1zeXNyb290PS93b3Jrc3BhY2Uvb2JqL3dvcmtzcGFjZS9zcmMvYW1kNjQuYW1kNjQv b2JqLWxpYjMyL3RtcA0KPiANCj4gdG8gbGVhZCB0byBpbmNsdWRlIGZpbGVzIGJlaW5nIGxv b2tlZCB1cCBpbjoNCj4gDQo+IC93b3Jrc3BhY2Uvb2JqL3dvcmtzcGFjZS9zcmMvYW1kNjQu YW1kNjQvb2JqLWxpYjMyL3RtcC91c3IvaW5jbHVkZQ0KPiANCj4gVGh1cyB0aGVyZSBhcHBl YXJzIHRvIHN0aWxsIGJlIGEgbmVlZCBmb3I6DQo+IA0KPiAtaXN5c3RlbSAvd29ya3NwYWNl L29iai93b3Jrc3BhY2Uvc3JjL2FtZDY0LmFtZDY0L29iai1saWIzMi90bXAvdXNyL2luY2x1 ZGUNCj4gDQo+IHVubGVzcyBtb3JlIGlzIGRvbmUgdG8gdGhlIGRldmVsLyotZ2NjIHRvIG1h a2UgdGhlbSBsb29rDQo+IGluIHRoYXQgYWRkaXRpb25hbCBwbGFjZSBhdXRvbWF0aWNhbGx5 IChiYXNlZCBvbiAtLXN5c3Jvb3QpLg0KDQotLXN5c3Jvb3QgZG9lcyB3b3JrLCBhbmQgeW91 IGNhbiB2ZXJpZnkgaXQgYnkgZG9pbmcgdGhlIGZvbGxvd2luZzoNCg0KJSB0b3VjaCBlbXB0 eS5jDQolIHg4Nl82NC11bmtub3duLWZyZWVic2QxMS4yLWdjYyAtYyAtdiBlbXB0eS5jDQpV c2luZyBidWlsdC1pbiBzcGVjcy4NCkNPTExFQ1RfR0NDPXg4Nl82NC11bmtub3duLWZyZWVi c2QxMS4yLWdjYw0KVGFyZ2V0OiB4ODZfNjQtdW5rbm93bi1mcmVlYnNkMTEuMg0KLi4uDQpp Z25vcmluZyBub25leGlzdGVudCBkaXJlY3RvcnkgIi91c3IvbG9jYWwvbGliL2djYy94ODZf NjQtdW5rbm93bi1mcmVlYnNkMTEuMi82LjQuMC9pbmNsdWRlLWZpeGVkIg0KaWdub3Jpbmcg bm9uZXhpc3RlbnQgZGlyZWN0b3J5ICIvdXNyL2xvY2FsL2xpYi9nY2MveDg2XzY0LXVua25v d24tZnJlZWJzZDExLjIvNi40LjAvLi4vLi4vLi4vLi4veDg2XzY0LXVua25vd24tZnJlZWJz ZDExLjIvaW5jbHVkZSINCiNpbmNsdWRlICIuLi4iIHNlYXJjaCBzdGFydHMgaGVyZToNCiNp bmNsdWRlIDwuLi4+IHNlYXJjaCBzdGFydHMgaGVyZToNCiAvdXNyL2xvY2FsL2xpYi9nY2Mv eDg2XzY0LXVua25vd24tZnJlZWJzZDExLjIvNi40LjAvaW5jbHVkZQ0KIC91c3IvaW5jbHVk ZQ0KRW5kIG9mIHNlYXJjaCBsaXN0Lg0KLi4uDQolIHg4Nl82NC11bmtub3duLWZyZWVic2Qx MS4yLWdjYyAtYyAtdiBlbXB0eS5jICAtLXN5c3Jvb3Q9L2Zvbw0KVXNpbmcgYnVpbHQtaW4g c3BlY3MuDQpDT0xMRUNUX0dDQz14ODZfNjQtdW5rbm93bi1mcmVlYnNkMTEuMi1nY2MNClRh cmdldDogeDg2XzY0LXVua25vd24tZnJlZWJzZDExLjINCi4uLg0KaWdub3Jpbmcgbm9uZXhp c3RlbnQgZGlyZWN0b3J5ICIvdXNyL2xvY2FsL2xpYi9nY2MveDg2XzY0LXVua25vd24tZnJl ZWJzZDExLjIvNi40LjAvaW5jbHVkZS1maXhlZCINCmlnbm9yaW5nIG5vbmV4aXN0ZW50IGRp cmVjdG9yeSAiL3Vzci9sb2NhbC9saWIvZ2NjL3g4Nl82NC11bmtub3duLWZyZWVic2QxMS4y LzYuNC4wLy4uLy4uLy4uLy4uL3g4Nl82NC11bmtub3duLWZyZWVic2QxMS4yL2luY2x1ZGUi DQppZ25vcmluZyBub25leGlzdGVudCBkaXJlY3RvcnkgIi9mb28vdXNyL2luY2x1ZGUiDQoj aW5jbHVkZSAiLi4uIiBzZWFyY2ggc3RhcnRzIGhlcmU6DQojaW5jbHVkZSA8Li4uPiBzZWFy Y2ggc3RhcnRzIGhlcmU6DQogL3Vzci9sb2NhbC9saWIvZ2NjL3g4Nl82NC11bmtub3duLWZy ZWVic2QxMS4yLzYuNC4wL2luY2x1ZGUNCkVuZCBvZiBzZWFyY2ggbGlzdC4NCg0KSSB3aWxs IHNlZSBpZiBJIGNhbiByZXByb2R1Y2UgdGhlIGZhaWx1cmUgbG9jYWxseS4NCg0KLS0gDQpK b2huIEJhbGR3aW4NCg== From owner-freebsd-current@freebsd.org Fri Jun 29 20:26: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 956F7F7889F; Fri, 29 Jun 2018 20:26:06 +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 349FD7A2AB; Fri, 29 Jun 2018 20:26:06 +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 4C42910AFCD; Fri, 29 Jun 2018 16:26:04 -0400 (EDT) Subject: Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build) To: Mark Millard , Bryan Drewery References: <00D1127A-1F0E-4E0E-B86C-1C5AA5B2E085@yahoo.com> <7A845F2C-C994-4828-823D-33A97B7B6EB0@yahoo.com> Cc: svn-src-head@freebsd.org, FreeBSD Current From: John Baldwin Message-ID: Date: Fri, 29 Jun 2018 13:26:03 -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: <7A845F2C-C994-4828-823D-33A97B7B6EB0@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, 29 Jun 2018 16:26:04 -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.26 Precedence: 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, 29 Jun 2018 20:26:06 -0000 On 6/28/18 7:54 PM, Mark Millard wrote: > On 2018-Jun-28, at 6:04 PM, Mark Millard wrote: > >> On 2018-Jun-28, at 5:39 PM, Mark Millard wrote: >> >>> [ ci.free.bsd.org jumped from -r335773 (built) to -r335784 (failed) >>> for FreeBSD-head-amd64-gcc. It looked to me like the most likely >>> breaking-change was the following but I've not tried personal >>> builds to confirm. >>> ] So this is a bit complicated and I'm not sure what the correct fix is. What is happening is that the shipped with GCC is now being used after this change instead of sys/x86/include/float.h. A sledgehammer approach would be to remove float.h from the GCC package (we currently don't install the float.h for the base system clang either). However, looking at this in more detail, it seems that x86/include/float.h is also busted in some ways. First, the #error I don't understand how it is happening. The GCC float.h defines LDBL_MAX_EXP to the __LDBL_MAX_EXP__ builtin which is 16384 just like the x86 float.h: # x86_64-unknown-freebsd12.0-gcc -dM -E empty.c -m32 | grep LDBL_MAX_EXP #define __LDBL_MAX_EXP__ 16384 I even hacked catrigl.c to add the following lines before the #error check: LDBL_MAX_EXP_ = LDBL_MAX_EXP LDBL_MANT_DIG_ = LDBL_MANT_DIG #if LDBL_MAX_EXP != 0x4000 #error "Unsupported long double format" #endif And the -E output is: DBL_MAX_EXP_ = 16384 LDBL_MANT_DIG_ = 53 # 51 "/zoo/jhb/zoo/jhb/git/freebsd/lib/msun/src/catrigl.c:93:2: error: #error "U nsupported long double format" #error "Unsupported long double format" ^~~~~ Yet clearly, 16384 == 0x4000 assuming it is doing a numeric comparison (which it must be since the x86 float.h uses '16384' not '0x4000' as the value). However, LDBL_MANT_DIG of 53 is a bit more fun. We have a comment about the initial FPU control word in sys/amd64/include/fpu.h that reads thus: /* * The hardware default control word for i387's and later coprocessors is * 0x37F, giving: * * round to nearest * 64-bit precision * all exceptions masked. * * FreeBSD/i386 uses 53 bit precision for things like fadd/fsub/fsqrt etc * because of the difference between memory and fpu register stack arguments. * If its using an intermediate fpu register, it has 80/64 bits to work * with. If it uses memory, it has 64/53 bits to work with. However, * gcc is aware of this and goes to a fair bit of trouble to make the * best use of it. * * This is mostly academic for AMD64, because the ABI prefers the use * SSE2 based math. For FreeBSD/amd64, we go with the default settings. */ #define __INITIAL_FPUCW__ 0x037F #define __INITIAL_FPUCW_I386__ 0x127F #define __INITIAL_NPXCW__ __INITIAL_FPUCW_I386__ #define __INITIAL_MXCSR__ 0x1F80 #define __INITIAL_MXCSR_MASK__ 0xFFBF GCC is indeed aware of this in gcc/config/i386/freebsd.h which results in __LDBL_MANT_DIG__ being set to 53 instead of 64: /* FreeBSD sets the rounding precision of the FPU to 53 bits. Let the compiler get the contents of and std::numeric_limits correct. */ #undef TARGET_96_ROUND_53_LONG_DOUBLE #define TARGET_96_ROUND_53_LONG_DOUBLE (!TARGET_64BIT) clang seems unaware of this as it reports all the same values for LDBL_MIN/MAX for both amd64 and i386 (values that match GCC for amd64 but not i386): # cc -dM -E empty.c | egrep 'LDBL_(MIN|MAX)__' #define __LDBL_MAX__ 1.18973149535723176502e+4932L #define __LDBL_MIN__ 3.36210314311209350626e-4932L # cc -dM -E empty.c -m32 | egrep 'LDBL_(MIN|MAX)__' #define __LDBL_MAX__ 1.18973149535723176502e+4932L #define __LDBL_MIN__ 3.36210314311209350626e-4932L # x86_64-unknown-freebsd12.0-gcc -dM -E empty.c | egrep 'LDBL_(MIN|MAX)__' #define __LDBL_MAX__ 1.18973149535723176502e+4932L #define __LDBL_MIN__ 3.36210314311209350626e-4932L # x86_64-unknown-freebsd12.0-gcc -dM -E empty.c -m32 | egrep 'LDBL_(MIN|MAX)__' #define __LDBL_MAX__ 1.1897314953572316e+4932L #define __LDBL_MIN__ 3.3621031431120935e-4932L The x86/include/float.h header though reports the MIN/MAX values somewhere in between the two ranges for both amd64 and i386 while reporting an LDBL_MANT_DIG of 64: #define LDBL_MANT_DIG 64 #define LDBL_MIN 3.3621031431120935063E-4932L #define LDBL_MAX 1.1897314953572317650E+4932L I guess for now I will remove float.h from the amd64-gcc pkg-plist, but we should really be fixing our tree to work with compiler-provided language headers when at all possible. It's not clear to me if amd64 should be using the compiler provided values of things like LDBL_MIN/MAX either btw. -- John Baldwin From owner-freebsd-current@freebsd.org Fri Jun 29 21:58: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 6678AF7E54E for ; Fri, 29 Jun 2018 21:58:11 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-21.consmr.mail.gq1.yahoo.com (sonic306-21.consmr.mail.gq1.yahoo.com [98.137.68.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 C5A727DC64 for ; Fri, 29 Jun 2018 21:58:10 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: kd46I7oVM1lvRhfvJTN5ixEGj_EQ2w1I6KSrwUgxSufWVcivsT34ltwi6snz76f 71BSTYvaJNgW_M7etNgSAOD5grnXy3JAYvZ1tig56LB5kH4GKRoTX6AXyMRE4a_4eTU3mT7IP3N_ dh0pyEVkJNq694ynYJHLao6jFtpejVUloeITs9zCbSkiuXZZMJhP7M3nM2i5xzf1ysIkX8cZuKzx ZZDSUvwQJTd4st5.yoI6a5HqADO7OZFO8ib1k6.2ZF48K6.hubEM2107jfTBolFYJIlSSD_cPUeo MsqIe5Ze3Ll9j9IA3YHK0nQ5aBqISHARIarbrSSjVruXJ2OwNjEZ8vdljRly7_7z.xg.2y_L_7lE V2qf.9VcNo5Gxn.mcIGzVv.RXj20Do2_ycF_9xJXkeyLetoyLb8V3mmTHJCvOaHycNYkrOsEi73Y N1ApwNw17telYS7Ifz9WMgosihlCXcikOAaMNbz39aUsN11F9bqCknn27l1zR1F_N1hDIW6PeE9K IjOogv91WMx.8rQ5Id8serkmOPVYkShCbqK.bc2GEt5h_ffUYBLlD.6qBK4axGCmgpOIwFJ6d1cP oYHhtn40.bBYBNvigXqTKoV6kfL.OF9AJ96cb0mIwXg9mMkMt5un7Om26.Qo_ZhULRn9f.cUPNNq IXBqcV.F8pUDuU7FgbjIujObZP2NPKC9hfc1gSrgNFMh5Z9cBR.MM4mSBWdueHDYwh8ra29LHIwG ypysy1dyFuTcjnh8wiWe7zBVZQj_IfigMg4XfKXWJvYRNhI.06YmRT0oSXfDvPoQUVu.wLfxgk_c LP8HeOrlqpiCS24KDWILxjqBhBAegAAfybOnz2Z9nkG.raEdZFFpxf7pSXbLIB_B7drffgfPOoF4 Ynt09rtPn7MIFBB2K4n4gymA9qVgWcvRvkkEPFDZbYp_gT.0UMh7Gw3c1XOh8fh4W5PHeywbm3sz rRA80k.6JRST3z1ai2Xorfd6VWk9HnVc- Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Fri, 29 Jun 2018 21:58:09 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp407.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 5ff4b36b23986c2b46e7ca46bb74cb75; Fri, 29 Jun 2018 21:37:51 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build) From: Mark Millard In-Reply-To: <72081b02-cf23-82ec-32df-7f5793c35f57@FreeBSD.org> Date: Fri, 29 Jun 2018 14:37:49 -0700 Cc: Bryan Drewery , svn-src-head@freebsd.org, FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <003509F0-F2F4-4A43-82FE-3F6FC23D19D4@yahoo.com> References: <00D1127A-1F0E-4E0E-B86C-1C5AA5B2E085@yahoo.com> <7A845F2C-C994-4828-823D-33A97B7B6EB0@yahoo.com> <72081b02-cf23-82ec-32df-7f5793c35f57@FreeBSD.org> To: John Baldwin X-Mailer: Apple Mail (2.3445.8.2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 29 Jun 2018 21:58:11 -0000 [I expect this is more than just amd64-gcc related but that is all that ci.freebsd.org normally builds via a devel/*-gcc .] On 2018-Jun-29, at 10:38 AM, John Baldwin wrote: > On 6/28/18 7:54 PM, Mark Millard wrote: >> On 2018-Jun-28, at 6:04 PM, Mark Millard = wrote: >>=20 >>> On 2018-Jun-28, at 5:39 PM, Mark Millard = wrote: >>>=20 >>> . . . >>> Later below expand the failing and previoly good commands, one >>> option per line. The summary of the distinction in content is >>> a one line difference, the working example ( -r335773 )had the >>> option: >>>=20 >>> -isystem = /workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/include >>>=20 >>> but the failing one did not. Working ( -r335773 ) is shown first. >>>=20 >>> --- catrigl.o --- >>> /usr/local/bin/x86_64-unknown-freebsd11.1-gcc >>> -DCOMPAT_32BIT >>> -march=3Di686 >>> -mmmx >>> -msse >>> -msse2 >>> -m32 >>> -L/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/lib32 >>> --sysroot=3D/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp >>> -B/usr/local/x86_64-unknown-freebsd11.1/bin/ >>> -B/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/lib32 >>> -isystem = /workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/include >>> -O2 >>> -pipe >>> -I/workspace/src/lib/msun/x86 >>> -I/workspace/src/lib/msun/ld80 >>> -I/workspace/src/lib/msun/i387 >>> -I/workspace/src/lib/msun/src >>> -I/workspace/src/lib/libc/include >>> -I/workspace/src/lib/libc/i386 >>> . . . >>>=20 >>> --- catrigl.o --- >>> /usr/local/bin/x86_64-unknown-freebsd11.1-gcc >>> -DCOMPAT_32BIT >>> -march=3Di686 >>> -mmmx >>> -msse >>> -msse2 >>> -m32 >>> -L/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/lib32 >>> --sysroot=3D/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp >>> -B/usr/local/x86_64-unknown-freebsd11.1/bin/ >>> -B/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/lib32 >>> -O2 >>> -pipe >>> -I/workspace/src/lib/msun/x86 >>> -I/workspace/src/lib/msun/ld80 >>> -I/workspace/src/lib/msun/i387 >>> -I/workspace/src/lib/msun/src >>> -I/workspace/src/lib/libc/include=20 >>> -I/workspace/src/lib/libc/i386 >>> . . . >>=20 >>=20 >> For the report: >>=20 >>> The xtoolchain GCC packages have not required these flags since = ports >>> commits r465416 and r466701 >>=20 >> Looking at = https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6331/consoleText >> there is: >>=20 >>> Updating FreeBSD repository catalogue... >>> FreeBSD repository is up to date. >>> All repositories are up to date. >>> The following 6 package(s) will be affected (of 0 checked): >>>=20 >>> New packages to be INSTALLED: >>> amd64-xtoolchain-gcc: 0.4_1 >>> amd64-gcc: 6.4.0 >>> mpfr: 4.0.1 >>> gmp: 6.1.2 >>> mpc: 1.1.0_1 >>> amd64-binutils: 2.30_3,1 >>=20 >> and amd64-gcc being 6.4.0 (via powerpc64-gcc) is from -r466834 >> (via looking up in https://svnweb.freebsd.org/ports/head/devel/ ). >>=20 >> This indicates that -r465416 and -r466701 did not cause: >>=20 >> --sysroot=3D/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp >>=20 >> to lead to include files being looked up in: >>=20 >> /workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/include >>=20 >> Thus there appears to still be a need for: >>=20 >> -isystem = /workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/include >>=20 >> unless more is done to the devel/*-gcc to make them look >> in that additional place automatically (based on --sysroot). >=20 > --sysroot does work, and you can verify it by doing the following: >=20 > % touch empty.c > % x86_64-unknown-freebsd11.2-gcc -c -v empty.c > Using built-in specs. > COLLECT_GCC=3Dx86_64-unknown-freebsd11.2-gcc > Target: x86_64-unknown-freebsd11.2 > ... > ignoring nonexistent directory = "/usr/local/lib/gcc/x86_64-unknown-freebsd11.2/6.4.0/include-fixed" > ignoring nonexistent directory = "/usr/local/lib/gcc/x86_64-unknown-freebsd11.2/6.4.0/../../../../x86_64-un= known-freebsd11.2/include" > #include "..." search starts here: > #include <...> search starts here: > /usr/local/lib/gcc/x86_64-unknown-freebsd11.2/6.4.0/include > /usr/include > End of search list. > ... > % x86_64-unknown-freebsd11.2-gcc -c -v empty.c --sysroot=3D/foo > Using built-in specs. > COLLECT_GCC=3Dx86_64-unknown-freebsd11.2-gcc > Target: x86_64-unknown-freebsd11.2 > ... > ignoring nonexistent directory = "/usr/local/lib/gcc/x86_64-unknown-freebsd11.2/6.4.0/include-fixed" > ignoring nonexistent directory = "/usr/local/lib/gcc/x86_64-unknown-freebsd11.2/6.4.0/../../../../x86_64-un= known-freebsd11.2/include" > ignoring nonexistent directory "/foo/usr/include" > #include "..." search starts here: > #include <...> search starts here: > /usr/local/lib/gcc/x86_64-unknown-freebsd11.2/6.4.0/include > End of search list. >=20 > I will see if I can reproduce the failure locally. The: ignoring nonexistent directory "/foo/usr/include" means that the order of the search alternatives was not shown ("search starts here"). That is what I expect is different. It will take a while before I'll have a build from either before or after the change to show a search order with. (And longer to have both for comparison.) My context is freebsd12.0 . My buildworld buildkernel context has: # more ~/src.configs/make.conf=20 CFLAGS.gcc+=3D -v so my script file for a build is very explicit about the order. I'll be starting from # uname -apKU FreeBSD FBSDUSSD 12.0-CURRENT FreeBSD 12.0-CURRENT r335245M amd64 = amd64 1200069 1200069 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Sat Jun 30 00:14: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 D2D98FD5439 for ; Sat, 30 Jun 2018 00:14:45 +0000 (UTC) (envelope-from dim@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 5F0B5824B2 for ; Sat, 30 Jun 2018 00:14:45 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 15766FD5437; Sat, 30 Jun 2018 00:14: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 029A3FD5436 for ; Sat, 30 Jun 2018 00:14:45 +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 84969824B1 for ; Sat, 30 Jun 2018 00:14:44 +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 B6000D549; Sat, 30 Jun 2018 02:14:36 +0200 (CEST) From: Dimitry Andric Message-Id: <39E9E542-8690-40AA-92D3-DA5523DE6FDD@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_27D4102D-1D31-41DA-A149-6B8BC91AC953"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: RiscV tinderbox fails Date: Sat, 30 Jun 2018 02:14:31 +0200 In-Reply-To: <611243783F62AF48AFB07BC25FA4B10629917799@DLDEFFMIMP01EXC.intra.dlr.de> Cc: current@freebsd.org To: Hartmut.Brandt@dlr.de References: <611243783F62AF48AFB07BC25FA4B10629917799@DLDEFFMIMP01EXC.intra.dlr.de> X-Mailer: Apple Mail (2.3445.8.2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 30 Jun 2018 00:14:46 -0000 --Apple-Mail=_27D4102D-1D31-41DA-A149-6B8BC91AC953 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 29 Jun 2018, at 13:33, Hartmut.Brandt@dlr.de wrote: >=20 > is it supposed not to fail? I get: >=20 > /usr/obj/usr/src/riscv.riscv64sf/tmp/usr/lib/libgcc.a(comparedf2.o): = In function > `__gedf2': > /usr/src/contrib/compiler-rt/lib/builtins/comparedf2.c:101: multiple = definition > of `__gedf2' > = /usr/obj/usr/src/riscv.riscv64sf/tmp/usr/lib/libc.a(gedf2.o):/usr/src/lib/= libc/s > oftfloat/gedf2.c:18: first defined here > /usr/obj/usr/src/riscv.riscv64sf/tmp/usr/lib/libgcc.a(comparedf2.o): = In function > `__eqdf2': > /usr/src/contrib/compiler-rt/lib/builtins/comparedf2.c:127: multiple = definition > of `__eqdf2' > = /usr/obj/usr/src/riscv.riscv64sf/tmp/usr/lib/libc.a(eqdf2.o):/usr/src/lib/= libc/s > oftfloat/eqdf2.c:18: first defined here > /usr/obj/usr/src/riscv.riscv64sf/tmp/usr/lib/libgcc.a(comparedf2.o): = In function > `__ltdf2': > /usr/src/contrib/compiler-rt/lib/builtins/comparedf2.c:127: multiple = definition > of `__ltdf2' > = /usr/obj/usr/src/riscv.riscv64sf/tmp/usr/lib/libc.a(ltdf2.o):/usr/src/lib/= libc/s > oftfloat/ltdf2.c:18: first defined here > /usr/obj/usr/src/riscv.riscv64sf/tmp/usr/lib/libgcc.a(comparedf2.o): = In function > `__nedf2': > /usr/src/contrib/compiler-rt/lib/builtins/comparedf2.c:127: multiple = definition > of `__nedf2' > = /usr/obj/usr/src/riscv.riscv64sf/tmp/usr/lib/libc.a(nedf2.o):/usr/src/lib/= libc/s > oftfloat/nedf2.c:18: first defined here > /usr/obj/usr/src/riscv.riscv64sf/tmp/usr/lib/libgcc.a(comparedf2.o): = In function > `__gtdf2': > /usr/src/contrib/compiler-rt/lib/builtins/comparedf2.c:142: multiple = definition > of `__gtdf2' > = /usr/obj/usr/src/riscv.riscv64sf/tmp/usr/lib/libc.a(gtdf2.o):/usr/src/lib/= libc/s > oftfloat/gtdf2.c:18: first defined here > collect2: error: ld returned 1 exit status > *** [nologin.full] Error code 1 As far as I know, it has been broken for quite some time. I guess for riscv those functions need to be defined either in libc, or in compiler-rt, but not both... -Dimitry --Apple-Mail=_27D4102D-1D31-41DA-A149-6B8BC91AC953 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 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCWzbLZwAKCRCwXqMKLiCW o05DAKCj4HbXWhj61yb1tz+2yCaaH8R8nACeObzKTdH/Y94ijcWNItq5sUdzDAM= =Mea7 -----END PGP SIGNATURE----- --Apple-Mail=_27D4102D-1D31-41DA-A149-6B8BC91AC953-- From owner-freebsd-current@freebsd.org Sat Jun 30 00:05: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 D4ED4FD4F12; Sat, 30 Jun 2018 00:05:16 +0000 (UTC) (envelope-from rlibby@gmail.com) Received: from mail-pl0-x233.google.com (mail-pl0-x233.google.com [IPv6:2607:f8b0:400e:c01::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 3AA56821A8; Sat, 30 Jun 2018 00:05:16 +0000 (UTC) (envelope-from rlibby@gmail.com) Received: by mail-pl0-x233.google.com with SMTP id bi1-v6so5165900plb.12; Fri, 29 Jun 2018 17:05:16 -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 :cc; bh=evN0dJ+3tS5Odd/ZRXg3SF2Jl5U4GgRB8DSHHsoe+yc=; b=n/U7SNkXPUgP532+k9d9QT8xtjtcLdLK8w1Wzlm/ew/jKDYVTvYwESF4bzwraHhhzb osd/ZNmn9rxGIjqGXzkC+A3LP3FS8MRs81BmCofbvl+yZU+CPXqyYByQokoVY2ATBGn7 ItfII8OYT+YfdOAQQiuxhVhiIPYxJ9f66+6OkJkSpwSi5MLwbRJ9B7JRvTU+tE8uJff/ c3fGv1JKkiqFYnyEhO3UfvaPOCVyGTzozI4uexnR/wkfUQTRhEIuRmFfB6Ce39nIhdFE x58yHpziBglYIvVG5bXs0EATuab6dDSEt8U5vuyhqJPHqQzqwDS+Gb8v1x/l7yChCldZ i+4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=evN0dJ+3tS5Odd/ZRXg3SF2Jl5U4GgRB8DSHHsoe+yc=; b=WUhmG0H54lW5zIHbv2eGCuTgaBCUfnuuQaeWmm1p3k4Iu5zKp2x09F/HyEBbMEDNcs uCdpkKjjPJXFvvvmm9+0wOSRqhZXBbw9b4PitugMOtR+T5eyCFYJa+PdijYY6SjE1LO4 XXBPdDjYyYFBoHVWejgAJlisuRAnQXGDOWKivZsOZ2CjA/15AoRA5r2NsaslSJCQx3Oj a/aTzo2fHOuTRmRFSWJkDQmEq9g2yH/jUbN4/HRQ2Dv7IfOF/TQpYh1YMOAzGfoYiacY Y+PLAWuDFIjsUC4R7RySlRHZC0/F/yRPckut2e2Y2w6RvE2KAdbPUhys0uJPUkKswRto 5s4Q== X-Gm-Message-State: APt69E3fJMZcD/7xFGAbsGYuiq6o4XzTqe1a41G4XGiFrLGXXPuVbDZG nHagbCBReTJRXCAjpu55JTkqKPAt70/1FpyRT+nc2ltE X-Google-Smtp-Source: ADUXVKLGFyQvEbacjVfcqnx7WNmhUwHuRLMSwTf/wxY+YOUxtEU066sPm9voUIkMrONr9QQeiRXIUgm+GkIZUB8dBKg= X-Received: by 2002:a17:902:6acc:: with SMTP id i12-v6mr16849374plt.278.1530317114687; Fri, 29 Jun 2018 17:05:14 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:1581:0:0:0:0 with HTTP; Fri, 29 Jun 2018 17:05:13 -0700 (PDT) In-Reply-To: References: <00D1127A-1F0E-4E0E-B86C-1C5AA5B2E085@yahoo.com> <7A845F2C-C994-4828-823D-33A97B7B6EB0@yahoo.com> From: Ryan Libby Date: Fri, 29 Jun 2018 17:05:13 -0700 Message-ID: Subject: Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build) To: John Baldwin Cc: Mark Millard , Bryan Drewery , svn-src-head@freebsd.org, FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Mailman-Approved-At: Sat, 30 Jun 2018 00:29:08 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 30 Jun 2018 00:05:17 -0000 On Fri, Jun 29, 2018 at 1:26 PM, John Baldwin wrote: > On 6/28/18 7:54 PM, Mark Millard wrote: >> On 2018-Jun-28, at 6:04 PM, Mark Millard wrote: >> >>> On 2018-Jun-28, at 5:39 PM, Mark Millard wrote: >>> >>>> [ ci.free.bsd.org jumped from -r335773 (built) to -r335784 (failed) >>>> for FreeBSD-head-amd64-gcc. It looked to me like the most likely >>>> breaking-change was the following but I've not tried personal >>>> builds to confirm. >>>> ] > > So this is a bit complicated and I'm not sure what the correct fix is. > > What is happening is that the shipped with GCC is now being used > after this change instead of sys/x86/include/float.h. A sledgehammer approach > would be to remove float.h from the GCC package (we currently don't install > the float.h for the base system clang either). However, looking at this > in more detail, it seems that x86/include/float.h is also busted in some > ways. > > First, the #error I don't understand how it is happening. The GCC float.h > defines LDBL_MAX_EXP to the __LDBL_MAX_EXP__ builtin which is 16384 just > like the x86 float.h: > > # x86_64-unknown-freebsd12.0-gcc -dM -E empty.c -m32 | grep LDBL_MAX_EXP > #define __LDBL_MAX_EXP__ 16384 > > I even hacked catrigl.c to add the following lines before the #error > check: > > LDBL_MAX_EXP_ = LDBL_MAX_EXP > LDBL_MANT_DIG_ = LDBL_MANT_DIG > > #if LDBL_MAX_EXP != 0x4000 > #error "Unsupported long double format" > #endif > > And the -E output is: > > DBL_MAX_EXP_ = 16384 > LDBL_MANT_DIG_ = 53 > > # 51 "/zoo/jhb/zoo/jhb/git/freebsd/lib/msun/src/catrigl.c:93:2: error: #error "U > nsupported long double format" > #error "Unsupported long double format" > ^~~~~ > > Yet clearly, 16384 == 0x4000 assuming it is doing a numeric comparison (which > it must be since the x86 float.h uses '16384' not '0x4000' as the value). > Isn't this just the unsupported LDBL_MANT_DIG you're hitting here? Note line 93. I reused the same error message for LDBL_MAX_EXP :/ > However, LDBL_MANT_DIG of 53 is a bit more fun. We have a comment about the > initial FPU control word in sys/amd64/include/fpu.h that reads thus: > > /* > * The hardware default control word for i387's and later coprocessors is > * 0x37F, giving: > * > * round to nearest > * 64-bit precision > * all exceptions masked. > * > * FreeBSD/i386 uses 53 bit precision for things like fadd/fsub/fsqrt etc > * because of the difference between memory and fpu register stack arguments. > * If its using an intermediate fpu register, it has 80/64 bits to work > * with. If it uses memory, it has 64/53 bits to work with. However, > * gcc is aware of this and goes to a fair bit of trouble to make the > * best use of it. > * > * This is mostly academic for AMD64, because the ABI prefers the use > * SSE2 based math. For FreeBSD/amd64, we go with the default settings. > */ > #define __INITIAL_FPUCW__ 0x037F > #define __INITIAL_FPUCW_I386__ 0x127F > #define __INITIAL_NPXCW__ __INITIAL_FPUCW_I386__ > #define __INITIAL_MXCSR__ 0x1F80 > #define __INITIAL_MXCSR_MASK__ 0xFFBF > > GCC is indeed aware of this in gcc/config/i386/freebsd.h which results in > __LDBL_MANT_DIG__ being set to 53 instead of 64: > > /* FreeBSD sets the rounding precision of the FPU to 53 bits. Let the > compiler get the contents of and std::numeric_limits correct. */ > #undef TARGET_96_ROUND_53_LONG_DOUBLE > #define TARGET_96_ROUND_53_LONG_DOUBLE (!TARGET_64BIT) > > clang seems unaware of this as it reports all the same values for > LDBL_MIN/MAX for both amd64 and i386 (values that match GCC for amd64 > but not i386): > > # cc -dM -E empty.c | egrep 'LDBL_(MIN|MAX)__' > #define __LDBL_MAX__ 1.18973149535723176502e+4932L > #define __LDBL_MIN__ 3.36210314311209350626e-4932L > # cc -dM -E empty.c -m32 | egrep 'LDBL_(MIN|MAX)__' > #define __LDBL_MAX__ 1.18973149535723176502e+4932L > #define __LDBL_MIN__ 3.36210314311209350626e-4932L > # x86_64-unknown-freebsd12.0-gcc -dM -E empty.c | egrep 'LDBL_(MIN|MAX)__' > #define __LDBL_MAX__ 1.18973149535723176502e+4932L > #define __LDBL_MIN__ 3.36210314311209350626e-4932L > # x86_64-unknown-freebsd12.0-gcc -dM -E empty.c -m32 | egrep 'LDBL_(MIN|MAX)__' > #define __LDBL_MAX__ 1.1897314953572316e+4932L > #define __LDBL_MIN__ 3.3621031431120935e-4932L > > The x86/include/float.h header though reports the MIN/MAX values somewhere > in between the two ranges for both amd64 and i386 while reporting an > LDBL_MANT_DIG of 64: > > #define LDBL_MANT_DIG 64 > #define LDBL_MIN 3.3621031431120935063E-4932L > #define LDBL_MAX 1.1897314953572317650E+4932L > > I guess for now I will remove float.h from the amd64-gcc pkg-plist, but we > should really be fixing our tree to work with compiler-provided language > headers when at all possible. It's not clear to me if amd64 should be > using the compiler provided values of things like LDBL_MIN/MAX either btw. > > -- > John Baldwin > _______________________________________________ > 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" The whole situation is a little messed up. LDBL_MAX, LDBL_MIN, and LDBL_MANT_DIG are IMHO broken by design, because they are just the defaults. User code can change the mode, and then the constants necessarily yield weird things, like max - epsilon becoming infinity, or not actually being the maximum possible finite value. It's difficult for code to use them correctly--which was why I removed references to LDBL_MAX in [1]. Some general background on that aspect here [2]. [1] https://svnweb.freebsd.org/base?view=revision&revision=323003 [2] https://lists.freebsd.org/pipermail/freebsd-numerics/2012-September/000288.html From owner-freebsd-current@freebsd.org Sat Jun 30 00:29: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 F310AFD5CE0 for ; Sat, 30 Jun 2018 00:29:42 +0000 (UTC) (envelope-from gurenchan@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 69BC982A01 for ; Sat, 30 Jun 2018 00:29:42 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 2070AFD5CDA; Sat, 30 Jun 2018 00:29:42 +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 D5011FD5CD9 for ; Sat, 30 Jun 2018 00:29:41 +0000 (UTC) (envelope-from gurenchan@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 63322829FE; Sat, 30 Jun 2018 00:29:41 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-it0-x22e.google.com with SMTP id p185-v6so5144077itp.4; Fri, 29 Jun 2018 17:29:41 -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 :cc; bh=uA87LiOc7Cna1QwPkKREbZ6yOUcSdf6AfluvPJ5BnTs=; b=h7B9feSJYPRPkQCS9UsdoVM0gh5R7Y7txf11KdEdvDPVRT15T6YVzePLk9uNIDhg+S 4VqwPKSR/n/f3LLBu1CFf2mh2TROBL8ZGXa2avsCSTLJiYGz/FItIbQUrN2d6ZVr1mt3 HZjq9WDjrPBxmMh3Slgn+ne/Y0cf7RBSpYMI8QM9aj/I6GPSIzbOYDJrei4wfPWL9klM m4rivCp4JkrxBeC2YFxXhp3kqbwspY8LBRYaJWpmMTj/S5tT7d5tdCAY0+pEMUqDb1PZ 5Dap7/JhyfMFfUAWDNJSjX4Pz75yOc1q9B+2AWEuiwD9eNoMgndI+QNS53am77rlGYDp xWrA== 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=uA87LiOc7Cna1QwPkKREbZ6yOUcSdf6AfluvPJ5BnTs=; b=tugb3Orcp+ZLBy22PMyHOGoNdm46JlyL/P6Af3YboAiRImbdZeTpYiDZrd4n+FtN7W UqC5ta5w13nfYz2IZw+KN0Ed6NCLJ7Nu5elhW4l5A7bJZRTXBllL/SarrxuvYp2nh9Ie MrdnIHEBib+k+QMcXrpG5UcAWB6rYYXAOqMwDAierFez+et7jkE1KXWb6yQ7bJhfBJkW CuR3mc8BuenmcCGvlXq/W/Ug3dDMd+cInVEgaFzsiQirPYxnHzn5KhX1CYQFIWvZFncB oxTqCqJOBWUzrANgVFi4BNSk5EfiKPCOlQahf40rhbyFVROaA+OaMiuWlEhZvNVtOtHj zLtA== X-Gm-Message-State: APt69E2HxzHmxVn1yxao78sT2fukVKn37tPMMrmpIzGwadzGg2NjLdCB 3Jnjy+5S3fUEeAxpfEy/l8bAluQ5x3AqstM4WIU= X-Google-Smtp-Source: AAOMgpeXTQVRaIyjZMYCAOByRWiXjjFwGlqLIZkdH9fXPTotRuJHKrrGuw0s/ajziTI6G5ABfKYtB0O1h/wwClRnnX0= X-Received: by 2002:a02:1045:: with SMTP id 66-v6mr13756140jay.133.1530318580533; Fri, 29 Jun 2018 17:29:40 -0700 (PDT) MIME-Version: 1.0 References: <611243783F62AF48AFB07BC25FA4B10629917799@DLDEFFMIMP01EXC.intra.dlr.de> <39E9E542-8690-40AA-92D3-DA5523DE6FDD@FreeBSD.org> In-Reply-To: <39E9E542-8690-40AA-92D3-DA5523DE6FDD@FreeBSD.org> From: blubee blubeeme Date: Sat, 30 Jun 2018 08:29:50 +0800 Message-ID: Subject: Re: RiscV tinderbox fails To: Dimitry Andric Cc: Hartmut.Brandt@dlr.de, current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 30 Jun 2018 00:29:43 -0000 It seems to be that the FreeBSD implementation of the RISC-V has stalled and development is only proceeding on Linux with GCC. In my opinion FreeBSD forget GCC and work on implementing RISC-V backend for the llvm project. On Sat, Jun 30, 2018, 08:18 Dimitry Andric wrote: > On 29 Jun 2018, at 13:33, Hartmut.Brandt@dlr.de wrote: > > > > is it supposed not to fail? I get: > > > > /usr/obj/usr/src/riscv.riscv64sf/tmp/usr/lib/libgcc.a(comparedf2.o): In > function > > `__gedf2': > > /usr/src/contrib/compiler-rt/lib/builtins/comparedf2.c:101: multiple > definition > > of `__gedf2' > > > /usr/obj/usr/src/riscv.riscv64sf/tmp/usr/lib/libc.a(gedf2.o):/usr/src/lib/libc/s > > oftfloat/gedf2.c:18: first defined here > > /usr/obj/usr/src/riscv.riscv64sf/tmp/usr/lib/libgcc.a(comparedf2.o): In > function > > `__eqdf2': > > /usr/src/contrib/compiler-rt/lib/builtins/comparedf2.c:127: multiple > definition > > of `__eqdf2' > > > /usr/obj/usr/src/riscv.riscv64sf/tmp/usr/lib/libc.a(eqdf2.o):/usr/src/lib/libc/s > > oftfloat/eqdf2.c:18: first defined here > > /usr/obj/usr/src/riscv.riscv64sf/tmp/usr/lib/libgcc.a(comparedf2.o): In > function > > `__ltdf2': > > /usr/src/contrib/compiler-rt/lib/builtins/comparedf2.c:127: multiple > definition > > of `__ltdf2' > > > /usr/obj/usr/src/riscv.riscv64sf/tmp/usr/lib/libc.a(ltdf2.o):/usr/src/lib/libc/s > > oftfloat/ltdf2.c:18: first defined here > > /usr/obj/usr/src/riscv.riscv64sf/tmp/usr/lib/libgcc.a(comparedf2.o): In > function > > `__nedf2': > > /usr/src/contrib/compiler-rt/lib/builtins/comparedf2.c:127: multiple > definition > > of `__nedf2' > > > /usr/obj/usr/src/riscv.riscv64sf/tmp/usr/lib/libc.a(nedf2.o):/usr/src/lib/libc/s > > oftfloat/nedf2.c:18: first defined here > > /usr/obj/usr/src/riscv.riscv64sf/tmp/usr/lib/libgcc.a(comparedf2.o): In > function > > `__gtdf2': > > /usr/src/contrib/compiler-rt/lib/builtins/comparedf2.c:142: multiple > definition > > of `__gtdf2' > > > /usr/obj/usr/src/riscv.riscv64sf/tmp/usr/lib/libc.a(gtdf2.o):/usr/src/lib/libc/s > > oftfloat/gtdf2.c:18: first defined here > > collect2: error: ld returned 1 exit status > > *** [nologin.full] Error code 1 > > As far as I know, it has been broken for quite some time. I guess for > riscv those functions need to be defined either in libc, or in > compiler-rt, but not both... > > -Dimitry > > From owner-freebsd-current@freebsd.org Sat Jun 30 01:02: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 BD2F1FDC87D for ; Sat, 30 Jun 2018 01:02:27 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-9.consmr.mail.gq1.yahoo.com (sonic316-9.consmr.mail.gq1.yahoo.com [98.137.69.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 39C7183B4B for ; Sat, 30 Jun 2018 01:02:27 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: gsWnNjkVM1mKsS8iC4u_UCrJvS3oP9r7JnvHfapCkT94oXxCQ2wJZqAnSKI.rA2 FD01zFi53MbNl2q_XyzCeztmmCOeX8xkU4JOkSEe_9bPe6L..BG2lRcbk5ejCZxDHGJl05cywAgm 28mc8rrGSjdHm9xDkwnNsa38KLV8Qt_6aaIIvHEaEJi6.tEgZenSjJl3dMWZ3mltIQac1uj4j2Z6 XKkGyBk5wRVctD.wPX_zIpQ6asOG0HwP4nGnmPQeh8AlRRfEiGe3S4ygqM4_wfy4CkvIFxIebi7Y 8QcRMF_7bBS_Fot9dbzbaCevD5pawmag2rIpxwVPz9rj38G0Jhn2FK10WeZto.6CPikrPjT71o6u 5zmIOvTG9M7LmkwfM8KnRq7.cW8BMW1EJBmmHSLLwM0.rGq3oGS9j98Or3wHETGz3D_BPWAxxHav Ud_F3xWowaDIHLKRbho0oyNghyLGV7_k_riFN_ThZGOr8lxYoLrliOb2HKJrXwvROIip_tZQ2mZ7 2qUZJ9Pqo_E.8ZvHFzy5tFq_FqL1WKRrujaQoSA.fQRaTjZ49x1YMqOMrK3_gmGM31.WWvCxB4si U5GUNIasJxFo1Shc.Pt2SnidJiT2.48IO245da7Si8wq1GVKr6YhrXpOWiirpCKY33SfgTIIHhxw ULaCsE9.CX2npMJYo5amLxSoF4DXxuRWApV3Yr.yLMfiVu3ncUK8LexiYBnJJ4EzlWSNM0BzviHR BY2ZzYiAyhM5lz.e0IFmR3gIBmwvTcsy21X96SWRWU6g3IwzBuB8ra4Buwbf.qV1QFQ3mVZjbCkI 72bHImslvu7bCeFJoHNwiryRYXIyb_75RQ3WdXMOym.1MpAHUjsC.Z_DcPGFd4WeZ2rpOF9Bfy1N pBGlEAtRmoBo8gMxKSvzGITF6mhKtThL9yJlvoZlp0yCRAmUreRfzLEE20sXCdOPgnmpcEkKBOgF P_7aVjbYzWkqkI_q4WNZjTsG1bwWOvw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Sat, 30 Jun 2018 01:02:20 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp420.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 10f15d5305dd862f0cfb450bf9eee85e; Sat, 30 Jun 2018 01:02:15 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build) From: Mark Millard In-Reply-To: <003509F0-F2F4-4A43-82FE-3F6FC23D19D4@yahoo.com> Date: Fri, 29 Jun 2018 18:02:13 -0700 Cc: Bryan Drewery , svn-src-head@freebsd.org, FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <3010D324-3852-4EFC-BC7C-E4A905A0F665@yahoo.com> 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> To: John Baldwin X-Mailer: Apple Mail (2.3445.8.2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 30 Jun 2018 01:02:28 -0000 On 2018-Jun-29, at 2:37 PM, Mark Millard wrote: > [I expect this is more than just amd64-gcc related but that is all > that ci.freebsd.org normally builds via a devel/*-gcc .] >=20 > On 2018-Jun-29, at 10:38 AM, John Baldwin wrote: >=20 >> On 6/28/18 7:54 PM, Mark Millard wrote: >>> On 2018-Jun-28, at 6:04 PM, Mark Millard = wrote: >>>=20 >>>> On 2018-Jun-28, at 5:39 PM, Mark Millard = wrote: >>>>=20 >>>> . . . >>>> Later below expand the failing and previoly good commands, one >>>> option per line. The summary of the distinction in content is >>>> a one line difference, the working example ( -r335773 )had the >>>> option: >>>>=20 >>>> -isystem = /workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/include >>>>=20 >>>> but the failing one did not. Working ( -r335773 ) is shown first. >>>>=20 >>>> --- catrigl.o --- >>>> /usr/local/bin/x86_64-unknown-freebsd11.1-gcc >>>> -DCOMPAT_32BIT >>>> -march=3Di686 >>>> -mmmx >>>> -msse >>>> -msse2 >>>> -m32 >>>> -L/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/lib32 >>>> --sysroot=3D/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp >>>> -B/usr/local/x86_64-unknown-freebsd11.1/bin/ >>>> -B/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/lib32 >>>> -isystem = /workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/include >>>> -O2 >>>> -pipe >>>> -I/workspace/src/lib/msun/x86 >>>> -I/workspace/src/lib/msun/ld80 >>>> -I/workspace/src/lib/msun/i387 >>>> -I/workspace/src/lib/msun/src >>>> -I/workspace/src/lib/libc/include >>>> -I/workspace/src/lib/libc/i386 >>>> . . . >>>>=20 >>>> --- catrigl.o --- >>>> /usr/local/bin/x86_64-unknown-freebsd11.1-gcc >>>> -DCOMPAT_32BIT >>>> -march=3Di686 >>>> -mmmx >>>> -msse >>>> -msse2 >>>> -m32 >>>> -L/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/lib32 >>>> --sysroot=3D/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp >>>> -B/usr/local/x86_64-unknown-freebsd11.1/bin/ >>>> -B/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/lib32 >>>> -O2 >>>> -pipe >>>> -I/workspace/src/lib/msun/x86 >>>> -I/workspace/src/lib/msun/ld80 >>>> -I/workspace/src/lib/msun/i387 >>>> -I/workspace/src/lib/msun/src >>>> -I/workspace/src/lib/libc/include=20 >>>> -I/workspace/src/lib/libc/i386 >>>> . . . >>>=20 >>>=20 >>> For the report: >>>=20 >>>> The xtoolchain GCC packages have not required these flags since = ports >>>> commits r465416 and r466701 >>>=20 >>> Looking at = https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6331/consoleText >>> there is: >>>=20 >>>> Updating FreeBSD repository catalogue... >>>> FreeBSD repository is up to date. >>>> All repositories are up to date. >>>> The following 6 package(s) will be affected (of 0 checked): >>>>=20 >>>> New packages to be INSTALLED: >>>> amd64-xtoolchain-gcc: 0.4_1 >>>> amd64-gcc: 6.4.0 >>>> mpfr: 4.0.1 >>>> gmp: 6.1.2 >>>> mpc: 1.1.0_1 >>>> amd64-binutils: 2.30_3,1 >>>=20 >>> and amd64-gcc being 6.4.0 (via powerpc64-gcc) is from -r466834 >>> (via looking up in https://svnweb.freebsd.org/ports/head/devel/ ). >>>=20 >>> This indicates that -r465416 and -r466701 did not cause: >>>=20 >>> --sysroot=3D/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp >>>=20 >>> to lead to include files being looked up in: >>>=20 >>> /workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/include >>>=20 >>> Thus there appears to still be a need for: >>>=20 >>> -isystem = /workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/include >>>=20 >>> unless more is done to the devel/*-gcc to make them look >>> in that additional place automatically (based on --sysroot). >>=20 >> --sysroot does work, and you can verify it by doing the following: >>=20 >> % touch empty.c >> % x86_64-unknown-freebsd11.2-gcc -c -v empty.c >> Using built-in specs. >> COLLECT_GCC=3Dx86_64-unknown-freebsd11.2-gcc >> Target: x86_64-unknown-freebsd11.2 >> ... >> ignoring nonexistent directory = "/usr/local/lib/gcc/x86_64-unknown-freebsd11.2/6.4.0/include-fixed" >> ignoring nonexistent directory = "/usr/local/lib/gcc/x86_64-unknown-freebsd11.2/6.4.0/../../../../x86_64-un= known-freebsd11.2/include" >> #include "..." search starts here: >> #include <...> search starts here: >> /usr/local/lib/gcc/x86_64-unknown-freebsd11.2/6.4.0/include >> /usr/include >> End of search list. >> ... >> % x86_64-unknown-freebsd11.2-gcc -c -v empty.c --sysroot=3D/foo >> Using built-in specs. >> COLLECT_GCC=3Dx86_64-unknown-freebsd11.2-gcc >> Target: x86_64-unknown-freebsd11.2 >> ... >> ignoring nonexistent directory = "/usr/local/lib/gcc/x86_64-unknown-freebsd11.2/6.4.0/include-fixed" >> ignoring nonexistent directory = "/usr/local/lib/gcc/x86_64-unknown-freebsd11.2/6.4.0/../../../../x86_64-un= known-freebsd11.2/include" >> ignoring nonexistent directory "/foo/usr/include" >> #include "..." search starts here: >> #include <...> search starts here: >> /usr/local/lib/gcc/x86_64-unknown-freebsd11.2/6.4.0/include >> End of search list. >>=20 >> I will see if I can reproduce the failure locally. >=20 > The: >=20 > ignoring nonexistent directory "/foo/usr/include" >=20 > means that the order of the search alternatives was not shown > ("search starts here"). That is what I expect is different. >=20 > It will take a while before I'll have a build from either > before or after the change to show a search order with. > (And longer to have both for comparison.) >=20 > My context is freebsd12.0 . My buildworld buildkernel > context has: >=20 > # more ~/src.configs/make.conf=20 > CFLAGS.gcc+=3D -v >=20 > so my script file for a build is very explicit about the > order. >=20 > I'll be starting from # uname -apKU > FreeBSD FBSDUSSD 12.0-CURRENT FreeBSD 12.0-CURRENT r335245M amd64 = amd64 1200069 1200069 >=20 Here is what head -r335245 got for my build . . . = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/li= b/msun/catrigl.o.meta shows: 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" ignoring duplicate directory = "/usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/t= mp/usr/include" #include "..." search starts here: #include <...> search starts here: /usr/src/lib/msun/x86 /usr/src/lib/msun/ld80 /usr/src/lib/msun/i387 /usr/src/lib/msun/src /usr/src/lib/libc/include /usr/src/lib/libc/i386 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tm= p/usr/include /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include End of search list. It will be some time before I have an attempted build of -r335782 or later to compare such with. But the above found FreeBSD's: # ls -lT = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tm= p/usr/include/float.h=20 lrwxr-xr-x 1 root wheel 15 Jun 29 16:27:34 2018 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tm= p/usr/include/float.h -> machine/float.h # ls -lT = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tm= p/usr/include/machine/float.h -rwxr-xr-x 1 root wheel 151 Nov 3 02:27:25 2016 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tm= p/usr/include/machine/float.h instead of: # ls -lT = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/float.h=20 -rw-r--r-- 1 root wheel 8729 May 26 05:05:37 2018 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/float.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 Sat Jun 30 01:20: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 6F53AFDDD18; Sat, 30 Jun 2018 01:20:00 +0000 (UTC) (envelope-from rlibby@gmail.com) Received: from mail-pg0-f51.google.com (mail-pg0-f51.google.com [74.125.83.51]) (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 E197E84974; Sat, 30 Jun 2018 01:19:59 +0000 (UTC) (envelope-from rlibby@gmail.com) Received: by mail-pg0-f51.google.com with SMTP id n15-v6so1444004pgv.4; Fri, 29 Jun 2018 18:19:59 -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:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eD7t1Z8opqcesVGKuPnig4TspTzTJ1Q6Rp1EReGaQCc=; b=A7eEKUHS5XYkDxKSykSLgOba2lcUqDnJaKuzOE9lNYsrg+cKL0udzUkrpVn7Sn8aXK r/qRF0wfiLmkYQXvS/KC9Md/TUH26zOKgkAj7VZ7s+SsSfaP3GTXZ7kYahnLtusgQKNc QZVdPZyr+7s/AvJc5o14CIDAhzhgUNvK+YBnJIA6L4QmxE3KPOAsDiUttzkG1R59dOdK o748yRs8+sHL79H+pZRR+JSTV0JP5YjoljnFcGPxIkR7+d0Zsx6YgsXy1WHgVQVdXzPq UMoxuehVMPURTMh6lk/RViGZpkYydrMBAVDeD+48DdV9GyWkh0fy0sjNFUu+IcerJidR Pb/Q== X-Gm-Message-State: APt69E28q6WV8IjJPUlOHWN5KXJfs3jpayNTKKjdjUTu+cf8dS987zwl RG00qHlQA196KkA/C/4wIBuyC2+28C0= X-Google-Smtp-Source: AAOMgpeP2E5m4ufls7DjSaLQDZwqCk/GM9vsjUnNdwJuOQkuUQEAoPhNMdIg9+Vy2sA1944Obs22DQ== X-Received: by 2002:a62:930c:: with SMTP id b12-v6mr16365461pfe.193.1530317437783; Fri, 29 Jun 2018 17:10:37 -0700 (PDT) Received: from mail-pl0-f54.google.com (mail-pl0-f54.google.com. [209.85.160.54]) by smtp.gmail.com with ESMTPSA id 15-v6sm16937509pfq.81.2018.06.29.17.10.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Jun 2018 17:10:37 -0700 (PDT) Received: by mail-pl0-f54.google.com with SMTP id 30-v6so5167572pld.13; Fri, 29 Jun 2018 17:10:37 -0700 (PDT) X-Received: by 2002:a17:902:8d91:: with SMTP id v17-v6mr17117928plo.9.1530317437496; Fri, 29 Jun 2018 17:10:37 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:1581:0:0:0:0 with HTTP; Fri, 29 Jun 2018 17:10:36 -0700 (PDT) In-Reply-To: References: <00D1127A-1F0E-4E0E-B86C-1C5AA5B2E085@yahoo.com> <7A845F2C-C994-4828-823D-33A97B7B6EB0@yahoo.com> From: Ryan Libby Date: Fri, 29 Jun 2018 17:10:36 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build) To: John Baldwin Cc: Mark Millard , Bryan Drewery , svn-src-head@freebsd.org, FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 30 Jun 2018 01:20:00 -0000 [Re-sending from my subscription address, sorry for the spam] On Fri, Jun 29, 2018 at 1:26 PM, John Baldwin wrote: > On 6/28/18 7:54 PM, Mark Millard wrote: >> On 2018-Jun-28, at 6:04 PM, Mark Millard wrote: >> >>> On 2018-Jun-28, at 5:39 PM, Mark Millard wrote: >>> >>>> [ ci.free.bsd.org jumped from -r335773 (built) to -r335784 (failed) >>>> for FreeBSD-head-amd64-gcc. It looked to me like the most likely >>>> breaking-change was the following but I've not tried personal >>>> builds to confirm. >>>> ] > > So this is a bit complicated and I'm not sure what the correct fix is. > > What is happening is that the shipped with GCC is now being used > after this change instead of sys/x86/include/float.h. A sledgehammer approach > would be to remove float.h from the GCC package (we currently don't install > the float.h for the base system clang either). However, looking at this > in more detail, it seems that x86/include/float.h is also busted in some > ways. > > First, the #error I don't understand how it is happening. The GCC float.h > defines LDBL_MAX_EXP to the __LDBL_MAX_EXP__ builtin which is 16384 just > like the x86 float.h: > > # x86_64-unknown-freebsd12.0-gcc -dM -E empty.c -m32 | grep LDBL_MAX_EXP > #define __LDBL_MAX_EXP__ 16384 > > I even hacked catrigl.c to add the following lines before the #error > check: > > LDBL_MAX_EXP_ = LDBL_MAX_EXP > LDBL_MANT_DIG_ = LDBL_MANT_DIG > > #if LDBL_MAX_EXP != 0x4000 > #error "Unsupported long double format" > #endif > > And the -E output is: > > DBL_MAX_EXP_ = 16384 > LDBL_MANT_DIG_ = 53 > > # 51 "/zoo/jhb/zoo/jhb/git/freebsd/lib/msun/src/catrigl.c:93:2: error: #error "U > nsupported long double format" > #error "Unsupported long double format" > ^~~~~ > > Yet clearly, 16384 == 0x4000 assuming it is doing a numeric comparison (which > it must be since the x86 float.h uses '16384' not '0x4000' as the value). > Isn't this just the unsupported LDBL_MANT_DIG you're hitting here? Note line 93. I reused the same error message for LDBL_MAX_EXP :/ > However, LDBL_MANT_DIG of 53 is a bit more fun. We have a comment about the > initial FPU control word in sys/amd64/include/fpu.h that reads thus: > > /* > * The hardware default control word for i387's and later coprocessors is > * 0x37F, giving: > * > * round to nearest > * 64-bit precision > * all exceptions masked. > * > * FreeBSD/i386 uses 53 bit precision for things like fadd/fsub/fsqrt etc > * because of the difference between memory and fpu register stack arguments. > * If its using an intermediate fpu register, it has 80/64 bits to work > * with. If it uses memory, it has 64/53 bits to work with. However, > * gcc is aware of this and goes to a fair bit of trouble to make the > * best use of it. > * > * This is mostly academic for AMD64, because the ABI prefers the use > * SSE2 based math. For FreeBSD/amd64, we go with the default settings. > */ > #define __INITIAL_FPUCW__ 0x037F > #define __INITIAL_FPUCW_I386__ 0x127F > #define __INITIAL_NPXCW__ __INITIAL_FPUCW_I386__ > #define __INITIAL_MXCSR__ 0x1F80 > #define __INITIAL_MXCSR_MASK__ 0xFFBF > > GCC is indeed aware of this in gcc/config/i386/freebsd.h which results in > __LDBL_MANT_DIG__ being set to 53 instead of 64: > > /* FreeBSD sets the rounding precision of the FPU to 53 bits. Let the > compiler get the contents of and std::numeric_limits correct. */ > #undef TARGET_96_ROUND_53_LONG_DOUBLE > #define TARGET_96_ROUND_53_LONG_DOUBLE (!TARGET_64BIT) > > clang seems unaware of this as it reports all the same values for > LDBL_MIN/MAX for both amd64 and i386 (values that match GCC for amd64 > but not i386): > > # cc -dM -E empty.c | egrep 'LDBL_(MIN|MAX)__' > #define __LDBL_MAX__ 1.18973149535723176502e+4932L > #define __LDBL_MIN__ 3.36210314311209350626e-4932L > # cc -dM -E empty.c -m32 | egrep 'LDBL_(MIN|MAX)__' > #define __LDBL_MAX__ 1.18973149535723176502e+4932L > #define __LDBL_MIN__ 3.36210314311209350626e-4932L > # x86_64-unknown-freebsd12.0-gcc -dM -E empty.c | egrep 'LDBL_(MIN|MAX)__' > #define __LDBL_MAX__ 1.18973149535723176502e+4932L > #define __LDBL_MIN__ 3.36210314311209350626e-4932L > # x86_64-unknown-freebsd12.0-gcc -dM -E empty.c -m32 | egrep 'LDBL_(MIN|MAX)__' > #define __LDBL_MAX__ 1.1897314953572316e+4932L > #define __LDBL_MIN__ 3.3621031431120935e-4932L > > The x86/include/float.h header though reports the MIN/MAX values somewhere > in between the two ranges for both amd64 and i386 while reporting an > LDBL_MANT_DIG of 64: > > #define LDBL_MANT_DIG 64 > #define LDBL_MIN 3.3621031431120935063E-4932L > #define LDBL_MAX 1.1897314953572317650E+4932L > > I guess for now I will remove float.h from the amd64-gcc pkg-plist, but we > should really be fixing our tree to work with compiler-provided language > headers when at all possible. It's not clear to me if amd64 should be > using the compiler provided values of things like LDBL_MIN/MAX either btw. > > -- > John Baldwin > _______________________________________________ > 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" The whole situation is a little messed up. LDBL_MAX, LDBL_MIN, and LDBL_MANT_DIG are IMHO broken by design, because they are just the defaults. User code can change the mode, and then the constants necessarily yield weird things, like max - epsilon becoming infinity, or not actually being the maximum possible finite value. It's difficult for code to use them correctly--which was why I removed references to LDBL_MAX in [1]. Some general background on that aspect here [2]. [1] https://svnweb.freebsd.org/base?view=revision&revision=323003 [2] https://lists.freebsd.org/pipermail/freebsd-numerics/2012-September/000288.html From owner-freebsd-current@freebsd.org Sat Jun 30 02:33:16 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 D8458FE2D1D for ; Sat, 30 Jun 2018 02:33:15 +0000 (UTC) (envelope-from mmitchel@gmail.com) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::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 6F074887A5 for ; Sat, 30 Jun 2018 02:33:15 +0000 (UTC) (envelope-from mmitchel@gmail.com) Received: by mail-qt0-x235.google.com with SMTP id h5-v6so9550213qtm.13 for ; Fri, 29 Jun 2018 19:33:15 -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=zF29zLvPv92Sll5PWA/0i47XVMDFc/yFY/WuL1T7UA4=; b=GFJ2R/QGzmrrkye7cPHq/az+jIcgCTNXLWUJcZDivT9W9civG7a4ZZ2kCbVZc88B3L ASu8MhDZSimjhVyndhXNHQzvuidinRYCiuX8xGs9DGSbJJLMTybcJpGeJB9nFEiUBea8 dd2W4SDnYldst4SzAU7U6dLOuz0ZaBceXAWA5t+6AQkPwvn2IhBDGQpnchU8//eS15Ro S51Mz9ZYwKlDG7L82PDqmoMXZSRP/7ZdkfxJ63vcJTLrwF6jhriUCsnUUd2mAZtW0JoN X62EsdKA2cWT2v5KLvVVjo9u9LBMQ8tLIYRXwjAe/obTkEPbKp67bVZCp/2ihFqjnJIj qrbw== 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=zF29zLvPv92Sll5PWA/0i47XVMDFc/yFY/WuL1T7UA4=; b=aO6bh2HMUm1qj2VVj0sgbA7Tgr7fh+euWgdZOnHDSWHMhNZN1iKWrH3etuCWL5x8ax L+hHYSWZBz9DdDcjq/gtpCkb6BnMjdzNuwWsLbfw+z4OEkIdZaAswDIm6fJCrE5M5+yP t+VT/20Mzcs/T0icne/Aa34I7GEBIqRHmaMH0LV9euDXl+/RHXgxTXtwFyXNPWBhIqfF ma8wqTiK3i3nOtBQoSQ8LccPeDvb9HJ5ezHjnBBsL+6BGVmZxBh7A4f1dSJxM+oAFYN3 73v2FU4eLMaO/+H2Pb/6mb3g2J6yWPwgkCL402Ly3q+S/PUuqHYP/pGfqlPV3Vxpx6ia k8sQ== X-Gm-Message-State: APt69E2ESsw84WXh252Xln95wDMyIDlGhc/NnBK8wvdJX3QJT02hZkff X0hm0WGdS3RDyHQfqfa6d2aoCHtpKnv4yzZPEl3Uhwzf6g== X-Google-Smtp-Source: AAOMgpd889tvqkKs+yY9X1L4ZJGPLqcDbZGgt0u2JAOcdp50aWHcTIt40/Y8kWbrV3MkDpi5EYpywE0ST8X0ydFlQPw= X-Received: by 2002:a0c:d8e8:: with SMTP id w37-v6mr15251633qvj.111.1530325994724; Fri, 29 Jun 2018 19:33:14 -0700 (PDT) MIME-Version: 1.0 References: <20180630020321.6mpusxvbn7fpy64y@ler-imac.local> In-Reply-To: <20180630020321.6mpusxvbn7fpy64y@ler-imac.local> From: Michael Mitchell Date: Fri, 29 Jun 2018 19:33:02 -0700 Message-ID: Subject: Re: DNSSEC/Log Spam for partially DNSSEC domain To: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 30 Jun 2018 02:33:16 -0000 /etc/syslog.conf maybe mdm - from a phone On Fri, Jun 29, 2018, 7:27 PM Larry Rosenman wrote: > I'm running Exim, with DNSSEC enabled, and my zone (lerctr.org) is > DNSSEC signed, but my dyn.lerctr.org subdomain is NOT DNSSEC signed due > to HE.net don't support DNSSEC. > > I get a ton of: > Jun 29 20:12:53 thebighonker exim[37649]: gethostby*.gethostanswer: asked > for "borg.lerctr.org IN AAAA", got type "RRSIG" > Jun 29 20:12:53 thebighonker exim[37649]: gethostby*.gethostanswer: asked > for "borg.lerctr.org IN A", got type "RRSIG" > > in my logs, which comes from libc: > /usr/src/lib/libc/net/getaddrinfo.c: > 2092 #ifdef DEBUG > 2093 if (type != T_KEY && type != T_SIG && > 2094 type != ns_t_dname) > 2095 syslog(LOG_NOTICE|LOG_AUTH, > 2096 "gethostby*.getanswer: asked for \"%s %s %s\", got > type \"%s\"", > 2097 qname, p_class(C_IN), > p_type(qtype), > 2098 p_type(type)); > 2099 #endif > > Is there an easy way to make this quieter? > > > > > -- > Larry Rosenman https://people.FreeBSD.org/~ler/ > Phone: +1 214-642-9640 E-Mail: ler@FreeBSD.org > US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106 > From owner-freebsd-current@freebsd.org Sat Jun 30 02:03:23 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 AA315FE0B5E for ; Sat, 30 Jun 2018 02:03:23 +0000 (UTC) (envelope-from ler@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5290D86726 for ; Sat, 30 Jun 2018 02:03:23 +0000 (UTC) (envelope-from ler@FreeBSD.org) Received: from ler-imac.local (unknown [IPv6:2600:1700:210:b18f:64b5:3a22:e800:a09]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: ler/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id ED2EC14976 for ; Sat, 30 Jun 2018 02:03:22 +0000 (UTC) (envelope-from ler@FreeBSD.org) Date: Fri, 29 Jun 2018 21:03:21 -0500 From: Larry Rosenman To: freebsd-current@FreeBSD.org Subject: DNSSEC/Log Spam for partially DNSSEC domain Message-ID: <20180630020321.6mpusxvbn7fpy64y@ler-imac.local> Mail-Followup-To: freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="2u6hhgvfwux2alpb" Content-Disposition: inline User-Agent: NeoMutt/20180622 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 30 Jun 2018 02:03:23 -0000 --2u6hhgvfwux2alpb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I'm running Exim, with DNSSEC enabled, and my zone (lerctr.org) is DNSSEC signed, but my dyn.lerctr.org subdomain is NOT DNSSEC signed due to HE.net don't support DNSSEC.=20 I get a ton of: Jun 29 20:12:53 thebighonker exim[37649]: gethostby*.gethostanswer: asked f= or "borg.lerctr.org IN AAAA", got type "RRSIG" Jun 29 20:12:53 thebighonker exim[37649]: gethostby*.gethostanswer: asked f= or "borg.lerctr.org IN A", got type "RRSIG" in my logs, which comes from libc: /usr/src/lib/libc/net/getaddrinfo.c: 2092 #ifdef DEBUG 2093 if (type !=3D T_KEY && type !=3D T_SIG && 2094 type !=3D ns_t_dname) 2095 syslog(LOG_NOTICE|LOG_AUTH, 2096 "gethostby*.getanswer: asked for \"%s %s %s\", got t= ype \"%s\"", 2097 qname, p_class(C_IN), p_type= (qtype), 2098 p_type(type)); 2099 #endif Is there an easy way to make this quieter? --=20 Larry Rosenman https://people.FreeBSD.org/~ler/ Phone: +1 214-642-9640 E-Mail: ler@FreeBSD.org US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106 --2u6hhgvfwux2alpb Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQHBBAABCgCrFiEEHjgknedhWzvJgwVzaXyZsatIp30FAls25OktFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3JnbGVyQEZyZWVCU0Qub3JnXxSAAAAAAC4AKGlz c3Vlci1mcHJAbm90YXRpb25zLm9wZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxRTM4 MjQ5REU3NjE1QjNCQzk4MzA1NzM2OTdDOTlCMUFCNDhBNzdEAAoJEGl8mbGrSKd9 2PQH/1HW88eh+eqANVcwhL7L7PGrJRhk3IAS4UTWclsHYrmtbwzLgMmBpg01009S OyHe88mTpe5GU0Ywxt/3opBz4qeElO6NI5JnFkKL8GWG6/jtLOztgWQlfQC5EXLy f/AXMezEDUHSEY8biME44q0n+udsyVBxLafOpnxyt+jNrcjfNNqoC4NpyvE03YCw vbhdUNBUVuuvlZFru8gwFtFYIvcNCIQj9tnAOhdt9Vf+xHZH2pHfVZtaJ1pJ6OOM TOb54EixaFAzn992KqoiR3hnCO7yWa1KsspCNQBgXaCHrc53IhrSddZQtEJYDsOv aeTJ2YuQlnSbYp4isKRWEj15Dx0= =OzIT -----END PGP SIGNATURE----- --2u6hhgvfwux2alpb-- From owner-freebsd-current@freebsd.org Sat Jun 30 03:30: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 1B586FE5D7E for ; Sat, 30 Jun 2018 03:30:02 +0000 (UTC) (envelope-from mmitchel@gmail.com) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::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 B14488AA1C for ; Sat, 30 Jun 2018 03:30:01 +0000 (UTC) (envelope-from mmitchel@gmail.com) Received: by mail-qt0-x233.google.com with SMTP id s47-v6so9625900qth.7 for ; Fri, 29 Jun 2018 20:30:01 -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=CpKk43hbXlFFJsC2ayhdjo9QgaK+W8WbuTDr4M45d9A=; b=l3wdKKuXGtUPZIx00KhGO4p3YdkZ6HN8FOp1cdxATdOO1QwzwSIKnd4kJD9mU99GeQ isC223CfVeQS4Jxi+nXeciBQ7Y2o04p20ISovDFdQzeIvjtLYGeDQn1+ru03/yfOqscl EkiMqtDZCwCAKIgVZiXZDWCCqy3O96natnvxFrSKlvnBzQ/WRcfeh2wRoy6omlvW9PTU 9Z9FURnGZYSilK+VEihtZylA7OwHqyNepiYjyBatpl9n64pIX13v1WFoDYA8G8bCmf6f lR6WiWuo7aFLnQIssy2TgT1HPPFBh4jkiznJjeJIqxQSHAfoy/xdq6Y/RsnQjoG7xC8q um7w== 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=CpKk43hbXlFFJsC2ayhdjo9QgaK+W8WbuTDr4M45d9A=; b=NdkUAKt8KgBUqzqXhphCcGphm6qovrQLQdhOA4UBgIclDeSHGxy7L6fDSqCzFXrzKx ecZthwl+Jp6MHwISBCqiUOLmWoRFJ+qD9B4odF99nyE4PtqY5twPHAUhF7Qe/odaEqT6 bLFKxYXsi0L2gMhUTyXT/+KaJ/7mgC+JiHYbXiYWsmhp1U1Su4oHUcu2LQFsb+tXpEFI mfL4HGW7WQI97CCZvHMYNqCuC9NFwTyhec49F3pdMI/5P4lya+UJruID6aM0ISE+MG7S Pn8KfYa+qoqGBFmQ8cMF7B/PXSIxfH38HlItfIqqYv0nwzVccDmoB8+cxG0VbrgpWa04 AS5Q== X-Gm-Message-State: APt69E0kqWRk40KsWtriNLwriQwgB5+iHOz9A2ymUOU/RFwL0WJrwR4G LgeOtALfe4fHMlEqchoO+/SzR3epkcYLsMOr/WmOZbRTYw== X-Google-Smtp-Source: AAOMgpcrotjdpMR5A389IcUOQ+O8TixiD3lM93ApsOSNC7znI9LRgio+hXmWy2xddvdpcP5HWwhYL7d6jn2aEhCPQa8= X-Received: by 2002:a0c:9a02:: with SMTP id p2-v6mr15560326qvd.184.1530329400911; Fri, 29 Jun 2018 20:30:00 -0700 (PDT) MIME-Version: 1.0 References: <20180630020321.6mpusxvbn7fpy64y@ler-imac.local> <20180630030032.knc2zx6b4zt7uc4a@ler-imac.local> In-Reply-To: <20180630030032.knc2zx6b4zt7uc4a@ler-imac.local> From: Michael Mitchell Date: Fri, 29 Jun 2018 20:29:48 -0700 Message-ID: Subject: Re: DNSSEC/Log Spam for partially DNSSEC domain To: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 30 Jun 2018 03:30:02 -0000 pick the right options for the daemon and info level? mdm - from a phone On Fri, Jun 29, 2018, 8:00 PM Larry Rosenman wrote: > On Fri, Jun 29, 2018 at 07:33:02PM -0700, Michael Mitchell wrote: > > /etc/syslog.conf maybe > > > > mdm - from a phone > > > That won't help, as I don't want to suppress ALL of the nastygrams. > > I'm looking for more selectivity from this in libc. > > > -- > Larry Rosenman http://www.lerctr.org/~ler > Phone: +1 214-642-9640 E-Mail: ler@lerctr.org > US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106 > From owner-freebsd-current@freebsd.org Sat Jun 30 03:00: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 B6521FE44CC for ; Sat, 30 Jun 2018 03:00:35 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:bb:dcff:fe50:d900]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.lerctr.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 59BBD89515 for ; Sat, 30 Jun 2018 03:00:35 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=E5mxLPajEUmNxnlZqRVQC7HCoPd02yVlZChU1IbV/rw=; b=lmDzwxX3xA95clG+kwwhQCW8Gn tanm47A9rmD6WcYPY5/i9Ujeu/g//MUwMnm/aL6FJO3u2JXNSnVmTIZ0uwuf5Fv8KHGK3DY52zQm5 DdOAzDDy/ofdydnrBOiqFLpW1zaHyBCn+yJX47C6dFZM89rQx1Gys9v02NbN3iWxB8RY=; Received: from [2600:1700:210:b18f:64b5:3a22:e800:a09] (port=63685 helo=ler-imac.local) by thebighonker.lerctr.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91 (FreeBSD)) (envelope-from ) id 1fZ67l-000BO2-GT; Fri, 29 Jun 2018 22:00:33 -0500 Date: Fri, 29 Jun 2018 22:00:32 -0500 From: Larry Rosenman To: Michael Mitchell Cc: freebsd-current@freebsd.org Subject: Re: DNSSEC/Log Spam for partially DNSSEC domain Message-ID: <20180630030032.knc2zx6b4zt7uc4a@ler-imac.local> Mail-Followup-To: Michael Mitchell , freebsd-current@freebsd.org References: <20180630020321.6mpusxvbn7fpy64y@ler-imac.local> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="fvpj67tjphumuzuw" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180622 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 30 Jun 2018 03:00:35 -0000 --fvpj67tjphumuzuw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 29, 2018 at 07:33:02PM -0700, Michael Mitchell wrote: > /etc/syslog.conf maybe >=20 > mdm - from a phone >=20 That won't help, as I don't want to suppress ALL of the nastygrams. I'm looking for more selectivity from this in libc. --=20 Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106 --fvpj67tjphumuzuw Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQHABAABCgCqFiEEHjgknedhWzvJgwVzaXyZsatIp30FAls28lAsFIAAAAAAFQAO cGthLWFkZHJlc3NAZ251cGcub3JnbGVyQGxlcmN0ci5vcmdfFIAAAAAALgAoaXNz dWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDFFMzgy NDlERTc2MTVCM0JDOTgzMDU3MzY5N0M5OUIxQUI0OEE3N0QACgkQaXyZsatIp31m 7wgAszcDPpQQ7uS6ElpAvRD3dD/6MFMbhe8SNv3WRj7ImvGzoHJJfj57tx1SMpyq aX4odJUZQdt+MqQN+5TtcrX6fH+30Zcw8DGdWHfqZ3Y58cGttD4xjaqagw2kEar+ w3Kzp8u+EJYoMfM+C0jPCQ0JbuskWm++zAdcucZF7SJdsfFrN+ba5aggiN2/Xinb J0Bl/wOAEoua2s1sR2cZaasZezVKuw3mpHMhejgohdK5sBiADd+66Mv6r2u9K73W buFLz/baB71inwM6U0PKXFeXuV006xZQI7FsuVC180LxwPYbof/TX9QDyuO7xvnO jdLSUr6FWG+cASd3IobrAYxjgw== =ExgG -----END PGP SIGNATURE----- --fvpj67tjphumuzuw-- From owner-freebsd-current@freebsd.org Sat Jun 30 04:06: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 66A761001608 for ; Sat, 30 Jun 2018 04:06:06 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:bb:dcff:fe50:d900]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.lerctr.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 06EDB8C359 for ; Sat, 30 Jun 2018 04:06:05 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=KiZEcuhpRSSaZ9WwcirJHK6apEA/ck6ysx89dx2ua+4=; b=MT7eUK8Duf4d5c/2u2IGepIAob 6rAyACAmk8nX99/8Brpxl4dxNbVAhszY4FYTT+ML37IkJ4Wc3DbGzJZ2fJwAP6HRy7HLtbsrvMMqZ 0E8a1jKb73CtdHh3N7muprv5+dGV2u5VMUb+lUn2QCW5JEsLJjKitbKXXLau+KocJF74=; Received: from [2600:1700:210:b18f:64b5:3a22:e800:a09] (port=51344 helo=ler-imac.local) by thebighonker.lerctr.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91 (FreeBSD)) (envelope-from ) id 1fZ79A-000CgD-PF; Fri, 29 Jun 2018 23:06:04 -0500 Date: Fri, 29 Jun 2018 23:06:04 -0500 From: Larry Rosenman To: Michael Mitchell Cc: freebsd-current@freebsd.org Subject: Re: DNSSEC/Log Spam for partially DNSSEC domain Message-ID: <20180630040604.pm3li64v4bwtrbo3@ler-imac.local> Mail-Followup-To: Michael Mitchell , freebsd-current@freebsd.org References: <20180630020321.6mpusxvbn7fpy64y@ler-imac.local> <20180630030032.knc2zx6b4zt7uc4a@ler-imac.local> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="vz2dyev5p5sd6zua" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180622 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 30 Jun 2018 04:06:06 -0000 --vz2dyev5p5sd6zua Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 29, 2018 at 08:29:48PM -0700, Michael Mitchell wrote: > pick the right options for the daemon and info level? Nope, it's just this message which is annoying. --=20 Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106 --vz2dyev5p5sd6zua Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQHABAABCgCqFiEEHjgknedhWzvJgwVzaXyZsatIp30FAls3AawsFIAAAAAAFQAO cGthLWFkZHJlc3NAZ251cGcub3JnbGVyQGxlcmN0ci5vcmdfFIAAAAAALgAoaXNz dWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDFFMzgy NDlERTc2MTVCM0JDOTgzMDU3MzY5N0M5OUIxQUI0OEE3N0QACgkQaXyZsatIp33Y IQf+IVQqb5J6LD9fSzAPkoZs533GhohfNc37ohseh4LutplEiavMq+O0Rm2T0tpX oI/1Gol4uYaPfTItL0QHzV6bNje7kps/rYDTmCabh5cpDq3SEZfSTbjjsn9xGDAm xvncU0GW2mTl85ljTTyI3F9MuI9Y/Uq0u/Ps/dw6taomEzAtqhJ95QYKLgomuXBL vfObp2VLTrswkzttynnPaW/0rOhgg+QdEX0+1KLX1pPjVH8/xvHl+dzDovX4RyRh nSOCTKW2kPlQXFrfIQIEWhTQR97VmHGPVTO6Ls0BSbvuPjhKFx48zHMZq5YmF8C4 X1GN9L7M+nFizhzWrFXEcIcHMg== =BnPd -----END PGP SIGNATURE----- --vz2dyev5p5sd6zua-- From owner-freebsd-current@freebsd.org Sat Jun 30 09:33: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 E8EDF102715A for ; Sat, 30 Jun 2018 09:33:24 +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 A66BA76806; Sat, 30 Jun 2018 09:33:24 +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 0CCB4D59C; Sat, 30 Jun 2018 11:33:23 +0200 (CEST) From: Dimitry Andric Message-Id: <9A9BEA31-1677-4F5D-A987-40B0E50EE9BF@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_F1DB7737-B20D-4030-B13A-9EE8AD20DFAC"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: DNSSEC/Log Spam for partially DNSSEC domain Date: Sat, 30 Jun 2018 11:33:19 +0200 In-Reply-To: <20180630020321.6mpusxvbn7fpy64y@ler-imac.local> Cc: freebsd-current@FreeBSD.org To: Larry Rosenman References: <20180630020321.6mpusxvbn7fpy64y@ler-imac.local> X-Mailer: Apple Mail (2.3445.8.2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 30 Jun 2018 09:33:25 -0000 --Apple-Mail=_F1DB7737-B20D-4030-B13A-9EE8AD20DFAC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 30 Jun 2018, at 04:03, Larry Rosenman wrote: >=20 > I'm running Exim, with DNSSEC enabled, and my zone (lerctr.org) is > DNSSEC signed, but my dyn.lerctr.org subdomain is NOT DNSSEC signed = due > to HE.net don't support DNSSEC. >=20 > I get a ton of: > Jun 29 20:12:53 thebighonker exim[37649]: gethostby*.gethostanswer: = asked for "borg.lerctr.org IN AAAA", got type "RRSIG" > Jun 29 20:12:53 thebighonker exim[37649]: gethostby*.gethostanswer: = asked for "borg.lerctr.org IN A", got type "RRSIG" >=20 > in my logs, which comes from libc: > /usr/src/lib/libc/net/getaddrinfo.c: > 2092 #ifdef DEBUG > 2093 if (type !=3D T_KEY && type !=3D T_SIG = && > 2094 type !=3D ns_t_dname) > 2095 syslog(LOG_NOTICE|LOG_AUTH, > 2096 "gethostby*.getanswer: asked for \"%s %s %s\", = got type \"%s\"", > 2097 qname, p_class(C_IN), = p_type(qtype), > 2098 p_type(type)); > 2099 #endif >=20 > Is there an easy way to make this quieter? I see this code is only included if DEBUG is defined. Maybe undefine DEBUG, for this particular file? Or hack it so it has #undef DEBUG at the top? That said, I'm not sure if debug messages like this should be enabled by default, and impossible to squelch without recompiling libc. So maybe we should #if 0 it, instead. -Dimitry --Apple-Mail=_F1DB7737-B20D-4030-B13A-9EE8AD20DFAC 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 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCWzdOXwAKCRCwXqMKLiCW owNVAJ9+KRFGTEUzXoqWjs02s/T6BUFJGACePKTGB+GRDQQVw8CDQUm30msidgw= =iJsz -----END PGP SIGNATURE----- --Apple-Mail=_F1DB7737-B20D-4030-B13A-9EE8AD20DFAC-- From owner-freebsd-current@freebsd.org Sat Jun 30 13:22: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 A4890102FEAA for ; Sat, 30 Jun 2018 13:22:34 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-8.consmr.mail.gq1.yahoo.com (sonic307-8.consmr.mail.gq1.yahoo.com [98.137.64.32]) (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 2C32D7D9E8 for ; Sat, 30 Jun 2018 13:22:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: OxQmL2EVM1mCriugJK3j36WMW7l4ylh0m6lA1LVhSLrrnyBh1mtt8DMOWfa_MEq fHZJBEg3EEQjS5v8Tn6iFzO.lxMKBwlzFdWjDx6jU_eExr.hLHB4CeOGUYn7_zgQtp_krTgWbJO. Sfccqf32sj33pH38MVY62e7pbYdXauP2cMnAxaWlCcldf9dEqMRCSgu.YkU.Ei36PYwiW7BKiTDS j04FVarFHzoM7UrpNq7BhcGIzz1qQIWJItBJjCGfUdz2W4xgLwH9K_0IbProbneBhvp431OKvlEk YpKExiG_g6cFL1oEDu1RQ0MS6tstmPV4uw8dpqYTFfZKFWI5cM7tm93NBffIGWc9SQxLdoRvaCmP dcgJzmsWnQqzeV4GcWQlfVT_yI5wiAU9Ys1ebG0rNLkmmGH7yPcd_mydyhIiBK6gk7K2cLdEV204 nyqRBJFzB7xy6Ax76XI_.quZZajlFAP1A__BpTYbQ8H1KC80Eg6uQk6pl7QsCw8iS3H83cOs15oQ F51rG78m9y1NzWUiW6imIk85VLKesPJLM7eZD1f_a09AC8lgrBBivCyuf9NBgttZ1ql_zTVhv9Ms ZA6YFpMhfsiPKPG_uiwwSaPnkOEZCBg5av4_rpOP64.CvJeq8BxnPJWpllWcz8dD.Nzm5QqsExh3 Bxa0SwUP7MZFU2IBk6VHE3I9v6aUXxWsH1KfG52RzJyqJeNoDl8rISVd44hjW8nmCdFf6bZyBbFU NXrsvRzzabJn4.fGFcvOFHssIij..MArK.ZrvtozbFalq70.ALpgnB6rDUoqqbWYkFoBlV9H4blu JrrDFwSUJ_Jd02gldK_DsDCCsMg6iCdY2GSq7yhChz5M.nDertkhad_U.dioyA8Tg2ipxWhQ4PyT NkIBt4CWwWWvCWDSZeh7vb_jMKBsqnhZjeQ..faGS.t0.ROCxsOxGbwwfLGiySQAEcU39bf2LAmC 4bE6jS9KRH75AtuTSYz1OFmA- Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Sat, 30 Jun 2018 13:22:27 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp407.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID f17f94342df0209c6deaf38635825644; Sat, 30 Jun 2018 13:22:26 +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.4 \(3445.8.2\)) Subject: Re: svn commit: r335813 [ broke ci.freebsd.org 's FreeBSD-head-{aarch64,amd64,i386}-build ] Message-Id: <84175A6B-B159-4320-95FD-C5BC7F3B4C96@yahoo.com> Date: Sat, 30 Jun 2018 06:22:25 -0700 To: Dimitry Andric , svn-src-head@freebsd.org, FreeBSD Current X-Mailer: Apple Mail (2.3445.8.2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 30 Jun 2018 13:22:34 -0000 https://ci.freebsd.org/job/FreeBSD-head-aarch64-build/8358/consoleText --- all_subdir_armv8crypto --- /usr/src/sys/crypto/armv8/armv8_crypto_wrap.c:46:10: fatal error: = 'arm_neon.h' file not found #include ^~~~~~~~~~~~ 1 error generated. *** [armv8_crypto_wrap.o] Error code 1 https://ci.freebsd.org/job/FreeBSD-head-amd64-build/9268/consoleText --- lib/liblzma__L --- 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. *** [lz_encoder.o] Error code 1 https://ci.freebsd.org/job/FreeBSD-head-i386-build/8370/consoleText --- aesni_ghash.o --- cc -target i386-unknown-freebsd12.0 = --sysroot=3D/usr/obj/usr/src/i386.i386/tmp = -B/usr/obj/usr/src/i386.i386/tmp/usr/bin -c -O3 -pipe = -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE = -DHAVE_KERNEL_OPTION_HEADERS -include = /usr/obj/usr/src/i386.i386/sys/GENERIC/opt_global.h -I. -I/usr/src/sys = -I/usr/src/sys/contrib/ck/include -fno-common -g = -I/usr/obj/usr/src/i386.i386/sys/GENERIC -mno-mmx -mno-sse -msoft-float = -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall = -Wredundant-decls -Wnested-externs -Wstrict-prototypes = -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef = -Wno-pointer-sign -D__printf__=3D__freebsd_kprintf__ = -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas = -Wno-error-tautological-compare -Wno-error-empty-body = -Wno-error-parentheses-equality -Wno-error-unused-function = -Wno-error-pointer-sign -Wno-error-shift-negative-value = -Wno-address-of-packed-member -Wno-error-cast-qual -mno-aes -mno-avx = -std=3Diso9899:1999 -Werror -mmmx -msse -msse4 -maes -mpclmul = /usr/src/sys/crypto/aesni/aesni_ghash.c /usr/src/sys/crypto/aesni/aesni_ghash.c:75:10: fatal error: = 'wmmintrin.h' file not found #include ^~~~~~~~~~~~~ 1 error generated. *** [aesni_ghash.o] Error code 1 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Sat Jun 30 13:58: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 626AC1030FC8; Sat, 30 Jun 2018 13:58:51 +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 DF4637E7AD; Sat, 30 Jun 2018 13:58:50 +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 EC9E3D5BC; Sat, 30 Jun 2018 15:58:48 +0200 (CEST) From: Dimitry Andric Message-Id: <082D396D-639C-445F-A04E-5C56F219D177@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_255F8461-A9AA-411D-BFBD-91EED23ED1AA"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: svn commit: r335813 [ broke ci.freebsd.org 's FreeBSD-head-{aarch64,amd64,i386}-build ] Date: Sat, 30 Jun 2018 15:58:36 +0200 In-Reply-To: <84175A6B-B159-4320-95FD-C5BC7F3B4C96@yahoo.com> Cc: svn-src-head@freebsd.org, FreeBSD Current To: Mark Millard References: <84175A6B-B159-4320-95FD-C5BC7F3B4C96@yahoo.com> X-Mailer: Apple Mail (2.3445.8.2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 30 Jun 2018 13:58:51 -0000 --Apple-Mail=_255F8461-A9AA-411D-BFBD-91EED23ED1AA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 30 Jun 2018, at 15:22, Mark Millard wrote: >=20 > https://ci.freebsd.org/job/FreeBSD-head-aarch64-build/8358/consoleText >=20 > --- all_subdir_armv8crypto --- > /usr/src/sys/crypto/armv8/armv8_crypto_wrap.c:46:10: fatal error: = 'arm_neon.h' file not found > #include > ^~~~~~~~~~~~ > 1 error generated. > *** [armv8_crypto_wrap.o] Error code 1 >=20 >=20 > https://ci.freebsd.org/job/FreeBSD-head-amd64-build/9268/consoleText >=20 > --- lib/liblzma__L --- > 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. > *** [lz_encoder.o] Error code 1 Yeah, sorry about that, working on it now. I'm awaiting a full build to see if there are any other issues. -Dimitry --Apple-Mail=_255F8461-A9AA-411D-BFBD-91EED23ED1AA 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 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCWzeMjAAKCRCwXqMKLiCW oz8IAKDxNVFQXCyzXvPSE5XRWLLjEjGdTQCfZbgvC2KcRs0MQUY5V3cNiMaPgv8= =KdEl -----END PGP SIGNATURE----- --Apple-Mail=_255F8461-A9AA-411D-BFBD-91EED23ED1AA-- From owner-freebsd-current@freebsd.org Sat Jun 30 14:51: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 7828B1032EE7; Sat, 30 Jun 2018 14:51:53 +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 20C4180573; Sat, 30 Jun 2018 14:51:53 +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 BDDFE10AFCD; Sat, 30 Jun 2018 10:51:51 -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> Cc: Bryan Drewery , svn-src-head@freebsd.org, FreeBSD Current From: John Baldwin Message-ID: <65b19cc4-eaf0-13ed-43e6-9f04a1f7f196@FreeBSD.org> Date: Sat, 30 Jun 2018 07:51:59 -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: <003509F0-F2F4-4A43-82FE-3F6FC23D19D4@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); Sat, 30 Jun 2018 10:51:52 -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.26 Precedence: 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, 30 Jun 2018 14:51:53 -0000 On 6/29/18 2:37 PM, Mark Millard wrote: > [I expect this is more than just amd64-gcc related but that is all > that ci.freebsd.org normally builds via a devel/*-gcc .] As indicated by my other mail, this is i386 and amd64 specific as it only matters for float.h on i386 due to the disagreement on LDBL_MANT_DIG. -- John Baldwin From owner-freebsd-current@freebsd.org Sat Jun 30 16:17: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 B0E571038006 for ; Sat, 30 Jun 2018 16:17:26 +0000 (UTC) (envelope-from marklmi@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 95CE983214 for ; Sat, 30 Jun 2018 16:17:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: pGSt4RkVM1lCvHUZlypj94lLqhPMdx01CrPywH937XUxxwY8jGJi2kgXZhHNpFY 6QJS.H_Hx1p.nRmRXHx0Yiwg1rUkAxTEXkjzgQYKZQDZa65H69i59ZDAm6TReI.LIa1y4XUcfpWn x2QjNxb6X5z9UUDwycpYuf10ksoNE8zJzJo_m7XJvoAQIgyV58blHCHoVpvzhjsFSvRtvp4mPgi. RPALnBpI.dtCPe2MP8RdngDxjGH7tZd2edGiCmZxYA9pJCxSp.YF2jVNZCi8l3l6Ms8LRp0hV6Pd sD4oaxZKpHZFYGKTFxZjDJLQuBZXMeBUSQ0HuXhBa8MVCIGpxim9.CEQRkHUfUciCFs4a78SXaBV i9lzUp9ZtvBlvVkh7dE55ZHAzZygJca7P5rIHC4p653FsxJikHFf.z38rs5PpcKeihkJuNs9hnZN XjeBgBHzh4ar.uW745NRBbI1Xe.jOJe8IpJXeiacAyKRtOW9hynvbyTsrPXd7Ds8KRn2iwkdmldk 1JTC2QdLkVK27EuTj0Wz8hGxba0DmBIR4FrZb1oHTmbHQb9M2fGISDFlaUVf4Px6ukAx0AMCA_0J IscZx_0FvcV_r14OKPFovkkAnSOYmPlseZk4.WWxtd1xlqlfbXlDxHlB8lvgxui4YySczy1P.i3M XPpvfmr4foldylaa63pcpfSkIPreCW4XizbR_uyZreT8LyA8ZVPgo9niSpJTyqnIkKMhjV9d1709 5bJGHruhwPTVARKoyWOKISa9CbHCZ6lX36.rBqIhKbWjzjKoxAl0puUHrASTnuW6OykSJzO5_u80 7ksOWDhMzISGod3wihIK8e5UAY.MTRoAshrKqkXlW6C44SUJZe9SBGH7hMFj7nUXA6RDpepbeMGa .tTl1WtSfrmmdhv7TzDTtvsHT9incknqzOdXsrS089yW1Hj9uddvsqH__mUiZnoeB76MHJs6LS_c 32ARV7FKxjk0dCkte6W6WnSsC137TEXdswwrvrOc- Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.bf2.yahoo.com with HTTP; Sat, 30 Jun 2018 16:17:24 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp427.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 50f1d279f5af2185a20f90ae09f34b8c; Sat, 30 Jun 2018 16:17:24 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build) From: Mark Millard In-Reply-To: <65b19cc4-eaf0-13ed-43e6-9f04a1f7f196@FreeBSD.org> Date: Sat, 30 Jun 2018 09:17:21 -0700 Cc: Bryan Drewery , svn-src-head@freebsd.org, FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: 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> To: John Baldwin , Dimitry Andric 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: Sat, 30 Jun 2018 16:17:27 -0000 On 2018-Jun-30, at 7:51 AM, John Baldwin wrote: > On 6/29/18 2:37 PM, Mark Millard wrote: >> [I expect this is more than just amd64-gcc related but that is all >> that ci.freebsd.org normally builds via a devel/*-gcc .] >=20 > As indicated by my other mail, this is i386 and amd64 specific as it > only matters for float.h on i386 due to the disagreement on > LDBL_MANT_DIG. I was correct about the search order for include files being different before -r335782 vs. -r335782 and later: head -r335812 uses the gcc headers (and fails): 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/lib/msun/x86 /usr/src/lib/msun/ld80 /usr/src/lib/msun/i387 /usr/src/lib/msun/src /usr/src/lib/libc/include /usr/src/lib/libc/i386 /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tm= p/usr/include End of search list. head -r335245 uses the FreeBSD headers and works: 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" ignoring duplicate directory = "/usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/t= mp/usr/include" #include "..." search starts here: #include <...> search starts here: /usr/src/lib/msun/x86 /usr/src/lib/msun/ld80 /usr/src/lib/msun/i387 /usr/src/lib/msun/src /usr/src/lib/libc/include /usr/src/lib/libc/i386 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tm= p/usr/include /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include End of search list. Might this reversal have other effects even for architectures for which the code does compile via devel/*-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 Sat Jun 30 16:29:14 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 A101A10398BF; Sat, 30 Jun 2018 16:29:14 +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 3388B83847; Sat, 30 Jun 2018 16:29:14 +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 2E30510A87D; Sat, 30 Jun 2018 12:29:12 -0400 (EDT) Subject: Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build) To: Mark Millard , Dimitry Andric 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> Cc: Bryan Drewery , svn-src-head@freebsd.org, FreeBSD Current From: John Baldwin Message-ID: Date: Sat, 30 Jun 2018 09:29:19 -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); Sat, 30 Jun 2018 12:29:12 -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: Sat, 30 Jun 2018 16:29:14 -0000 On 6/30/18 9:17 AM, Mark Millard wrote: > On 2018-Jun-30, at 7:51 AM, John Baldwin wrote: > >> On 6/29/18 2:37 PM, Mark Millard wrote: >>> [I expect this is more than just amd64-gcc related but that is all >>> that ci.freebsd.org normally builds via a devel/*-gcc .] >> >> As indicated by my other mail, this is i386 and amd64 specific as it >> only matters for float.h on i386 due to the disagreement on >> LDBL_MANT_DIG. > > I was correct about the search order for include files being > different before -r335782 vs. -r335782 and later: Yes, but this is kind of a feature, not a bug, and the issue there is that as much as possible we should allow FreeBSD to work with the standard headers that are supposed to be part of the language (and thus provided by the toolchain). Right now we don't ship any of the 'std*.h' headers clang provides for example in our base system clang, though a few months ago I fixed the one place that was using instead of in userland that was breaking the use of the toolchain-provided stdarg.h (both GCC and clang). > Might this reversal have other effects even for > architectures for which the code does compile > via devel/*-gcc ? It depends on the header. This particular failure is due to a quirk of on FreeBSD/i386. I have built other platforms with external GCC just fine. To the extent that we encounter any other issues we should try to make our source more conformant with C and only fall back to axeing the toolchain-provided language headers as a last resort. -- John Baldwin From owner-freebsd-current@freebsd.org Sat Jun 30 17:05:04 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 A64C0BB6 for ; Sat, 30 Jun 2018 17:05:04 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-20.consmr.mail.gq1.yahoo.com (sonic306-20.consmr.mail.gq1.yahoo.com [98.137.68.83]) (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 166C284CA3 for ; Sat, 30 Jun 2018 17:05:04 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: XeMX4HgVM1lRZ7liL7rVIPGTquJSZscRE5dNnhy9axojtLxx8X1JTq_eNdNzZIu OGlodgEFSXt5UN8ZOBCqGXkdF0mx78sXmjZ2hdhaCoSf1jpIU8Em_T4bnqm4VRvCdxm7r.ecmw2W 0Yx1c78Fl5FC8Bz1BAhEXrlGudgxZGfauKwxQ9ztruUMLot_1xowidWNgrdbtqDJXlFxXjnu8P5r TpW2l67C0hX_gSfABgIqhJ.J2ozGZ07_m2CMWusM5WD5n1AVWdJ8YwbGLI2VOzzPXReKcLyqb.fO ULpfcMCU6A0Ml31JEaFwz8GoZjjBEYhOz64nWZmxZoXdRg7WQDb_5.q4BqAknGBkLc8TehPsGIMs FCdzec3UXcD0qsJAXFarfn4sDNPdk3CYoatfLf8KSiOTeR0vyWPP6ZN7ykGHqpJStgSE4u_N4hS5 q6EJtLLeEbqMD8z9MvfK5EZP0fRh00untUTcT4NwNzyCwfJa4ZAKG7bQKXyf0qb.OykNTThLm2kn Ae.Ac157uuDVfsok6JmlDAUtRL02ZVq7NeSyZ2Ftn7boaBRDnxfHnWqFXQgmSVWnktYun0crLdex UVIqwtCx5qMp8iJUwNIgDqmscEHe0uMVHyogb7X8wjej.u7eYbg38psk4xEJHGl_XnVGNXpSawSM yTfwKHwIyiz8LfLJj8NuMWdP0XDpGT.4wHcVmmeRN8t7zKdL0fcM_ba6s_P5D70._7lTCpz.tO1J z7mSohpuW9mJxyDOPF1YLspiCX.P9YhoOp8.qOmIbeAvDpiBKdxnfiGhyyBEhvJTMbPF388.J3lC n9gT432tgjH0CzJ1879xxq61QDiUAAGUEkeKHer1h_PWaiMPcxTcz2z097r1NSKS7rG1VebLHoml LArxt5fAbqDd7y6kcftDibSoIXJo4MVDUWt6LY6RXDOj4t9nCaqR7svzcyOwAAone3w_2LEp7L31 Gb2Rt6CBfMY4reDFGwRV2pvXSnuSElQV6 Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Sat, 30 Jun 2018 17:04:56 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp418.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID f284a0a421dafd545100c752ffb27663; Sat, 30 Jun 2018 17:04:53 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build) From: Mark Millard In-Reply-To: Date: Sat, 30 Jun 2018 10:04:51 -0700 Cc: Dimitry Andric , Bryan Drewery , svn-src-head@freebsd.org, FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <49BF6569-96A9-4104-BDE6-8BB94C0D9626@yahoo.com> 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> To: John Baldwin 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: Sat, 30 Jun 2018 17:05:04 -0000 On 2018-Jun-30, at 9:29 AM, John Baldwin wrote: > On 6/30/18 9:17 AM, Mark Millard wrote: >> On 2018-Jun-30, at 7:51 AM, John Baldwin wrote: >>=20 >>> On 6/29/18 2:37 PM, Mark Millard wrote: >>>> [I expect this is more than just amd64-gcc related but that is all >>>> that ci.freebsd.org normally builds via a devel/*-gcc .] >>>=20 >>> As indicated by my other mail, this is i386 and amd64 specific as it >>> only matters for float.h on i386 due to the disagreement on >>> LDBL_MANT_DIG. >>=20 >> I was correct about the search order for include files being >> different before -r335782 vs. -r335782 and later: >=20 > Yes, but this is kind of a feature, not a bug, and the issue there is = that > as much as possible we should allow FreeBSD to work with the standard = headers > that are supposed to be part of the language (and thus provided by the > toolchain). Right now we don't ship any of the 'std*.h' headers clang > provides for example in our base system clang, though a few months ago = I > fixed the one place that was using instead of > in userland that was breaking the use of the = toolchain-provided > stdarg.h (both GCC and clang). >=20 >> Might this reversal have other effects even for >> architectures for which the code does compile >> via devel/*-gcc ? >=20 > It depends on the header. This particular failure is due to a quirk = of > on FreeBSD/i386. I have built other platforms with external > GCC just fine. To the extent that we encounter any other issues we > should try to make our source more conformant with C and only fall = back to > axeing the toolchain-provided language headers as a last resort. It is too bad that the review https://reviews.freebsd.org/D16055 did not catch the change in what headers are used by buildworld and buildkernel. I'd view such switching of long established header bindings as a fairly big deal, possibly even warranting being explicitly proposed and debated. I'm not claiming my opinion on which search order that I have is actually relevant. I'm just now nervous about my powerpc64-gcc based builds having unexpected differences, for example. [I sometimes explore the status of powerpc family builds via more modern toolchains.] (But lib32 for powerpc64 via modern gcc's is messed up anyway, generating code in crtbeginS.o for the wrong ABI: using R30 incorrectly. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206123 has more = about that.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Sat Jun 30 17:19: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 5D6B2FD05D4 for ; Sat, 30 Jun 2018 17:19:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-21.consmr.mail.ne1.yahoo.com (sonic305-21.consmr.mail.ne1.yahoo.com [66.163.185.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 DFDF285335 for ; Sat, 30 Jun 2018 17:19:35 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: Xt_DqMoVM1l_bXXQbL7opZX8yHE4ysXbHpB.KhBDQzxRDVSFeEFGAyL6w5l5bJ_ HZpEJLlULyPEcAga4Rw.4qbMtRKWuggCzye2sFaAzPSdkIPsOxdOZqa_VjZ8Avs9J.ufhcwHXsTz Er3pAEuTa6r5a..VZy5PvzW7Ka1XBNvurJHE9mpzb0nx4UHPot4uZiAScj0PP0lh3XgxrYN9cR6H 9ICQtk4IEUyccm0xF1LLcV53kadiPeIGNX1ZxcPsLxj_ROKM9YC9ygsSE2PlbNMt0IAJohxl_hLh YKowHf9GDoo..uoz.i1OMG9OXTdq4MCVLfHltmHcpI5FhexmEjs1o617FQc_O1qN5LQTlDlwJ9WZ T1MB6G0erN1EpDo28OovK.AUyEv8dnZbDLLye5LlOz6IwXtlR.ETGE4w3cFdfrMh1cA_6uX.KLpi lHyP_lyGH5tUbtMxogiCZs2NDUa0i1OSX2LFoxap0K8nYWT9_6zIOorRBRMSG4ywezrYLN0eRDDH C8UC9PMWZqlA2YjaTiw0LFFn5wfZXuQx5ZTuYK_DWo2AH6i.Lzn4LbUjd7paKC6r1MVC1cT8hRUm gN6Kmtx.ZXN48NwEI.KylSCH_viUpw_pMK1Wv9.ZmHZnajO5k8FuiJtd48PtWglIYSe1GShD6_PU C8svR5.0NUic0ylXmPT9iDw.Rb6qq4pkS80q2N9lmktj1G3WAmbwXTGa8sk0S1bn6BUrp24.ZqqE PRLkzKG5e.BJQSCdnEYSlgJrdmxLkIX3e7tQ71b7yF30XnVb2rkyCtEvTF6xFLZ8RVcEBtFrmadc n8APb0_Rr7Dt7F0H6OuWSFCyPIm5QdjGxXAbh05i4dXJfPX7RIwbDmIN3jvp1m2qBS6wRAXY0e9p bl6o.j6VqDcajC9GftP07OmCzT9Gfnql7ED1NCE0sTe7Cktiw37hFX2A6k.eI9145hZdrrmpM0em Tx1i8GqDU2cABvAZ3ED60lIYRDuQETHBFkQDv34QCUw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.ne1.yahoo.com with HTTP; Sat, 30 Jun 2018 17:19:29 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp419.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID c0a53a6b3e4e8bea18e82ab34bc09f84; Sat, 30 Jun 2018 17:19:24 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build) From: Mark Millard In-Reply-To: <49BF6569-96A9-4104-BDE6-8BB94C0D9626@yahoo.com> Date: Sat, 30 Jun 2018 10:19:22 -0700 Cc: Bryan Drewery , svn-src-head@freebsd.org, FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: 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> To: John Baldwin , Dimitry Andric 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: Sat, 30 Jun 2018 17:19:36 -0000 On 2018-Jun-30, at 10:04 AM, Mark Millard wrote: > On 2018-Jun-30, at 9:29 AM, John Baldwin wrote: >=20 >> On 6/30/18 9:17 AM, Mark Millard wrote: >>> On 2018-Jun-30, at 7:51 AM, John Baldwin wrote: >>>=20 >>>> On 6/29/18 2:37 PM, Mark Millard wrote: >>>>> [I expect this is more than just amd64-gcc related but that is all >>>>> that ci.freebsd.org normally builds via a devel/*-gcc .] >>>>=20 >>>> As indicated by my other mail, this is i386 and amd64 specific as = it >>>> only matters for float.h on i386 due to the disagreement on >>>> LDBL_MANT_DIG. >>>=20 >>> I was correct about the search order for include files being >>> different before -r335782 vs. -r335782 and later: >>=20 >> Yes, but this is kind of a feature, not a bug, and the issue there is = that >> as much as possible we should allow FreeBSD to work with the standard = headers >> that are supposed to be part of the language (and thus provided by = the >> toolchain). Right now we don't ship any of the 'std*.h' headers = clang >> provides for example in our base system clang, though a few months = ago I >> fixed the one place that was using instead of >> in userland that was breaking the use of the = toolchain-provided >> stdarg.h (both GCC and clang). >>=20 >>> Might this reversal have other effects even for >>> architectures for which the code does compile >>> via devel/*-gcc ? >>=20 >> It depends on the header. This particular failure is due to a quirk = of >> on FreeBSD/i386. I have built other platforms with = external >> GCC just fine. To the extent that we encounter any other issues we >> should try to make our source more conformant with C and only fall = back to >> axeing the toolchain-provided language headers as a last resort. >=20 > It is too bad that the review https://reviews.freebsd.org/D16055 did = not > catch the change in what headers are used by buildworld and = buildkernel. > I'd view such switching of long established header bindings as a > fairly big deal, possibly even warranting being explicitly proposed = and > debated. >=20 > I'm not claiming my opinion on which search order that I have is > actually relevant. I'm just now nervous about my powerpc64-gcc based > builds having unexpected differences, for example. [I sometimes = explore > the status of powerpc family builds via more modern toolchains.] >=20 > (But lib32 for powerpc64 via modern gcc's is messed up anyway, > generating code in crtbeginS.o for the wrong ABI: using R30 = incorrectly. > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206123 has more = about > that.) Looks like my being nervous is justified: there is a conflicting = altivec.h that has nothing to do with C/C++ language standards: # ls /usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/include/ altivec.h htmxlintrin.h ppc-asm.h = spe.h stdarg.h stddef.h = stdint.h varargs.h float.h iso646.h ppu_intrinsics.h = spu2vmx.h stdatomic.h stdfix.h = stdnoreturn.h vec_types.h htmintrin.h paired.h si2vmx.h = stdalign.h stdbool.h stdint-gcc.h = tgmath.h I've not checked for other name conflicts vs. FreeBSD. I just happen to recognize altivec.h . There is: = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.po= werpc64/tmp/usr/include/machine/altivec.h = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.po= werpc64/tmp/usr/lib/clang/6.0.0/include/altivec.h = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.po= werpc64/obj-lib32/tmp/usr/include/machine/altivec.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 Sat Jun 30 18:39: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 550FCFD3E80 for ; Sat, 30 Jun 2018 18:39:59 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670057.outbound.protection.outlook.com [40.107.67.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT TLS CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B89A0875FF for ; Sat, 30 Jun 2018 18:39:58 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM (52.132.44.24) by YTOPR0101MB0747.CANPRD01.PROD.OUTLOOK.COM (52.132.43.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.906.23; Sat, 30 Jun 2018 18:39:57 +0000 Received: from YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM ([fe80::d0eb:3783:7c99:2802]) by YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM ([fe80::d0eb:3783:7c99:2802%4]) with mapi id 15.20.0906.026; Sat, 30 Jun 2018 18:39:57 +0000 From: Rick Macklem To: "freebsd-current@freebsd.org" Subject: change of nfsd->kernel interface in head Thread-Topic: change of nfsd->kernel interface in head Thread-Index: AQHUEKEFXkupwPKmB02DAPWywH5oog== Date: Sat, 30 Jun 2018 18:39:57 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YTOPR0101MB0747; 7:gjc8ZojK0zuwtgSimB43I4zGBOhfH8pC13hChwBJDOPQaQzu5FFTpODFjvYDT+T/2BcLL9wZ/w+3WuonuooG1BtbbWc/loANL2j8heGqcPgN1uANlbVWI1f1wV/l8q8XV9MQPszZOHTu4J+ZfRKuS70G9BrImpmnn6V9SfkEyKEkXvCblKFA7tYbKyOcl3wixLma6nSncOXDrvHaraHLsbwYSwYrenws5zrQ9pN9i4s/7gANRHBxdyLV9KIyjStH x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: bb77f49e-3c24-4c22-d8c7-08d5deb8e156 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:YTOPR0101MB0747; x-ms-traffictypediagnostic: YTOPR0101MB0747: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3002001)(3231254)(944501410)(52105095)(10201501046)(93006095)(93001095)(149027)(150027)(6041310)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:YTOPR0101MB0747; BCL:0; PCL:0; RULEID:; SRVR:YTOPR0101MB0747; x-forefront-prvs: 0719EC6A9A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(136003)(376002)(396003)(366004)(199004)(189003)(8676002)(25786009)(8936002)(81166006)(81156014)(2501003)(33656002)(53936002)(5250100002)(2900100001)(14454004)(105586002)(106356001)(68736007)(97736004)(2906002)(5640700003)(7696005)(6436002)(6506007)(6916009)(316002)(55016002)(486006)(786003)(74482002)(478600001)(256004)(305945005)(9686003)(99286004)(86362001)(74316002)(2351001)(26005)(186003)(5660300001)(476003)(102836004); DIR:OUT; SFP:1101; SCL:1; SRVR:YTOPR0101MB0747; H:YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-microsoft-antispam-message-info: 4vDwGjhgEV8tRjdnj7IcjsWfNPZf5G8N5ykkflIPxCjsmuqY/n5d/cYla5XMAiTALabBc9sps9J7KJrTTGZSOK4VvpXsjzed2Vd5jfURI7Ni8Tark7p0JM4+eCwLvCkBXFaj6yjjLB+DJHYcAPTUb5FeHgiSU86Kqn486B9CWA0LRQe9tZQxb0Rz8xSs7M2I+D3I9ToLMHuUqahlvHPMjpLRZjTVi6QoT8OO73i+EDjbIV7lcYU3yxm/d1hELl6QzuaxSurH5yr67vScDcpk/FSnz/4mL8rV1FDSGo5DYULrZeSZbaF5U9pG7e7IghKZpRTBwF4Bk+iaBXBCmVfo8QdWxRlknjghUNaTJISz5Qc= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-Network-Message-Id: bb77f49e-3c24-4c22-d8c7-08d5deb8e156 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jun 2018 18:39:57.7826 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTOPR0101MB0747 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, 30 Jun 2018 18:39:59 -0000 r335012 (the big patch that added the pNFS server support) revised the nfsd= ->kernel nfssvc(2) syscall interface. It has compatibility code, so that old nfsd binaries still work. I now need to revise this interface again to add a new pNFS server feature. Since the revised interface is only in head/current starting at r335012, I believe I can revise it again without an additional compatibility shim for r335012 or later nfsd binaries. Is this correct? I would post a HEADS UP to this email list and the only code affected would= be sites running current/head and using the "-p" (pNFS server) option, so they= would be few, if any. rick= From owner-freebsd-current@freebsd.org Sat Jun 30 18:53: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 BAB80FD4645; Sat, 30 Jun 2018 18:53:56 +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 67BCC88815; Sat, 30 Jun 2018 18:53:56 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-2.local (unknown [IPv6:2601:648:8880:1e30:28be:12f1:cde2:51bd]) by mail.baldwin.cx (Postfix) with ESMTPSA id AB21F10A87D; Sat, 30 Jun 2018 14:53:49 -0400 (EDT) Subject: Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build) To: Mark Millard , Dimitry Andric 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> Cc: Bryan Drewery , svn-src-head@freebsd.org, FreeBSD Current From: John Baldwin Message-ID: Date: Sat, 30 Jun 2018 11:53:48 -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); Sat, 30 Jun 2018 14:53:50 -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: Sat, 30 Jun 2018 18:53:57 -0000 On 6/30/18 10:19 AM, Mark Millard wrote: > > > On 2018-Jun-30, at 10:04 AM, Mark Millard wrote: > >> On 2018-Jun-30, at 9:29 AM, John Baldwin wrote: >> >>> On 6/30/18 9:17 AM, Mark Millard wrote: >>>> On 2018-Jun-30, at 7:51 AM, John Baldwin wrote: >>>> >>>>> On 6/29/18 2:37 PM, Mark Millard wrote: >>>>>> [I expect this is more than just amd64-gcc related but that is all >>>>>> that ci.freebsd.org normally builds via a devel/*-gcc .] >>>>> >>>>> As indicated by my other mail, this is i386 and amd64 specific as it >>>>> only matters for float.h on i386 due to the disagreement on >>>>> LDBL_MANT_DIG. >>>> >>>> I was correct about the search order for include files being >>>> different before -r335782 vs. -r335782 and later: >>> >>> Yes, but this is kind of a feature, not a bug, and the issue there is that >>> as much as possible we should allow FreeBSD to work with the standard headers >>> that are supposed to be part of the language (and thus provided by the >>> toolchain). Right now we don't ship any of the 'std*.h' headers clang >>> provides for example in our base system clang, though a few months ago I >>> fixed the one place that was using instead of >>> in userland that was breaking the use of the toolchain-provided >>> stdarg.h (both GCC and clang). >>> >>>> Might this reversal have other effects even for >>>> architectures for which the code does compile >>>> via devel/*-gcc ? >>> >>> It depends on the header. This particular failure is due to a quirk of >>> on FreeBSD/i386. I have built other platforms with external >>> GCC just fine. To the extent that we encounter any other issues we >>> should try to make our source more conformant with C and only fall back to >>> axeing the toolchain-provided language headers as a last resort. >> >> It is too bad that the review https://reviews.freebsd.org/D16055 did not >> catch the change in what headers are used by buildworld and buildkernel. >> I'd view such switching of long established header bindings as a >> fairly big deal, possibly even warranting being explicitly proposed and >> debated. >> >> I'm not claiming my opinion on which search order that I have is >> actually relevant. I'm just now nervous about my powerpc64-gcc based >> builds having unexpected differences, for example. [I sometimes explore >> the status of powerpc family builds via more modern toolchains.] >> >> (But lib32 for powerpc64 via modern gcc's is messed up anyway, >> generating code in crtbeginS.o for the wrong ABI: using R30 incorrectly. >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206123 has more about >> that.) > > Looks like my being nervous is justified: there is a conflicting altivec.h > that has nothing to do with C/C++ language standards: > > # ls /usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/include/ > altivec.h htmxlintrin.h ppc-asm.h spe.h stdarg.h stddef.h stdint.h varargs.h > float.h iso646.h ppu_intrinsics.h spu2vmx.h stdatomic.h stdfix.h stdnoreturn.h vec_types.h > htmintrin.h paired.h si2vmx.h stdalign.h stdbool.h stdint-gcc.h tgmath.h > > I've not checked for other name conflicts vs. FreeBSD. I just happen > to recognize altivec.h . There is: > > /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/usr/include/machine/altivec.h > > /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/usr/lib/clang/6.0.0/include/altivec.h > > /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.powerpc64/obj-lib32/tmp/usr/include/machine/altivec.h Actually, that is a compiler intrinsincs header similar to the , etc. headers used for SSE on x86 that are always provided by the compiler. However, this header is '' not '' so it won't conflict. (On x86, these headers provide the _mm_* functions documented in Intel's SDM as the official C bindings for vector extensions, and probably plays a similar role in providing the vendor-specified C bindings for altivec instructions.) -- John Baldwin From owner-freebsd-current@freebsd.org Sat Jun 30 19:53: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 96875FD5DA7 for ; Sat, 30 Jun 2018 19:53:02 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-20.consmr.mail.gq1.yahoo.com (sonic313-20.consmr.mail.gq1.yahoo.com [98.137.65.83]) (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 099D98A65C for ; Sat, 30 Jun 2018 19:53:01 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: NXGhhtwVM1n4_uoSr6_P_DdcqOlvMf0178FElPlm.ZnpSLskbfHPmt4ZtgdP6aI U3zY0434R4mWFdi.5GbAGV9eJaz8B8qrISShix5fqqHsOUnjof0S1IAaH.ab7RloL2Y_WkJF9QXi MbOdQNoYcr37j6ATqSNKOhLnLi.mWWbSrK41VDYkX5od7RsIahaJqrZEPEFB_aEWlcwB.jOEGEXZ xkDEHUP4Yfu00ZDsvW4wt7VHKq2LfWgvuIXrqOFXSrDuebhhJ05JrCJYq7bwUQppXBk_zCHZGQ7I 0R7PGahDhp.bHAWxkcmhOsWJ32.44sCayLt9_niAjS58OThCourzbb9gssT1_.M5U.YzAj5MM3dM qgibMC5CYh5.heu25Nd.nNB9NUJVvbIeo9Evn2GySQCcaUUFFcv9uCSZiRJzZ0w4bycXh1EUB2aV JlZTsdn7ZGez1JWlOq6rodYREyswosTpsOCREgbYxFki5W0z4kRkuksAxNfQTllQINnr_R5JfHXR HMeABCWtLBJ70vXC0QpA.IZnDKQRG1u9fJ6Yeomc1P6B6fUVmdCrgMqOnxjDf0CXiHW_cxIHr5AZ W2qjXXU79sSXNEzBXEuH_9qwKftl3ieONydtGOWAdNy_jRmA6JhTq_vBdFM2z010EGpXSM_qDVXi TmrPoRN90dlvG.zQCIJb2JtJYWCmLVOMj6sqLuMOjxjX3LBb0YURr2CzI.30ss4ieIWuSkb59rgH RSODvLhr0I0ze2BY4XWRg6DQVvkajSTu_MJXXpm7lQIwvjIGBMqENwr5uli9QBnDBTA_iCOQG6lU jXN1HRgQQCVhyYIgtxtZONCaRQ4W9HT3qZezqhpgapGLk5NYIJKW9FtxMKowSyzlhf2EFhppc8_Q PHQiY3X55x185A5HxWu3XLrTZXjRCMT5cnJZQn7c4aESXYPCaegwuPArsqql.dIdWIKeFTrUufqP RKq1hzZPROn9c9JpChKuorxYIN6MBSY1e.g-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Sat, 30 Jun 2018 19:52:54 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp405.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 5aa676cfba08ebfdb7125dd985a49388; Sat, 30 Jun 2018 19:52:50 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build) From: Mark Millard In-Reply-To: Date: Sat, 30 Jun 2018 12:52:48 -0700 Cc: Dimitry Andric , Bryan Drewery , svn-src-head@freebsd.org, FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: 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> To: John Baldwin 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: Sat, 30 Jun 2018 19:53:02 -0000 On 2018-Jun-30, at 11:53 AM, John Baldwin wrote: > On 6/30/18 10:19 AM, Mark Millard wrote: >=20 >=20 > On 2018-Jun-30, at 10:04 AM, Mark Millard = wrote: >=20 >> On 2018-Jun-30, at 9:29 AM, John Baldwin wrote: >>=20 >>> On 6/30/18 9:17 AM, Mark Millard wrote: >>>> On 2018-Jun-30, at 7:51 AM, John Baldwin = wrote: >>>>=20 >>>>> On 6/29/18 2:37 PM, Mark Millard wrote: >>>>>> [I expect this is more than just amd64-gcc related but that is = all >>>>>> that ci.freebsd.org normally builds via a devel/*-gcc .] >>>>>=20 >>>>> As indicated by my other mail, this is i386 and amd64 specific as = it >>>>> only matters for float.h on i386 due to the disagreement on >>>>> LDBL_MANT_DIG. >>>>=20 >>>> I was correct about the search order for include files being >>>> different before -r335782 vs. -r335782 and later: >>>=20 >>> Yes, but this is kind of a feature, not a bug, and the issue there = is that >>> as much as possible we should allow FreeBSD to work with the = standard headers >>> that are supposed to be part of the language (and thus provided by = the >>> toolchain). Right now we don't ship any of the 'std*.h' headers = clang >>> provides for example in our base system clang, though a few months = ago I >>> fixed the one place that was using instead of >>> in userland that was breaking the use of the = toolchain-provided >>> stdarg.h (both GCC and clang). >>>=20 >>>> Might this reversal have other effects even for >>>> architectures for which the code does compile >>>> via devel/*-gcc ? >>>=20 >>> It depends on the header. This particular failure is due to a quirk = of >>> on FreeBSD/i386. I have built other platforms with = external >>> GCC just fine. To the extent that we encounter any other issues we >>> should try to make our source more conformant with C and only fall = back to >>> axeing the toolchain-provided language headers as a last resort. >>=20 >> It is too bad that the review https://reviews.freebsd.org/D16055 did = not >> catch the change in what headers are used by buildworld and = buildkernel. >> I'd view such switching of long established header bindings as a >> fairly big deal, possibly even warranting being explicitly proposed = and >> debated. >>=20 >> I'm not claiming my opinion on which search order that I have is >> actually relevant. I'm just now nervous about my powerpc64-gcc based >> builds having unexpected differences, for example. [I sometimes = explore >> the status of powerpc family builds via more modern toolchains.] >>=20 >> (But lib32 for powerpc64 via modern gcc's is messed up anyway, >> generating code in crtbeginS.o for the wrong ABI: using R30 = incorrectly. >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206123 has more = about >> that.) >=20 > Looks like my being nervous is justified: there is a conflicting = altivec.h > that has nothing to do with C/C++ language standards: >=20 > # ls /usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/include/ > altivec.h htmxlintrin.h ppc-asm.h = spe.h stdarg.h stddef.h = stdint.h varargs.h > float.h iso646.h ppu_intrinsics.h = spu2vmx.h stdatomic.h stdfix.h = stdnoreturn.h vec_types.h > htmintrin.h paired.h si2vmx.h = stdalign.h stdbool.h stdint-gcc.h = tgmath.h >=20 > I've not checked for other name conflicts vs. FreeBSD. I just happen > to recognize altivec.h . There is: >=20 > = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.po= werpc64/tmp/usr/include/machine/altivec.h >=20 > = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.po= werpc64/tmp/usr/lib/clang/6.0.0/include/altivec.h >=20 > = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.po= werpc64/obj-lib32/tmp/usr/include/machine/altivec.h >=20 > Actually, that is a compiler intrinsincs header similar to the = , > etc. headers used for SSE on x86 that are always provided by the = compiler. > However, this header is '' not '' so it = won't conflict. >=20 > (On x86, these headers provide the _mm_* functions documented in = Intel's > SDM as the official C bindings for vector extensions, and > probably plays a similar role in providing the vendor-specified C > bindings for altivec instructions.) [This is based on a -r335812 build still.] If I have a modern gcc build a system that includes building the system clang, I do not expect it is that simple. There is: /usr/src/contrib/llvm/tools/clang/lib/Lex/Lexer.cpp:#include and altivec.h files around: /usr/lib/clang/6.0.0/include/altivec.h /usr/src/contrib/llvm/tools/clang/lib/Headers/altivec.h /usr/src/contrib/gcc/config/rs6000/altivec.h /usr/src/sys/powerpc/include/altivec.h /usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/include/altivec.h = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.po= werpc64/tmp/usr/include/machine/altivec.h = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.po= werpc64/tmp/usr/lib/clang/6.0.0/include/altivec.h = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.po= werpc64/obj-lib32/tmp/usr/include/machine/altivec.h If I read the below right the gcc altivec.h will be found by the above #include when building system clang via a modern gcc. The Lex_Lexer.o.meta shows (note the lack of include in some of the = paths compared to the above places where altivec.h files actually are --and = other path mismatches): ignoring nonexistent directory = "/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.p= owerpc64/tmp/usr/include/c++/v1//powerpc64-unknown-freebsd12.0" ignoring nonexistent directory = "/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.p= owerpc64/tmp/usr/include/c++/v1//backward" ignoring nonexistent directory = "/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/include-fixed" ignoring nonexistent directory = "/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/../../../../powerp= c64-unknown-freebsd12.0/include" #include "..." search starts here: #include <...> search starts here: = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.po= werpc64/lib/clang/libclang = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.po= werpc64/lib/clang/libllvm /usr/src/contrib/llvm/tools/clang/lib/Basic /usr/src/contrib/llvm/tools/clang/lib/Driver /usr/src/contrib/llvm/tools/clang/include /usr/src/lib/clang/include /usr/src/contrib/llvm/include = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.po= werpc64/tmp/usr/include/c++/v1/ /usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/include = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.po= werpc64/tmp/usr/include End of search list. But the old order would have found the FreeBSD one, not the clang one, for its different order if I understand right. So it is not clear that before -r335782 was right either. But is is now different from what I can tell. What the consequences might be I do not (yet) know. Just for completeness . . . There are also uses of machine/altivec.h : /usr/src/sys/powerpc/aim/aim_machdep.c:#include /usr/src/sys/powerpc/booke/spe.c:#include /usr/src/sys/powerpc/powermac/platform_powermac.c:#include = /* For save_vec() */ /usr/src/sys/powerpc/powerpc/altivec.c:#include /usr/src/sys/powerpc/powerpc/elf32_machdep.c:#include = /usr/src/sys/powerpc/powerpc/elf64_machdep.c:#include = /usr/src/sys/powerpc/powerpc/exec_machdep.c:#include /usr/src/sys/powerpc/powerpc/machdep.c:#include /usr/src/sys/powerpc/powerpc/ptrace_machdep.c:#include = /usr/src/sys/powerpc/powerpc/trap.c:#include I'd wish that the file names for the 3 contexts had been made distinct = to avoid all potential aliasing problems. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Sat Jun 30 19:53: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 C7D8DFD5E33 for ; Sat, 30 Jun 2018 19:53:47 +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 3E1AB8A6FD for ; Sat, 30 Jun 2018 19:53:47 +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 w5UJraLb032780 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 30 Jun 2018 22:53:39 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w5UJraLb032780 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w5UJraUO032779; Sat, 30 Jun 2018 22:53:36 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 30 Jun 2018 22:53:36 +0300 From: Konstantin Belousov To: Rick Macklem Cc: "freebsd-current@freebsd.org" Subject: Re: change of nfsd->kernel interface in head Message-ID: <20180630195335.GU2430@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.0 (2018-05-17) 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: Sat, 30 Jun 2018 19:53:48 -0000 On Sat, Jun 30, 2018 at 06:39:57PM +0000, Rick Macklem wrote: > r335012 (the big patch that added the pNFS server support) revised the nfsd->kernel > nfssvc(2) syscall interface. > It has compatibility code, so that old nfsd binaries still work. > > I now need to revise this interface again to add a new pNFS server feature. > Since the revised interface is only in head/current starting at r335012, I > believe I can revise it again without an additional compatibility shim for > r335012 or later nfsd binaries. Is this correct? > > I would post a HEADS UP to this email list and the only code affected would be > sites running current/head and using the "-p" (pNFS server) option, so they would > be few, if any. > You are right. More, it is not clear if nfsd interface should be considered part of the stable contract even on stable. It is clearly the management interface, nfsd is not required to get the system operational enough to install the right nfsd. If possible, stable should not add more troubles for upgrade, while for HEAD it does not matter.