From owner-freebsd-current@freebsd.org Sun Jan 26 00:02:05 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id CFEFC228169 for ; Sun, 26 Jan 2020 00:02:05 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 484tND5Lv7z4Hvp for ; Sun, 26 Jan 2020 00:02:04 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id vVNJiq6JE17ZDvVNKiuIQB; Sat, 25 Jan 2020 17:02:02 -0700 X-Authority-Analysis: v=2.3 cv=ZsqT1OzG c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=kj9zAlcOel0A:10 a=Jdjhy38mL1oA:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=c6mPj2GN9QQFLjMPNbYA:9 a=Hyxa5-U28yG75ZZN:21 a=F_7FnpcVgq6rfmR4:21 a=CjuIK1q_8ugA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id BAF6D6A2; Sat, 25 Jan 2020 16:02:00 -0800 (PST) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id 00Q020Mx007221; Sat, 25 Jan 2020 16:02:00 -0800 (PST) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id 00Q01xcs007218; Sat, 25 Jan 2020 16:01:59 -0800 (PST) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <202001260001.00Q01xcs007218@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: sgk@troutmask.apl.washington.edu cc: Cy Schubert , freebsd-current@freebsd.org, Mark Millard , yasu@utahime.org Subject: Re: After update to r357104 build of poudriere jail fails with 'out of swap space' In-reply-to: <20200125235405.GA50378@troutmask.apl.washington.edu> References: <20200125215203.GA49253@troutmask.apl.washington.edu> <3B744DB0-35ED-44FE-8235-A16EE5F925CA@cschubert.com> <20200125233116.GA49916@troutmask.apl.washington.edu> <20200125235405.GA50378@troutmask.apl.washington.edu> Comments: In-reply-to Steve Kargl message dated "Sat, 25 Jan 2020 15:54:05 -0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 25 Jan 2020 16:01:59 -0800 X-CMAE-Envelope: MS4wfNhqWoZ46MpNiGajDqtsdGlRsy/K6+4eWuDw5lezT3mQwH78aRPnwTbdXWtMzHZBU1HE0KoI+Vsr8EqIC4e0IrPGDiwvxogupIr15t1sXtRWjIxKm/nm wrTnNFgVfDQrYJaccVwUX6dVdcHC3CmpxbeaalOjJp25NS+poBBt2Isg49+YaY92trqSd23EtPuyRfTIFFsBplbS+D/5YxZluF/M5QiGDk1BzIkbs//CCNHR jTi97UFZGnwK25Z5hoIxTwyIo3/GbGmHn1VOtuVsJZaB+Aoni8OgsB/h1gQmeMLa X-Rspamd-Queue-Id: 484tND5Lv7z4Hvp X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 64.59.136.138) smtp.mailfrom=cy.schubert@cschubert.com X-Spamd-Result: default: False [-4.09 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCPT_COUNT_FIVE(0.00)[5]; REPLYTO_EQ_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[17.125.67.70.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; RCVD_TLS_LAST(0.00)[]; IP_SCORE(-2.39)[ip: (-6.24), ipnet: 64.59.128.0/20(-3.17), asn: 6327(-2.47), country: CA(-0.09)]; RCVD_IN_DNSWL_LOW(-0.10)[138.136.59.64.list.dnswl.org : 127.0.5.1] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 26 Jan 2020 00:02:05 -0000 In message <20200125235405.GA50378@troutmask.apl.washington.edu>, Steve Kargl w rites: > On Sat, Jan 25, 2020 at 03:31:16PM -0800, Steve Kargl wrote: > > On Sat, Jan 25, 2020 at 02:09:29PM -0800, Cy Schubert wrote: > > > On January 25, 2020 1:52:03 PM PST, Steve Kargl gton.edu> wrote: > > > >On Sat, Jan 25, 2020 at 01:41:16PM -0800, Cy Schubert wrote: > > > >> > > > >> It's not just poudeiere. Standard port builds of chromium, rust > > > >> and thunderbird also fail on my machines with less than 8 GB. > > > >> > > > > > > > >Interesting. I routinely build chromium, rust, firefox, > > > >llvm and few other resource-hunger ports on a i386-freebsd > > > >laptop with 3.4 GB available memory. This is done with > > > >chrome running with a few tabs swallowing a 1-1.5 GB of > > > >memory. No issues. > > > > > > Number of threads makes a difference too. How many core/threads does your > laptop have? > > > > 2 cores. > > > > > Reducing number of concurrent threads allowed my builds to complete > > > on the 5 GB machine. My build machines have 4 cores, 1 thread per > > > core. Reducing concurrent threads circumvented the issue. > > > > I use portmaster, and AFIACT, it uses 'make -j 2' for the build. > > Laptop isn't doing too much, but an update and browsing. It does > > take a long time especially if building llvm is required. > > > > In thinking about this and recalling watching top(1) during > my last firefox rebuild, it seems that the compiler can use > 0.5-1 GB when compiling files. I see how doing a parallel > build with "-j NCPU" could stress a <4 GB system. It stresses my 5 GB 4 core system whereas my 8 GB 4 core machine handles it quite nicely. 3 GB doesn't seem like a lot more but the extra 60% more RAM is a lot. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-current@freebsd.org Sun Jan 26 00:22:43 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5AB03228DD7 for ; Sun, 26 Jan 2020 00:22:43 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [18.222.6.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.soaustin.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 484tr30Kxsz4KTW for ; Sun, 26 Jan 2020 00:22:42 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from lonesome.com (unknown [18.188.142.31]) by mail.soaustin.net (Postfix) with ESMTPSA id 745ED13E42; Sun, 26 Jan 2020 00:22:42 +0000 (UTC) Date: Sun, 26 Jan 2020 00:22:41 +0000 From: Mark Linimon To: Cy Schubert Cc: sgk@troutmask.apl.washington.edu, freebsd-current@freebsd.org, Mark Millard , yasu@utahime.org Subject: Re: After update to r357104 build of poudriere jail fails with 'out of swap space' Message-ID: <20200126002241.GC6420@lonesome.com> References: <20200125215203.GA49253@troutmask.apl.washington.edu> <3B744DB0-35ED-44FE-8235-A16EE5F925CA@cschubert.com> <20200125233116.GA49916@troutmask.apl.washington.edu> <202001252359.00PNx6n1007151@slippy.cwsent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202001252359.00PNx6n1007151@slippy.cwsent.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Rspamd-Queue-Id: 484tr30Kxsz4KTW X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of linimon@lonesome.com has no SPF policy when checking 18.222.6.11) smtp.mailfrom=linimon@lonesome.com X-Spamd-Result: default: False [1.19 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-0.21)[-0.214,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; IP_SCORE(-0.19)[ip: (0.05), ipnet: 18.220.0.0/14(0.20), asn: 16509(-1.15), country: US(-0.05)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[lonesome.com]; AUTH_NA(1.00)[]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[11.6.222.18.list.dnswl.org : 127.0.5.2]; NEURAL_SPAM_LONG(0.90)[0.896,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16509, ipnet:18.220.0.0/14, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 26 Jan 2020 00:22:43 -0000 On Sat, Jan 25, 2020 at 03:59:06PM -0800, Cy Schubert wrote: > A rule of thumb would probably be, have ~ 2 GB RAM for every core or > thread when doing large parallel builds. This is a rule of thumb that I have used for quite some time. Perhaps less is necessary for certain tasks, but if you want to build compilers or other heavy packages, this seems to work. mcl From owner-freebsd-current@freebsd.org Sun Jan 26 11:55:15 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1F4EE23A937 for ; Sun, 26 Jan 2020 11:55:15 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from forward501p.mail.yandex.net (forward501p.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b7:120]) (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 485BC44rqMz3wlw for ; Sun, 26 Jan 2020 11:55:12 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from mxback18g.mail.yandex.net (mxback18g.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b7:318]) by forward501p.mail.yandex.net (Yandex) with ESMTP id A4CAC3500525; Sun, 26 Jan 2020 14:55:07 +0300 (MSK) Received: from localhost (localhost [::1]) by mxback18g.mail.yandex.net (mxback/Yandex) with ESMTP id obJLH0GsCA-t6PO2euT; Sun, 26 Jan 2020 14:55:06 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfw.ru; s=mail; t=1580039706; bh=eluCCSOlq6buPXHL96IWhhq8lYoTI38QIO4CIFyeAqg=; h=References:Date:Message-Id:Subject:In-Reply-To:To:From; b=ibb0laU8pXqz3NaDAarMfQc4AL0kf5Ky8YVBB1ujSnkvCPmYCHBRlEr3JMSMevGce SzDdnrDtqZwmRpfizKvyNu4gA+mZYM0WkV2RWEwH/SjNjHYOjgC+u2M+Rz7AnO5TAW qFMsYStERoU0U3TAZrQ2vJ+XRtQKIyJETLZlKeOA= Received: by iva4-35f072fa8e4e.qloud-c.yandex.net with HTTP; Sun, 26 Jan 2020 14:55:06 +0300 From: Alexander V. Chernikov To: AN , "freebsd-current@freebsd.org" In-Reply-To: References: Subject: Re: ip_divert.c:374:7: error: use of undeclared identifier MIME-Version: 1.0 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Sun, 26 Jan 2020 11:55:06 +0000 Message-Id: <2335001580039706@iva4-35f072fa8e4e.qloud-c.yandex.net> Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8 X-Rspamd-Queue-Id: 485BC44rqMz3wlw X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ipfw.ru header.s=mail header.b=ibb0laU8; dmarc=none; spf=pass (mx1.freebsd.org: domain of melifaro@ipfw.ru designates 2a02:6b8:0:1472:2741:0:8b7:120 as permitted sender) smtp.mailfrom=melifaro@ipfw.ru X-Spamd-Result: default: False [-6.14 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[ipfw.ru:s=mail]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a02:6b8:0:1000::/52]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[ipfw.ru]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[ipfw.ru:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[0.2.1.0.7.b.8.0.0.0.0.0.1.4.7.2.2.7.4.1.0.0.0.0.8.b.6.0.2.0.a.2.list.dnswl.org : 127.0.5.0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:13238, ipnet:2a02:6b8::/32, country:RU]; IP_SCORE(-3.64)[ip: (-9.68), ipnet: 2a02:6b8::/32(-4.72), asn: 13238(-3.81), country: RU(0.01)] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 26 Jan 2020 11:55:15 -0000 25.01.2020, 19:14, "AN" : > FYI Should be fixed by r357144. Thanks for the report! > > FreeBSD Free_BSD_13 13.0-CURRENT FreeBSD 13.0-CURRENT #22 r356360: Sat Jan > 4 20:10:21 EST 2020 > root@Free_BSD_13:/usr/obj/usr/src/amd64.amd64/sys/MYKERNEL amd64 1300074 > > --- all_subdir_dtrace --- > --- prototype.o --- > cc -target x86_64-unknown-freebsd13.0 > --sysroot=/usr/obj/usr/src/amd64.amd64/tmp > -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe > -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -DKLD_TIED -nostdinc > -I/usr/src/sys/cddl/compat/opensolaris > -I/usr/src/sys/cddl/contrib/opensolaris/uts/common -I/usr/src/sys > -DHAVE_KERNEL_OPTION_HEADERS -include > /usr/obj/usr/src/amd64.amd64/sys/MYKERNEL/opt_global.h -I. -I/usr/src/sys > -I/usr/src/sys/contrib/ck/include -fno-common -g -fno-omit-frame-pointer > -mno-omit-leaf-frame-pointer > -fdebug-prefix-map=./machine=/usr/src/sys/amd64/include > -fdebug-prefix-map=./x86=/usr/src/sys/x86/include > -I/usr/obj/usr/src/amd64.amd64/sys/MYKERNEL -MD > -MF.depend.prototype.o -MTprototype.o -mcmodel=kernel -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__=__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-format-zero-length -mno-aes -mno-avx > -std=iso9899:1999 -include > /usr/src/sys/cddl/compat/opensolaris/sys/debug_compat.h -c > /usr/src/sys/cddl/dev/prototype.c -o prototype.o > --- all_subdir_iir --- > --- iir.ko.debug --- > objcopy --only-keep-debug iir.ko.full iir.ko.debug > --- iir.ko --- > objcopy --strip-debug --add-gnu-debuglink=iir.ko.debug iir.ko.full iir.ko > --- all_subdir_ipdivert --- > /usr/src/sys/netinet/ip_divert.c:374:7: error: use of undeclared > identifier 'IPV6_VERSION' >          case IPV6_VERSION >> 4: >               ^ > --- all_subdir_ipfilter --- > ===> ipfilter (all) > [Creating objdir > /usr/obj/usr/src/amd64.amd64/sys/MYKERNEL/modules/usr/src/sys/modules/ipfilter...] > --- all_subdir_ipdivert --- > 1 error generated. > *** [ip_divert.o] Error code 1 > > make[4]: stopped in /usr/src/sys/modules/ipdivert > 1 error > > make[4]: stopped in /usr/src/sys/modules/ipdivert > *** [all_subdir_ipdivert] Error code 2 > > _______________________________________________ > 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 Jan 26 14:25:58 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8D02323FB5F for ; Sun, 26 Jan 2020 14:25:58 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 485FY13K1Tz45Cr for ; Sun, 26 Jan 2020 14:25:57 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: by mail-lj1-x231.google.com with SMTP id r19so7893880ljg.3 for ; Sun, 26 Jan 2020 06:25:57 -0800 (PST) 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=ych0qtejfbFVxVoYk3Ltp6lY3R75ZXz9ZWSKKL2Vo8c=; b=TXQbva0gnDs3Y7MWaR878n/aYuHkqzgRtlNNOTsZMYr7UR2v5TUboLbB1gWQkvvqqx y2UzuIAycfLkfCH2isz+4wX2q8KdrmQSn+v6QALjsibR6KSEfRGgUtPxoVB8mZXxW2mZ ML6jaeY8N5QAXEDVum1/5dffMAX72q/NUWsoj/2UOAbNw9I+UtXXx3N6bQHa0/9tAQ8Q X64YzJAOO5Gk1JIhQnkadUSeU4//DoxTRQTB9HuMq9BzFOlV/faJebPImgdn2tAGdpv0 srawhP06Bm1Aq2UmeIzkz45W+WBjXryCHxoaSaasbdsmfVW8VC50+f2u56zsC2SvwEL2 cn2Q== 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=ych0qtejfbFVxVoYk3Ltp6lY3R75ZXz9ZWSKKL2Vo8c=; b=NxM0vwOmUBhwowKRKowf/PzUaWSPH0eyFX2IuzBVvt4TMRHPgZ0Ika/466AOWtI28o ac5IGv7jYXRrR+26LdDsMUF0fwihflYv7C6i8vWaZJ7UEgMG8JVhW2XHtJpDxE2EHBdB 4d74iRLDbs14Rz3yiw309p5lrx+CzLornttJN067Nm0OSKQa3rrwKhnl45mhLq/92oyH KtugrwPYYo6OC2o7iNiE+Wm1C6IbtFfXPdyrZFzpBvezLf7INMOhsnNvsU5ZiXpj5f9t uczJR6pRtkH1MayoSlg/H0mK+ahBY8n0o7ZR/Jeh4Pi1QX3GmruCd0AZdnxPbKiRokVB LsTg== X-Gm-Message-State: APjAAAUISywnH2FwfS9QByyuPBSXLp1gSFmSp1bkRAeC8n/1YzOa/AqY 4e0S/Kg8h1exrEFbDBEX0vzudMfi2H4j46PVCejFoUtm X-Google-Smtp-Source: APXvYqybdunwyoRA7UDmn91UcE9SvdFd4KhQhOhfQBuUJ02cdo3y4FUYRc2AZEerYAjF1tqeWRLbIgOABsTdoDtHyJA= X-Received: by 2002:a2e:8145:: with SMTP id t5mr7686366ljg.144.1580048755252; Sun, 26 Jan 2020 06:25:55 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Andreas Nilsson Date: Sun, 26 Jan 2020 15:25:46 +0100 Message-ID: Subject: Re: hwpstate_intel hangs kernel To: Current FreeBSD X-Rspamd-Queue-Id: 485FY13K1Tz45Cr X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=TXQbva0g; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of andrnils@gmail.com designates 2a00:1450:4864:20::231 as permitted sender) smtp.mailfrom=andrnils@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(0.00)[ip: (-9.31), ipnet: 2a00:1450::/32(-2.54), asn: 15169(-1.79), country: US(-0.05)]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[1.3.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 26 Jan 2020 14:25:58 -0000 On Fri, Jan 24, 2020 at 5:52 PM Andreas Nilsson wrote: > Hello, > > I updated my sources from 20200113 to 20200124 and after that my laptop > hangs during boot. > > The machine is a Lenovo Thinkpad X1 yoga with a core i7-6500U cpu and 8Gb > ram. > > It hangs during kernel boot and the last message printed on console is: > hwpstate_intel0: on cpu0 > > I reverted commits > 1c59e40a6928d0e50272f3653cc3be27a94d8ea3 > 0a0670f4aee197f46e40fda8b1c58f15fa882043 > a4e3b5b685179d1576933ac5e67719dfe96efdea > and recompiled the kernel, which then boots just fine. > > Interestingly, the hwpstate_intel code worked fine on my workstation, with > a Intel i7-7700 cpu. > > I set debug.hwpstate_verbose=1 in loader.conf in hopes of getting more > info, but I could not see any additional information. > > Best regards > Andreas > There seems to be further problems: My workstation has since hung, I'm on my way to the office to check it out now. My laptop with the hwpstate patches reverted has also hung, so that issue might be due to another commit. Best regards Andreas From owner-freebsd-current@freebsd.org Sun Jan 26 17:45:50 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id AFE421F5711 for ; Sun, 26 Jan 2020 17:45:50 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.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 485Kzd5N9yz4Jhb for ; Sun, 26 Jan 2020 17:45:49 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 00QHjlTv044007; Sun, 26 Jan 2020 09:45:47 -0800 (PST) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 00QHjkuW044006; Sun, 26 Jan 2020 09:45:46 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202001261745.00QHjkuW044006@gndrsh.dnsmgr.net> Subject: Re: After update to r357104 build of poudriere jail fails with 'out of swap space' In-Reply-To: <202001252359.00PNx6n1007151@slippy.cwsent.com> To: Cy Schubert Date: Sun, 26 Jan 2020 09:45:46 -0800 (PST) CC: sgk@troutmask.apl.washington.edu, freebsd-current@freebsd.org, Mark Millard , yasu@utahime.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 485Kzd5N9yz4Jhb X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd-rwg@gndrsh.dnsmgr.net has no SPF policy when checking 69.59.192.140) smtp.mailfrom=freebsd-rwg@gndrsh.dnsmgr.net X-Spamd-Result: default: False [2.56 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; RCPT_COUNT_FIVE(0.00)[5]; NEURAL_SPAM_MEDIUM(0.73)[0.731,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.90)[0.899,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.03)[ip: (0.13), ipnet: 69.59.192.0/19(0.07), asn: 13868(0.02), country: US(-0.05)]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 26 Jan 2020 17:45:50 -0000 > In message <20200125233116.GA49916@troutmask.apl.washington.edu>, Steve > Kargl w > rites: > > On Sat, Jan 25, 2020 at 02:09:29PM -0800, Cy Schubert wrote: > > > On January 25, 2020 1:52:03 PM PST, Steve Kargl > on.edu> wrote: > > > >On Sat, Jan 25, 2020 at 01:41:16PM -0800, Cy Schubert wrote: > > > >> > > > >> It's not just poudeiere. Standard port builds of chromium, rust > > > >> and thunderbird also fail on my machines with less than 8 GB. > > > >> > > > > > > > >Interesting. I routinely build chromium, rust, firefox, > > > >llvm and few other resource-hunger ports on a i386-freebsd > > > >laptop with 3.4 GB available memory. This is done with > > > >chrome running with a few tabs swallowing a 1-1.5 GB of > > > >memory. No issues. > > > > > > Number of threads makes a difference too. How many core/threads does your l > > aptop have? > > > > 2 cores. > > This is why. > > > > > > Reducing number of concurrent threads allowed my builds to complete > > > on the 5 GB machine. My build machines have 4 cores, 1 thread per > > > core. Reducing concurrent threads circumvented the issue. > > > > I use portmaster, and AFIACT, it uses 'make -j 2' for the build. > > Laptop isn't doing too much, but an update and browsing. It does > > take a long time especially if building llvm is required. > > I use portmaster as well (for quick incidental builds). It uses > MAKE_JOBS_NUMBER=4 (which is equivalent to make -j 4). I suppose machines > with not enough memory to support their cores with certain builds might > have a better chance of having this problem. > > MAKE_JOBS_NUMBER_LIMIT to limit a 4 core machine with less than 2 GB per > core might be an option. Looking at it this way, instead of an extra 3 GB, > the extra 60% more memory in the other machine makes a big difference. A > rule of thumb would probably be, have ~ 2 GB RAM for every core or thread > when doing large parallel builds. Perhaps we need to redo some boot time calculations, for one the ZFS arch cache, IMHO, is just silly at a fixed percent of total memory. A high percentage at that. One idea based on what you just said might be: percore_memory_reserve = 2G (Your number, I personally would use 1G here) arc_max = MAX(memory size - (Cores * percore_memory_reserve), 512mb) I think that simple change would go a long ways to cutting down the number of OOM reports we see. ALSO IMHO there should be a way for sub systems to easily tell zfs they are memory pigs too and need to share the space. Ie, bhyve is horrible if you do not tune zfs arc based on how much memory your using up for VM's. Another formulation might be percore_memory_reserve = alpha * memory_zire / cores Alpha most likely falling in the 0.25 to 0.5 range, I think this one would have better scalability, would need to run some numbers. Probably needs to become non linear above some core count. > Cy Schubert -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-current@freebsd.org Sun Jan 26 20:08:28 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E0C3F1F9C08 for ; Sun, 26 Jan 2020 20:08:28 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-to1can01on061e.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe5d::61e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 485P8C25DYz4Rk4; Sun, 26 Jan 2020 20:08:26 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WUZ2umTp9QKhMDoM8u6HmOAC2Om55XYKdNwnfrGR310QHM+tvw1UAYKOgaSREQK7b9vIFKkWX4+c2ojL5zsx4/3mBGM37Ecr08c1B5NKAk5BBlCazQaEvWPSrn8OUhzf1iNRIrHdLUkVNcf4BzwOQjTSUxkYyqPcJ3zCHEgI7u/SYUeaKeSnenjVtDexCei6TKVRgkphAzOiGhZQ/ofqKdqddFl6gAZ0wbepCzlbaVM3BGOsOozXby9hf2gmjNQmDlvUlImsaZ8/IKpfujbJXA1hMeki3Udkb4sY+EOci6nkLNx1r+c0VwPsm/wUWQt+2/VBU/Mt9OaXU++l1ZJ8RQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=agFfBABy7TtdJq/Bou2AUfLvBLfYCaWDrz9gBqnyCPM=; b=V6cAfFSFB8UJ/SKIQpAet10TmvWAGg3VHNKUGYAWHBqFwewAVyj1QhsjMNAzmt65iPBD14V7uGgwuym5Q8mkKXa9BS5BAYfvdD2VlHBOW32UU6aBQXQvZleHJruLHWkPXn31klliKvIRZLrscNJPZPtYptCrGmEPleqWyIofscecWRDn8d1NoELxjkJzxpaunqU7pfSQhuZnCte4wQi86Q31EgtB3UWSakqD4Q9IpKFots00ddSRhcWc/3R1iwZCEzEYGH4aq+FoegCU4d3Q1TZuD+/TH4/jAQfekd6NApcNalSCLsNeqfxLCup6GV4ZFiPiegw7aGoKDytGeAMC6w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none Received: from YQBPR0101MB1427.CANPRD01.PROD.OUTLOOK.COM (52.132.69.153) by YQBPR0101MB0820.CANPRD01.PROD.OUTLOOK.COM (52.132.66.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.23; Sun, 26 Jan 2020 20:08:25 +0000 Received: from YQBPR0101MB1427.CANPRD01.PROD.OUTLOOK.COM ([fe80::6588:45c3:4892:f98]) by YQBPR0101MB1427.CANPRD01.PROD.OUTLOOK.COM ([fe80::6588:45c3:4892:f98%7]) with mapi id 15.20.2665.017; Sun, 26 Jan 2020 20:08:25 +0000 From: Rick Macklem To: John Baldwin , "freebsd-current@FreeBSD.org" Subject: Re: how to use the ktls Thread-Topic: how to use the ktls Thread-Index: AQHVxa2HeRfmo36hWEyrGcMaBhE88KfhEeoAgBxnlpk= Date: Sun, 26 Jan 2020 20:08:25 +0000 Message-ID: References: , <5be57c87-90fe-fcbe-ea37-bdb1bcff2da8@FreeBSD.org> In-Reply-To: <5be57c87-90fe-fcbe-ea37-bdb1bcff2da8@FreeBSD.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ac21c625-e933-437d-20d7-08d7a29b803d x-ms-traffictypediagnostic: YQBPR0101MB0820: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5797; x-forefront-prvs: 02945962BD x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39860400002)(376002)(136003)(396003)(366004)(189003)(199004)(71200400001)(66556008)(66476007)(66946007)(64756008)(8936002)(66446008)(110136005)(316002)(786003)(5660300002)(81156014)(81166006)(8676002)(7696005)(2906002)(76116006)(9686003)(55016002)(478600001)(186003)(33656002)(450100002)(86362001)(6506007)(52536014); DIR:OUT; SFP:1101; SCL:1; SRVR:YQBPR0101MB0820; H:YQBPR0101MB1427.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Vq54Er8ACAHCyRwQUH07PsFQMnuPUz5Ia2xggjlxJo3uwSmZmzx5QBPeTotZwplLDEzsI0mQKynJe+e8wXRXDAVFuUOMEZK9Pvsj01mPS4u9Wsf7Pw+BCLU+mp7Z13D2HP4QEwtohJJBpVQxOx6ADbPwULsSY5Y6y2l6RrA9H+TmqHw5WWkwhFK6Ci2XvDu3fwCiQTGflBRQuHw4P6cGbn36ej4oaA8nbnzWPsY5y7dVrYLhPZWjq9bn+EPam7o/TLtmLEgeO3OWO5y83PKaHPpmyIpq3j4NjkgrfRJwfXTcZyBHEME5c9AdAbGu/DpOsIWmuukMncwHBxwIjyP6wLXnK1YLt7ac7q8SWpIzrTWQG61I94LlMzLa4sRXRyXGnDKlfx+8URZRjWH4mXlrEPYZHon1nYfcucOmi/wlwNdm1t4tvV5ReqKdGXrQa9vf x-ms-exchange-antispam-messagedata: WEok+WQLlgVVgTiPrY0C86VFaQQ5gp6Uib9mFxMaCG5scDS9c3zEaSj/9j8Y8UtMf7uM5eLMtU1FLXGfjQcIJdUyPPdnj8XolP0op+0vffgF3sFvHdDWJBEMqrFrdOP5ckwZXV97ZyCfW5oLhtHzlEPLynzYnL5nfvVp+1Mx3g9jBM+nrE962vVVpw6oa/lByippxR7cpm8j2gAUjKIHVQ== x-ms-exchange-transport-forked: True 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: ac21c625-e933-437d-20d7-08d7a29b803d X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jan 2020 20:08:25.0855 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: oOwamABIWonIMvqbMgQFfWdmK1N1DJxJhr6aRzeWGjZ1A6fiHOgpv15DNs1UzMwxlK/TfM4U6sGdxYxrenx/aQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQBPR0101MB0820 X-Rspamd-Queue-Id: 485P8C25DYz4Rk4 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 2a01:111:f400:fe5d::61e as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-4.68 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a01:111:f400::/48]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[uoguelph.ca]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[3]; IP_SCORE(-1.38)[ipnet: 2a01:111:f000::/36(-3.83), asn: 8075(-3.04), country: US(-0.05)]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:8075, ipnet:2a01:111:f000::/36, country:US]; ARC_ALLOW(-1.00)[i=1] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 26 Jan 2020 20:08:28 -0000 John Baldwin wrote:=0A= [stuff snipped]=0A= >Hmmm, this might be a fair bit of work indeed.=0A= >=0A= >Right now KTLS only works for transmit (though I have some WIP for receive= ).=0A= >=0A= >KTLS does assumes that the initial handshake and key negotiation is handle= d by=0A= >OpenSSL. OpenSSL uses custom setockopt() calls to tell the kernel which= =0A= >session keys to use.=0A= >=0A= >I think what you would want to do is use something like OpenSSL_connect() = in=0A= >userspace, and then check to see if KTLS "worked". If it did, you can tel= l=0A= >the kernel it can write to the socket directly, otherwise you will have to= =0A= >bounce data back out to userspace to run it through SSL_write() and have= =0A= >userspace do SSL_read() and then feed data into the kernel.=0A= >=0A= >The pseudo-code might look something like:=0A= >=0A= >SSL *s;=0A= >=0A= >s =3D SSL_new(...);=0A= >=0A= >/* fd is the existing TCP socket */=0A= >SSL_set_fd(s, fd);=0A= >OpenSSL_connect(s);=0A= >if (BIO_get_ktls_send(SSL_get_wbio(s)) {=0A= > /* Can use KTLS for transmit. */=0A= >}=0A= >if (BIO_get_ktls_recv(SSL_get_rbio(s)) {=0A= > /* Can use KTLS for receive. */=0A= >}=0A= =0A= So, I've been making some progress. The first stab at the daemons that do t= he=0A= handshake are now on svn in base/projects/nfs-over-tls/usr.sbin/rpctlscd an= d=0A= rpctlssd.=0A= =0A= A couple of questions...=0A= 1 - I haven't found BIO_get_ktls_send() or BIO_get_ktls_recv(). Are they in= some=0A= different library?=0A= 2 - After a successful SSL_connect(), the receive queue for the socket has = 478bytes=0A= of stuff in it. SSL_read() seems to know how to skip over it, but I ha= ven't=0A= figured out a good way to do this. (I currently just do a recv(..478,0= ) on the=0A= socket.)=0A= Any idea what to do with this? (Or will the receive side of the ktls f= igure out=0A= how to skip over it?)=0A= =0A= I'm currently testing with a kernel that doesn't have options KERN_TLS and= =0A= (so long as I get rid of the 478 bytes), it then just does unencrypted RPCs= .=0A= =0A= So, I guess the big question is.... can I get access to your WIP code for K= TLS=0A= receive? (I have no idea if I can make progress on it, but I can't do a lot= more=0A= before I have that.)=0A= =0A= Oh, and for anyone out there...=0A= What is the easiest freebie way to test signed certificates?=0A= (I currently am using a self-signed certificate, but I need to test the "re= al" version=0A= at some point soon.)=0A= =0A= Thanks, rick=0A= =0A= =0A= --=0A= John Baldwin=0A= From owner-freebsd-current@freebsd.org Mon Jan 27 00:27:41 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6CEDA2295CB for ; Mon, 27 Jan 2020 00:27:41 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-25.consmr.mail.gq1.yahoo.com (sonic304-25.consmr.mail.gq1.yahoo.com [98.137.68.206]) (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 485VvJ1VlVz4gGs for ; Mon, 27 Jan 2020 00:27:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: PYpnngIVM1lSBQoFLxSIv.i1mfkfhEcSuqbLw46wGEQPA_Mj0zYkgHif9uRV8Z8 ORWPPNvw1KWNHDG2zFfbf09NdkiTr5Y0HB8_uDC5K_Hg6t7t1mxgYwgbgBdff8MJaipV2KNbl7XK 2Zlq5Jk0Oq5FSAGY.UIynMhoxgEwNVeO2Hd9g4ppkRJlYqyLghCh7lxn9wsOJ.kk8zeZ7TAgTeQB BVxSnje6HXMetbALFMJvHldOxdjCd.JGf3J.74kJLisYuwr0JH09tsaPVKs5dxoeNeI2k2SvMkzp 2i2nTYVE7VG5ml51GR6vfSoIBSwMXtpIwsHcC8kuF_Joe8CV7y2yR2CgyGtyI.2fNmHpADvc92k9 no9iG7KarsoSK9_DhstA1qbOI0zik5Oiw29j09JP8k6uyGxlzCWtXRnNMaA_uf6NYQ0B2ASMMlR2 HotKfIBuKZXv5BgVclW0CqGa.pwY4KE8awf_ghQmcrzwzvrmPWz6Ukqs0ES_CDyO5_UGNhmsvuVK 2jDDEuxziHlxfSn1.tLPpyjoS3OoqCQJ.xEDObU91JXh1qN1WLUbhZedYNKiKGrOTiFkpqSA58gW UjX2xnU1loQ.iKCopZs91tey9_z3TRB0bG.hWrOHbsZZch.f8v0l8RwwLb9vM.OSYG.M_rblhlqc uPL0irpCNaJ1iByNiiFqgTcOQP3WDG9KCWSkDAJhfIgT.CBkQj8lLuY7w15A4.JqXgo5DS5kOeaY PJwk41OMM72AxGANwPctvSzZ64YUFsOcqXOeKPca9llnB0IpbPlrLt22urHqjiEp9YX9zeSyyp4n pIUc5BDkn3yfu1lfvSsjbuym01OyCNNl7t3kh.ID.q_MIA.dh7eUx6nEQ96p1_qZ8BFJk75lE7Ku auY3BLRUFWYStAIvZcXedWjvLETSu3jAMwqDKYpL03skQwQYJ.qLOtOUz6QGKFJfRJDm08ai5AMP mSzwha1KI.Qtfs0XIOlCZkRomrpE3x2QN3PF2OhcP0s4_Ykh65X5mzWotwVOYnn4b1w8ToADledC RYMgxRZ.lYjcYPxNbegwq071VQN7losNaWDi696AwaYzZKUAoHMYVN2WfkvZS7ctIq_lEHQTBVPH 8ZbyBmPNd.E3jZEuy6xZ400qtZtC2M6mZnudDkfsbpzMORJwnzfM_Kdl6ItJBI16qAuu4Adjqr6O 3ZPFHjsdIKLOqliUbSuIuCDR4N3cgW8_G37uBpYd.PruXFl_CC1rweDNSQN4.Bu2k1qiLZ.H4Pqx nKBCZXJYlXrHF19BUNwHtFEwuuE1frG3GVmg2qOu7aP1dOAlOB2CWkHsn1WQqNAKDUkOO9iNv3vE P7UCBMW6j_cqpgK2fHMICAjnti4ACfvRs60bydBW.nNFqdebOqKsvrisfpXoAU6JVQuh9E.gztwp .J8R7tSd3dz4wsll3AmNOlcPIzm5NxjH5GHKprz798BE- Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Mon, 27 Jan 2020 00:27:38 +0000 Received: by smtp412.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 5f2db6ab55161ced436e38e005dcafd7; Mon, 27 Jan 2020 00:27:35 +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 13.0 \(3608.40.2.2.4\)) Subject: Re: r356776 breaks kernel for powerpc64 users Message-Id: <2EEA029D-2C24-42F2-A347-69813B928BC4@yahoo.com> Date: Sun, 26 Jan 2020 16:27:35 -0800 To: listy@anongoth.pl, FreeBSD Current X-Mailer: Apple Mail (2.3608.40.2.2.4) References: <2EEA029D-2C24-42F2-A347-69813B928BC4.ref@yahoo.com> X-Rspamd-Queue-Id: 485VvJ1VlVz4gGs X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.05 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.71)[-0.711,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-0.84)[-0.838,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (0.83), ipnet: 98.137.64.0/21(0.84), asn: 36647(0.67), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[206.68.137.98.list.dnswl.org : 127.0.5.0]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 27 Jan 2020 00:27:41 -0000 Piotr Kubaj listy at anongoth.pl wrote on Thu Jan 16 19:56:11 UTC 2020 : > revision 356776 breaks booting for powerpc64 users. It reportedly = works fine on POWER8, but I get kernel panic on POWER9 (Talos II) right = after the usual warning: WITNESS enabled. Kernel panic is uploaded to = https://pastebin.com/s8ZaUNS2. >=20 >=20 > @jeff > Since you commited this patch, can you fix this issue or revert this = commit? >=20 Is this still a problem for powerpc64? I've not seen anything looking like a direct response or like a status update for this. I do see arm report(s) of problems that they also attributed to head -r356776 . But I've no clue how good the evidence is generally. An example message is: https://lists.freebsd.org/pipermail/freebsd-arm/2020-January/021069.html But one part of that is for specifically for going from -r356767 to the next check-in to head: -r356776 . That problem likely has good evidence for the attribution to -r356776 . =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Mon Jan 27 02:25:15 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A1CF522C870 for ; Mon, 27 Jan 2020 02:25:15 +0000 (UTC) (envelope-from dclarke@blastwave.org) Received: from mail.oetec.com (mail.oetec.com [108.160.241.186]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.oetec.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 485YVy2Nphz3HLc for ; Mon, 27 Jan 2020 02:25:13 +0000 (UTC) (envelope-from dclarke@blastwave.org) X-Spam-Status: No X-oetec-MailScanner-From: dclarke@blastwave.org X-oetec-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1.199, required 6, autolearn=not spam, ALL_TRUSTED -1.00, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, DKIM_VALID_EF -0.10, URIBL_BLOCKED 0.00) X-oetec-MailScanner: Found to be clean X-oetec-MailScanner-ID: 00R2P1gD000951 X-oetec-MailScanner-Information: Please contact oetec for more information Received: from [172.16.35.3] (CPEf81d0f84cb23-CMf81d0f84cb20.cpe.net.cable.rogers.com [99.253.169.68]) (authenticated bits=0) by mail.oetec.com (8.15.2/8.15.2/Debian-8) with ESMTPSA id 00R2P1gD000951 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Sun, 26 Jan 2020 21:25:02 -0500 Subject: Re: r356776 breaks kernel for powerpc64 users To: freebsd-current@freebsd.org References: <2EEA029D-2C24-42F2-A347-69813B928BC4.ref@yahoo.com> <2EEA029D-2C24-42F2-A347-69813B928BC4@yahoo.com> From: Dennis Clarke Message-ID: <6f8b8c41-b712-ccb0-1655-0a2e1cfc8bf7@blastwave.org> Date: Sun, 26 Jan 2020 21:25:01 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:72.0) Gecko/20100101 Thunderbird/72.0 MIME-Version: 1.0 In-Reply-To: <2EEA029D-2C24-42F2-A347-69813B928BC4@yahoo.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 485YVy2Nphz3HLc X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.17 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[blastwave.org:s=default]; NEURAL_HAM_MEDIUM(-0.75)[-0.755,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.94)[-0.938,0]; IP_SCORE(0.52)[asn: 812(2.68), country: CA(-0.09)]; DKIM_TRACE(0.00)[blastwave.org:+]; DMARC_POLICY_ALLOW(-0.50)[blastwave.org,quarantine]; RECEIVED_SPAMHAUS_PBL(0.00)[68.169.253.99.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:812, ipnet:108.160.240.0/20, country:CA]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 27 Jan 2020 02:25:15 -0000 On 2020-01-26 19:27, Mark Millard wrote: > Piotr Kubaj listy at anongoth.pl wrote on > Thu Jan 16 19:56:11 UTC 2020 : > >> revision 356776 breaks booting for powerpc64 users. It reportedly works fine on POWER8, but I get kernel panic on POWER9 (Talos II) right after the usual warning: WITNESS enabled. Kernel panic is uploaded to https://pastebin.com/s8ZaUNS2. >> >> >> @jeff >> Since you commited this patch, can you fix this issue or revert this commit? >> > > Is this still a problem for powerpc64? I've not seen > anything looking like a direct response or like a > status update for this. > > I do see arm report(s) of problems that they also > attributed to head -r356776 . But I've no clue how > good the evidence is generally. An example message > is: > > https://lists.freebsd.org/pipermail/freebsd-arm/2020-January/021069.html > > But one part of that is for specifically for going > from -r356767 to the next check-in to head: -r356776 . > That problem likely has good evidence for the > attribution to -r356776 . > I will give current a try and report back. However I am hesitant to do so as I have a working G5 right now. For science ... I will do the experiment. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional From owner-freebsd-current@freebsd.org Mon Jan 27 05:37:19 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 751C8231F37 for ; Mon, 27 Jan 2020 05:37:19 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-22.consmr.mail.gq1.yahoo.com (sonic309-22.consmr.mail.gq1.yahoo.com [98.137.65.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 485dmZ2cxKz3xCB for ; Mon, 27 Jan 2020 05:37:18 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: .BqASKYVM1mUxwlOwMqGcJ4sRYQVFj3i9AboXzbZ51hJjAjHWWXwrqNofBXBy2I ijRmtN7mZxUergLQJTkhpylCAYVt3ap2QBAI6KIm0TohjlBif2y0Mp44zlHw1fK99fkn0u9jmd4m 4R_eJvh3KEEqEAyiR.XC8Kwf81sEAYRrUMfCAKli2IhWZbB8q5_vVfaDA9vfv8nj0QwoHdIudWBR PD6qv5u02MTPN5bt2RanlB8n_vnmlDondWVyLcNL6hBFe3lw78ThIYafIsowPvZHDIoalnaBCTTg pswcCVODk6z7K.WTU37RMsJ1qkYNrtC.RXJds9ykP79HNqLtbofo2tI77kWq1w9AbMAJS338TXXp 7d53TEhRk_rvq3lG99LUcao9wV9YfQw.29kL6QWWr97lzZ6pJQtFKgBsXOtjgd7XIXVi.xQhFHNu flgj7gfZXCGKpbKyK1miPWuOW8x1WiQ7n3lDmfOJ5y0ANrORLidXRoGhQsJe89m41lcvUorwk7qG SqfPgzT4FB7xMu2ndx07fNWIu64VJmA9ustvLzeTkGlc_hg6PG_RLseZUgUuWcueVk56mCFYud5B 3SquotmMr6V7b7OJ9B42o7t.V5UGmbouRBWI4QCZ9_FYgEyNvyrnwVeIJ_IohCWs0SEydqmg1Pa5 ihur4Pm6NH_rV4brVWcTPuetFkkg12SEIi.PxDUQE2LJauX13TASMakSzKEcTeoKZtwfqDEyVtBc gitIyUWgYYQUTlsmF3bz3N44ik3vrHKS1HNwYc5pGrlCFNga94cWTd_LtGAy9RVplpXEhqbOLwuC Fxotxv4TayRjHVyC2bd8Bzu_AE3I6FNhfoB3z4TImT_3nG3Sk34vd8pdL6zbo7QTl.3mE9KcrxbN xuTHIVEQ49orCDdGdTf35xHbS__YHohsnm.ZdrpQs5m.sTwA2M2kvRzxMoSdqJjjlXM6QWsRrync tYFtMzu4Kyct3v.LFfXz_TRb.Kj9pSiLakIsU_ejxnq8mug5DzCt0WGgWaC8Wx4mWyM8CrMNqPaw 0qUnSb266H3Xjkidi9A6zTvVLq0LE4PPT._qREvz_uMb9oyyvZpoEn1sdoWKYdruxc5rjPbvxb9j D1ms3n8etpYUciVfLfLAQXrt33FrxgGifF2eTmRvRPz_TbPGXicvkTUwnMclRyt7Zq1Bu6LuynKv KxFqaLnFmF8t5E_pavKAPoM1jcL_eFOcfEz.3oI1PmY3wHhjwJmg8kXbYlPh1WXtQpK7db4LjpcK I.WJ33G_rXtXCfX2WNYWhU1_HgzbNjRctzUFZMdH51W0M3KzgUK84XyBxADgDxI7QFKGNs8cFFa_ YkTSbTDmevFliklMDM5SGXufIBOdm8WbnH1XKwu7SDUDoLLBjc2SxMpXTsT6jFUHOcf4.c8092qj 1bsO1d3nTDC5qtjoIDatliGZvMayki.lQTaGiBcXaAO7u.uHBumCQYm_XWGS6qKqo6H1nXlA- Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Mon, 27 Jan 2020 05:37:16 +0000 Received: by smtp422.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID c89559f5babdf9fe5c937eee5f910f76; Mon, 27 Jan 2020 05:37:11 +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 13.0 \(3608.40.2.2.4\)) Subject: Re: r356776 breaks kernel for powerpc64 users Message-Id: Date: Sun, 26 Jan 2020 21:37:10 -0800 To: Dennis Clarke , FreeBSD Current X-Mailer: Apple Mail (2.3608.40.2.2.4) References: X-Rspamd-Queue-Id: 485dmZ2cxKz3xCB X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.49 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.993,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_GOOD(-0.10)[text/plain]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; RCVD_COUNT_TWO(0.00)[2]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[148.65.137.98.list.dnswl.org : 127.0.5.0]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.00)[ip: (-1.77), ipnet: 98.137.64.0/21(0.84), asn: 36647(0.67), country: US(-0.05)]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 27 Jan 2020 05:37:19 -0000 Dennis Clarke dclarke at blastwave.org wrote on Mon Jan 27 02:25:15 UTC 2020 : > On 2020-01-26 19:27, Mark Millard wrote: > > Piotr Kubaj listy at anongoth.pl wrote on > > Thu Jan 16 19:56:11 UTC 2020 : > >=20 > >> revision 356776 breaks booting for powerpc64 users. It reportedly = works fine on POWER8, but I get kernel panic on POWER9 (Talos II) right = after the usual warning: WITNESS enabled. Kernel panic is uploaded to = https://pastebin.com/s8ZaUNS2. > >> > >> > >> @jeff > >> Since you commited this patch, can you fix this issue or revert = this commit? > >> > >=20 > > Is this still a problem for powerpc64? I've not seen > > anything looking like a direct response or like a > > status update for this. > >=20 > > I do see arm report(s) of problems that they also > > attributed to head -r356776 . But I've no clue how > > good the evidence is generally. An example message > > is: > >=20 > > = https://lists.freebsd.org/pipermail/freebsd-arm/2020-January/021069.html > >=20 > > But one part of that is for specifically for going > > from -r356767 to the next check-in to head: -r356776 . > > That problem likely has good evidence for the > > attribution to -r356776 . > >=20 >=20 > I will give current a try and report back. However I am hesitant to do=20= > so as I have a working G5 right now. >=20 > For science ... I will do the experiment. If Piotr has a context that fairly reliably gives the problem still, you might want to wait until it starts working. Especially if you can not keep a bootable copy of your working environment. I've not heard one way or the other for any PowerMacs. Piotr indicated some POWER8 contexts did not get the problem that he got on POWER9. Also, unfortunately, head -r356899 eliminated the old binutils as program but powerpc64 can still require it for an (empty!) crtsavres.s assembly. powerpc64 probably needs to be changed to avoid using an external assembler for anything, even indirectly via system-clang reaching into /usr/local/ if it does so. (Otherwise an external toolchain is still required.) Of course, if one is not building from source, this is not an issue. Another issue is that the "epoch" usage changes seem to have lead to a fair number of crash problems as the various places gradually are updated to use it the new way but do not fully work prior to their updates. (It is just an impression of what I've read but not dealt with: I might have summarized incorrectly.) These and -r536776 related material have overlapping time frames, so it may be things are odd until all 3 areas have been taken care of sufficiently. I'm still holding at head -r356426 as the base version for my activities. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Mon Jan 27 09:45:37 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0ACC61F0DB9 for ; Mon, 27 Jan 2020 09:45:37 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 485lH46YB0z4BSw; Mon, 27 Jan 2020 09:45:36 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from dhcp-10-248-114-204.eduroam.wireless.private.cam.ac.uk (global-5-143.nat-2.net.cam.ac.uk [131.111.5.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 9ED1BF45F; Mon, 27 Jan 2020 09:45:36 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: how to use the ktls To: Rick Macklem , "freebsd-current@FreeBSD.org" References: <5be57c87-90fe-fcbe-ea37-bdb1bcff2da8@FreeBSD.org> From: John Baldwin Message-ID: Date: Mon, 27 Jan 2020 09:45:34 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 27 Jan 2020 09:45:37 -0000 On 1/26/20 8:08 PM, Rick Macklem wrote: > John Baldwin wrote: > [stuff snipped] >> Hmmm, this might be a fair bit of work indeed. >> >> Right now KTLS only works for transmit (though I have some WIP for receive). >> >> KTLS does assumes that the initial handshake and key negotiation is handled by >> OpenSSL. OpenSSL uses custom setockopt() calls to tell the kernel which >> session keys to use. >> >> I think what you would want to do is use something like OpenSSL_connect() in >> userspace, and then check to see if KTLS "worked". If it did, you can tell >> the kernel it can write to the socket directly, otherwise you will have to >> bounce data back out to userspace to run it through SSL_write() and have >> userspace do SSL_read() and then feed data into the kernel. >> >> The pseudo-code might look something like: >> >> SSL *s; >> >> s = SSL_new(...); >> >> /* fd is the existing TCP socket */ >> SSL_set_fd(s, fd); >> OpenSSL_connect(s); >> if (BIO_get_ktls_send(SSL_get_wbio(s)) { >> /* Can use KTLS for transmit. */ >> } >> if (BIO_get_ktls_recv(SSL_get_rbio(s)) { >> /* Can use KTLS for receive. */ >> } > > So, I've been making some progress. The first stab at the daemons that do the > handshake are now on svn in base/projects/nfs-over-tls/usr.sbin/rpctlscd and > rpctlssd. > > A couple of questions... > 1 - I haven't found BIO_get_ktls_send() or BIO_get_ktls_recv(). Are they in some > different library? They only existing currently in OpenSSL master (which will be OpenSSL 3.0.0 when it is released). I have some not-yet-tested WIP changes to backport those changes into the base OpenSSL, but it will also add overhead to future OpenSSL imports perhaps, so it is something I need to work with secteam@ on to decide if it's viable once I have a tested PoC. I will try to at least provide a patch to the security/openssl port to add a KTLS option "soon" that you could use for testing. > 2 - After a successful SSL_connect(), the receive queue for the socket has 478bytes > of stuff in it. SSL_read() seems to know how to skip over it, but I haven't > figured out a good way to do this. (I currently just do a recv(..478,0) on the > socket.) > Any idea what to do with this? (Or will the receive side of the ktls figure out > how to skip over it?) I don't know yet. :-/ With the TOE-based TLS I had been testing with, this doesn't happen because the NIC blocks the data until it gets the key and then it's always available via KTLS. With software-based KTLS for RX (which I'm going to start working on soon), this won't be the case and you will potentially have some data already ready by OpenSSL that needs to be drained from OpenSSL before you can depend on KTLS. It's probably only the first few messsages, but I will need to figure out a way that you can tell how much pending data in userland you need to read via SSL_read() and then pass back into the kernel before relying on KTLS (it would just be a single chunk of data after SSL_connect you would have to do this for). > I'm currently testing with a kernel that doesn't have options KERN_TLS and > (so long as I get rid of the 478 bytes), it then just does unencrypted RPCs. > > So, I guess the big question is.... can I get access to your WIP code for KTLS > receive? (I have no idea if I can make progress on it, but I can't do a lot more > before I have that.) The WIP only works right now if you have a Chelsio T6 NIC as it uses the T6's TCP offload engine to do TLS. If you don't have that gear, ping me off-list. It would also let you not worry about the SSL_read case for now for initial testing. -- John Baldwin From owner-freebsd-current@freebsd.org Mon Jan 27 13:09:17 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 56E381F5D43 for ; Mon, 27 Jan 2020 13:09:17 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 485qp435Qrz4M80 for ; Mon, 27 Jan 2020 13:09:16 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id w48di47BhkqGXw48fiHBM3; Mon, 27 Jan 2020 06:09:14 -0700 X-Authority-Analysis: v=2.3 cv=c/jVvi1l c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=kj9zAlcOel0A:10 a=Jdjhy38mL1oA:10 a=iKhvJSA4AAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=cU3w10EP4QF15qbrk4gA:9 a=jSGmALKL3TXUxhBw:21 a=Tr42tAgKKlysYeKq:21 a=CjuIK1q_8ugA:10 a=7FgKuMUr8FYA:10 a=odh9cflL3HIXMm4fY7Wr:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id BC1B7363; Mon, 27 Jan 2020 05:09:10 -0800 (PST) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id 00RD9ANN005879; Mon, 27 Jan 2020 05:09:10 -0800 (PST) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id 00RD96nr005876; Mon, 27 Jan 2020 05:09:08 -0800 (PST) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <202001271309.00RD96nr005876@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: "Rodney W. Grimes" cc: Cy Schubert , sgk@troutmask.apl.washington.edu, freebsd-current@freebsd.org, Mark Millard , yasu@utahime.org Subject: Re: After update to r357104 build of poudriere jail fails with 'out of swap space' In-reply-to: <202001261745.00QHjkuW044006@gndrsh.dnsmgr.net> References: <202001261745.00QHjkuW044006@gndrsh.dnsmgr.net> Comments: In-reply-to "Rodney W. Grimes" message dated "Sun, 26 Jan 2020 09:45:46 -0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 27 Jan 2020 05:09:06 -0800 X-CMAE-Envelope: MS4wfBzW3U4SwHyQLGfQVmj/Jebr0eFpafaj1NAYteVAdTfB21P0Pdamnqw9bGdiA+FDF0lNJVbjcr7MMBSlgPef+TERZhY4dMsN1NsSKctwVgxgYzOgtskq gXwRS8DU6l27X3xIYeS1bSQBK6SdFVzF8JNHjJJ+qyfH9ojvoVvUKYmXk0yOpJCQ7/SmHpdLwnUF4dDslAz2AbZ463y5Ahg6Yq0e1XMoKHFoqlI5owDyXhm/ Xc8Rv/by2oEA3wcG686OIcjLNMSDCxRvlsRH43GywjJY/z4glen4t/N6RBpLhiCXfQv39c77tAdPP3wLG4q8rjfsTCo1vp7qpb5eospZLOg= X-Rspamd-Queue-Id: 485qp435Qrz4M80 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 64.59.134.13) smtp.mailfrom=cy.schubert@cschubert.com X-Spamd-Result: default: False [-4.15 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCPT_COUNT_FIVE(0.00)[6]; REPLYTO_EQ_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[17.125.67.70.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[13.134.59.64.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; RCVD_TLS_LAST(0.00)[]; IP_SCORE(-2.45)[ip: (-6.53), ipnet: 64.59.128.0/20(-3.18), asn: 6327(-2.47), country: CA(-0.09)]; FROM_EQ_ENVFROM(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 27 Jan 2020 13:09:17 -0000 In message <202001261745.00QHjkuW044006@gndrsh.dnsmgr.net>, "Rodney W. Grimes" writes: > > In message <20200125233116.GA49916@troutmask.apl.washington.edu>, Steve > > Kargl w > > rites: > > > On Sat, Jan 25, 2020 at 02:09:29PM -0800, Cy Schubert wrote: > > > > On January 25, 2020 1:52:03 PM PST, Steve Kargl ingt > > > on.edu> wrote: > > > > >On Sat, Jan 25, 2020 at 01:41:16PM -0800, Cy Schubert wrote: > > > > >> > > > > >> It's not just poudeiere. Standard port builds of chromium, rust > > > > >> and thunderbird also fail on my machines with less than 8 GB. > > > > >> > > > > > > > > > >Interesting. I routinely build chromium, rust, firefox, > > > > >llvm and few other resource-hunger ports on a i386-freebsd > > > > >laptop with 3.4 GB available memory. This is done with > > > > >chrome running with a few tabs swallowing a 1-1.5 GB of > > > > >memory. No issues. > > > > > > > > Number of threads makes a difference too. How many core/threads does yo > ur l > > > aptop have? > > > > > > 2 cores. > > > > This is why. > > > > > > > > > Reducing number of concurrent threads allowed my builds to complete > > > > on the 5 GB machine. My build machines have 4 cores, 1 thread per > > > > core. Reducing concurrent threads circumvented the issue. > > > > > > I use portmaster, and AFIACT, it uses 'make -j 2' for the build. > > > Laptop isn't doing too much, but an update and browsing. It does > > > take a long time especially if building llvm is required. > > > > I use portmaster as well (for quick incidental builds). It uses > > MAKE_JOBS_NUMBER=4 (which is equivalent to make -j 4). I suppose machines > > with not enough memory to support their cores with certain builds might > > have a better chance of having this problem. > > > > MAKE_JOBS_NUMBER_LIMIT to limit a 4 core machine with less than 2 GB per > > core might be an option. Looking at it this way, instead of an extra 3 GB, > > the extra 60% more memory in the other machine makes a big difference. A > > rule of thumb would probably be, have ~ 2 GB RAM for every core or thread > > when doing large parallel builds. > > Perhaps we need to redo some boot time calculations, for one the > ZFS arch cache, IMHO, is just silly at a fixed percent of total > memory. A high percentage at that. > > One idea based on what you just said might be: > > percore_memory_reserve = 2G (Your number, I personally would use 1G here) > arc_max = MAX(memory size - (Cores * percore_memory_reserve), 512mb) > > I think that simple change would go a long ways to cutting down the > number of OOM reports we see. ALSO IMHO there should be a way for > sub systems to easily tell zfs they are memory pigs too and need to > share the space. Ie, bhyve is horrible if you do not tune zfs arc > based on how much memory your using up for VM's. > > Another formulation might be > percore_memory_reserve = alpha * memory_zire / cores > > Alpha most likely falling in the 0.25 to 0.5 range, I think this one > would have better scalability, would need to run some numbers. > Probably needs to become non linear above some core count. Setting a lower arc_max at boot is unlikely to help. Rust was building on the 8 GB and 5 GB 4 core machines last night. It completed successfully on the 8 GB machine, while using 12 MB of swap. ARC was at 1307 MB. On the 5 GB 4 core machine the rust build died of OOM. 328 KB swap was used. ARC was reported at 941 MB. arc_min on this machine is 489.2 MB. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-current@freebsd.org Mon Jan 27 16:40:59 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 78B7A1FB9F5 for ; Mon, 27 Jan 2020 16:40:59 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 485wVL5cwqz4Ytw for ; Mon, 27 Jan 2020 16:40:58 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: by mail-lj1-x229.google.com with SMTP id a13so11393402ljm.10 for ; Mon, 27 Jan 2020 08:40:58 -0800 (PST) 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=oWcMCK2P/gSZ59eqbdptTJW6v8KCzOjWKY6h/qBe4ng=; b=C1W/vmhcgkvDg1/sadrGvUC10Kknu+OF89pdU2/IYekHAtkJ1fM1QwGs6vKjRExo2Z +YFJI5Psn990mxewe6Sy9P/azyN/lGacqhT20pVYfKEnPkNohoND++oP5+1hH/NB4DIn jSBqUB077mcVg7cQpRrxEkflHNTj7rP3L3hx9ODiZNpjUx8Prej4b4xWvx/GHJmoI8CT DT9A3Ydvy0yiebBuQCp6u7yRtUrCLxuOjQ4tpxnLwWysFxKe1Yh/Rrexjlj9rVf4VE/w rs1ThCKmsYDOs96gEj1U0sKqNUQi2fEJgVChR2X9+KFGeQAJ8yrZgiWzvdYC8E4v2Dnu Letw== 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=oWcMCK2P/gSZ59eqbdptTJW6v8KCzOjWKY6h/qBe4ng=; b=TpCJ/2NjPoDGfBSZsJ8p+GLP29iY2Dantr4aksTFJKWd8u4CYytHFxKU/1UAbV1yV/ kZdJj2V/6LsfjBPcERJCAIXySIViZliyGTINirmNiEmNiRrps58w2CddN3Vp8S3Ow8gA V8wAXdlcSNd67V1Fht7nQPdFiegcmA3JHNLLloffZLRut7IVkpXra0qns3zk1gjI0h+s +eH2/yqhZu+bKWuw2R6Tov9vPAZEMfj5nlTtn93J/ZAh4xQpoVoVepKz0kIg74xWFMqb 7lzFPQYcE60dy/h0WN7hOXC4kWKTTK9YO1ZA7wAKS1PtMjl3sRE+ouMK3kgdk2okb2EC shgQ== X-Gm-Message-State: APjAAAWoH+AkhEFk5pcQFGTNTFmtWeKpbebmbbfyrQhbCHQ4s1dO97vD pRr7UF5wne9nzEwyahMSl0jV73rYEjGhqzgTrt/j/A== X-Google-Smtp-Source: APXvYqzM3TTuyINk4MuGlTpLL03p+/M2mlxVZ3NaadBQ63EqmbgBouAG9NJ83Q1Ermt6KbhMA+EEoFjjDnWHjDQ3Eao= X-Received: by 2002:a2e:9013:: with SMTP id h19mr11121148ljg.223.1580143256820; Mon, 27 Jan 2020 08:40:56 -0800 (PST) MIME-Version: 1.0 References: <5be57c87-90fe-fcbe-ea37-bdb1bcff2da8@FreeBSD.org> In-Reply-To: From: Freddie Cash Date: Mon, 27 Jan 2020 08:40:45 -0800 Message-ID: Subject: Re: how to use the ktls To: Rick Macklem Cc: "freebsd-current@FreeBSD.org" X-Rspamd-Queue-Id: 485wVL5cwqz4Ytw X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=C1W/vmhc; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of fjwcash@gmail.com designates 2a00:1450:4864:20::229 as permitted sender) smtp.mailfrom=fjwcash@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[9.2.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; IP_SCORE(0.00)[ip: (-9.24), ipnet: 2a00:1450::/32(-2.52), asn: 15169(-1.78), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 27 Jan 2020 16:40:59 -0000 On Sun, Jan 26, 2020 at 12:08 PM Rick Macklem wrote: > Oh, and for anyone out there... > What is the easiest freebie way to test signed certificates? > (I currently am using a self-signed certificate, but I need to test the > "real" version > at some point soon.) > Let's Encrypt is what you are looking for. Create real, signed, certificates, for free. They're only good for 90 days, but they are easy to renew. There's various script and programs out there for managing Let's Encrypt certificates (certbot, acme.sh, dehydrated, etc). There's a bunch of different bits available in the ports tree. We use dehydrated at work, using DNS for authenticating the cert requests, and have it full automated via cron, managing certs for 50-odd domains (school servers and firewalls). Works great. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-current@freebsd.org Mon Jan 27 16:43:00 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 586A81FBDD9 for ; Mon, 27 Jan 2020 16:43:00 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 485wXg10CCz4ZSx for ; Mon, 27 Jan 2020 16:42:58 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: by mail-lj1-x232.google.com with SMTP id h23so11438207ljc.8 for ; Mon, 27 Jan 2020 08:42:58 -0800 (PST) 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=Q7CzIDqyY71ICUwFz1n7tezqUUjDHh2qePRV8QNQBBw=; b=RxDEi4832lSw8wc+APy1xcs4Gah6pZcURVmKfbHdVxGFAKNNaZrPDiO+LUGQy4dn6S QEqrAC1TKWTRl/lJx9yL9gHRNu6hYr67lQp78mlWnMGAy/gkpdeD3wlu3fQ3aEXzPAz5 NBdmx/bEP8dM7Ctt6OQdmr7+hMN8W4wIimUJjXkwwBqdNUwsKTX/Oit7u4gLHwVmgHaf J2ru/j0tF6ppwSRVviFx5VgP37hgKKIUJll+qTm8yj6NNLE4Mouk+3Yip9S2GrqUtlwK I9+dHJEZvXS+u7qxbADMv4+5eluI6QZDwCBweid288y925qBIwe80g9Q+IwHAi3Z02e7 cy8w== 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=Q7CzIDqyY71ICUwFz1n7tezqUUjDHh2qePRV8QNQBBw=; b=anbFwP3ya4e3oXbdTU52uGQBQnhRX1DvgDr/9CRO5UVK1wdBZqXhlGt+zhDEy08dih fKIDy9KORdcdQhP2g/h4WpNUB5LUeewoVF1w8emfnHTIYbF4PLFqEfNu49IsbW13eW7R KsQpicTiTRPFq33xR2OzipKIPIr66bOPddtBelbURb1u1QdYTdI/i4vaBz86KPkXXZSc loyMGtUpYJwWIOC+W3nrD4SEmEwxnKdSCunlbc62ceVjvD3J5pSPMh7zDKwDWS+H4R0b R0xUHocmAyrIBKCaPehal6liiHL03v0bFVJLaTjPqtQnUmO1Kgs+57c7IaDZX2qUiAJz pxtw== X-Gm-Message-State: APjAAAXzIr1wdmC9J3gG+CRtZSdg4NfXnv4PpANsG0Ia0cuJMU/qr3oz /+SJHCMsQDZihwtTRYk6bRyturtK61I/B3xhEBw= X-Google-Smtp-Source: APXvYqwA5e5228dU2A1VLsmD/jvZDniUDgbcRBx0C/+Pf01GMItv7TRvGB4lSNMFa3Bi6rSgOpEHDOZWLfQGHAjwSgU= X-Received: by 2002:a2e:9013:: with SMTP id h19mr11125973ljg.223.1580143377467; Mon, 27 Jan 2020 08:42:57 -0800 (PST) MIME-Version: 1.0 References: <5be57c87-90fe-fcbe-ea37-bdb1bcff2da8@FreeBSD.org> In-Reply-To: From: Freddie Cash Date: Mon, 27 Jan 2020 08:42:46 -0800 Message-ID: Subject: Re: how to use the ktls To: Rick Macklem Cc: "freebsd-current@FreeBSD.org" X-Rspamd-Queue-Id: 485wXg10CCz4ZSx X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=RxDEi483; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of fjwcash@gmail.com designates 2a00:1450:4864:20::232 as permitted sender) smtp.mailfrom=fjwcash@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; URI_COUNT_ODD(1.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(0.00)[ip: (-9.22), ipnet: 2a00:1450::/32(-2.52), asn: 15169(-1.78), country: US(-0.05)]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2.3.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 27 Jan 2020 16:43:00 -0000 On Mon, Jan 27, 2020 at 8:40 AM Freddie Cash wrote: > On Sun, Jan 26, 2020 at 12:08 PM Rick Macklem > wrote: > >> Oh, and for anyone out there... >> What is the easiest freebie way to test signed certificates? >> (I currently am using a self-signed certificate, but I need to test the >> "real" version >> at some point soon.) >> > > Let's Encrypt is what you are looking for. Create real, signed, > certificates, for free. They're only good for 90 days, but they are easy > to renew. There's various script and programs out there for managing Let's > Encrypt certificates (certbot, acme.sh, dehydrated, etc). There's a bunch > of different bits available in the ports tree. > > We use dehydrated at work, using DNS for authenticating the cert requests, > and have it full automated via cron, managing certs for 50-odd domains > (school servers and firewalls). Works great. > Forgot the link: https://letsencrypt.org -- Freddie Cash fjwcash@gmail.com From owner-freebsd-current@freebsd.org Mon Jan 27 17:01:19 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 686051FCA72 for ; Mon, 27 Jan 2020 17:01:19 +0000 (UTC) (envelope-from listy@anongoth.pl) Received: from mail.anongoth.pl (mail.anongoth.pl [46.248.190.61]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "anongoth.pl", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 485wxp2W2qz4bbw; Mon, 27 Jan 2020 17:01:18 +0000 (UTC) (envelope-from listy@anongoth.pl) Received: from anongoth.pl (unknown [192.168.1.15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: pkubaj@anongoth.pl) by mail.anongoth.pl (Postfix) with ESMTPSA id E2FF454B2C; Mon, 27 Jan 2020 18:01:07 +0100 (CET) Date: Mon, 27 Jan 2020 18:01:06 +0100 From: Piotr Kubaj To: Mark Millard Cc: FreeBSD Current , "jeff@freebsd.org" Subject: Re: r356776 breaks kernel for powerpc64 users Message-ID: <20200127170106.GA35159@KGPE-D16> Mail-Followup-To: Mark Millard , FreeBSD Current , "jeff@freebsd.org" References: <2EEA029D-2C24-42F2-A347-69813B928BC4.ref@yahoo.com> <2EEA029D-2C24-42F2-A347-69813B928BC4@yahoo.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="5mCyUwZo2JvN/JJP" Content-Disposition: inline In-Reply-To: <2EEA029D-2C24-42F2-A347-69813B928BC4@yahoo.com> X-Rspamd-Queue-Id: 485wxp2W2qz4bbw X-Spamd-Bar: ------- X-Spamd-Result: default: False [-7.26 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:46.248.190.61]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; IP_SCORE(-2.86)[ip: (-9.91), ipnet: 46.248.160.0/19(-4.81), asn: 47544(0.34), country: PL(0.07)]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_POLICY_ALLOW(-0.50)[anongoth.pl,reject]; SIGNED_PGP(-2.00)[]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:47544, ipnet:46.248.160.0/19, country:PL]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 27 Jan 2020 17:01:19 -0000 --5mCyUwZo2JvN/JJP Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable No, it's ok now. I didn't report it earlier, because I wasn't sure which re= vision fixed it and jeff didn't reply.=20 On 20-01-26 16:27:35, Mark Millard wrote: > Piotr Kubaj listy at anongoth.pl wrote on > Thu Jan 16 19:56:11 UTC 2020 : >=20 > > revision 356776 breaks booting for powerpc64 users. It reportedly works= fine on POWER8, but I get kernel panic on POWER9 (Talos II) right after th= e usual warning: WITNESS enabled. Kernel panic is uploaded to https://paste= bin.com/s8ZaUNS2. > >=20 > >=20 > > @jeff > > Since you commited this patch, can you fix this issue or revert this co= mmit? > >=20 >=20 > Is this still a problem for powerpc64? I've not seen > anything looking like a direct response or like a > status update for this. >=20 > I do see arm report(s) of problems that they also > attributed to head -r356776 . But I've no clue how > good the evidence is generally. An example message > is: >=20 > https://lists.freebsd.org/pipermail/freebsd-arm/2020-January/021069.html >=20 > But one part of that is for specifically for going > from -r356767 to the next check-in to head: -r356776 . > That problem likely has good evidence for the > attribution to -r356776 . >=20 >=20 > =3D=3D=3D > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) >=20 --5mCyUwZo2JvN/JJP Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEycyIeNkkgohzsoorelmbhSCDnJ0FAl4vF1IACgkQelmbhSCD nJ2hoBAAuJXRIABcIHsa7qmyifWyRNL2okKPwTmWsSLvoQ8gqRvrXylk0FPwa9GZ Qsq7gGC6Osjkv5/KVZbArzhcHR75+pYsxE4GT0QBsfDDqEXSkbI/gfx3dp8DXN/j RAs9tjmiT/W9Fcd7kSlpC3H1i+CMzX23mnSNhAgQXV3P1hX8trYwdV/5ZeUEoLHW 3EROHdA/mnTD2LNkzFLG27N9QQvaNKb9yqspLqe+Msn3kFoSnjdXEZU0qdtaTwVb Kl3qrsZd78IzjhNoXj5/83GNU0Yd/eDRvURonrgwl8TEsDNuNQNG7R+o60czfdXI 00xenPOthlSSazmLBaAAvnbl48U/60IUB9zhIfsHIZphGT8Bzpu4anNgLA654qxj 8xcAITxXL+q6JvQHWWpBBEpcMfX+f33C08Lf0YufQTAKH1wwCigbW9tfqjJzbyzw k5wNdeFRbp2wmZxonFTMQhH4VB94uL0KIfhh0NXWy1u90Nw6CuVc9LpU3hJJQZvz W4XdjXa6AzgoF3N/aGkOdfxErKV+5OxFk/BthT1OPxeHUDsNv9qsTDE1e4cDMcfg 70HPDLktvDy8jdIHP+DDfdwJHfECCLQNxEratXNfHXGgTcq8a87iYgeaqPny0QnJ AKdAq6qBXu8zXiaMsLtUIkFTL8V97cDOf90iFFTj3VleiFWVWkY= =ISsc -----END PGP SIGNATURE----- --5mCyUwZo2JvN/JJP-- From owner-freebsd-current@freebsd.org Mon Jan 27 18:19:58 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A8F691FEBC7 for ; Mon, 27 Jan 2020 18:19:58 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.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 485yhY3zvMz3C0Z for ; Mon, 27 Jan 2020 18:19:57 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 00RIJpeZ056050; Mon, 27 Jan 2020 10:19:51 -0800 (PST) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 00RIJo3e056049; Mon, 27 Jan 2020 10:19:50 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202001271819.00RIJo3e056049@gndrsh.dnsmgr.net> Subject: Re: After update to r357104 build of poudriere jail fails with 'out of swap space' In-Reply-To: <202001271309.00RD96nr005876@slippy.cwsent.com> To: Cy Schubert Date: Mon, 27 Jan 2020 10:19:50 -0800 (PST) CC: "Rodney W. Grimes" , sgk@troutmask.apl.washington.edu, freebsd-current@freebsd.org, Mark Millard , yasu@utahime.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 485yhY3zvMz3C0Z X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd-rwg@gndrsh.dnsmgr.net has no SPF policy when checking 69.59.192.140) smtp.mailfrom=freebsd-rwg@gndrsh.dnsmgr.net X-Spamd-Result: default: False [2.43 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; RCPT_COUNT_FIVE(0.00)[6]; NEURAL_SPAM_MEDIUM(0.56)[0.556,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.94)[0.941,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.03)[ip: (0.13), ipnet: 69.59.192.0/19(0.07), asn: 13868(0.02), country: US(-0.05)]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 27 Jan 2020 18:19:58 -0000 > In message <202001261745.00QHjkuW044006@gndrsh.dnsmgr.net>, "Rodney W. > Grimes" > writes: > > > In message <20200125233116.GA49916@troutmask.apl.washington.edu>, Steve > > > Kargl w > > > rites: > > > > On Sat, Jan 25, 2020 at 02:09:29PM -0800, Cy Schubert wrote: > > > > > On January 25, 2020 1:52:03 PM PST, Steve Kargl > ingt > > > > on.edu> wrote: > > > > > >On Sat, Jan 25, 2020 at 01:41:16PM -0800, Cy Schubert wrote: > > > > > >> > > > > > >> It's not just poudeiere. Standard port builds of chromium, rust > > > > > >> and thunderbird also fail on my machines with less than 8 GB. > > > > > >> > > > > > > > > > > > >Interesting. I routinely build chromium, rust, firefox, > > > > > >llvm and few other resource-hunger ports on a i386-freebsd > > > > > >laptop with 3.4 GB available memory. This is done with > > > > > >chrome running with a few tabs swallowing a 1-1.5 GB of > > > > > >memory. No issues. > > > > > > > > > > Number of threads makes a difference too. How many core/threads does yo > > ur l > > > > aptop have? > > > > > > > > 2 cores. > > > > > > This is why. > > > > > > > > > > > > Reducing number of concurrent threads allowed my builds to complete > > > > > on the 5 GB machine. My build machines have 4 cores, 1 thread per > > > > > core. Reducing concurrent threads circumvented the issue. > > > > > > > > I use portmaster, and AFIACT, it uses 'make -j 2' for the build. > > > > Laptop isn't doing too much, but an update and browsing. It does > > > > take a long time especially if building llvm is required. > > > > > > I use portmaster as well (for quick incidental builds). It uses > > > MAKE_JOBS_NUMBER=4 (which is equivalent to make -j 4). I suppose machines > > > with not enough memory to support their cores with certain builds might > > > have a better chance of having this problem. > > > > > > MAKE_JOBS_NUMBER_LIMIT to limit a 4 core machine with less than 2 GB per > > > core might be an option. Looking at it this way, instead of an extra 3 GB, > > > the extra 60% more memory in the other machine makes a big difference. A > > > rule of thumb would probably be, have ~ 2 GB RAM for every core or thread > > > when doing large parallel builds. > > > > Perhaps we need to redo some boot time calculations, for one the > > ZFS arch cache, IMHO, is just silly at a fixed percent of total > > memory. A high percentage at that. > > > > One idea based on what you just said might be: > > > > percore_memory_reserve = 2G (Your number, I personally would use 1G here) > > arc_max = MAX(memory size - (Cores * percore_memory_reserve), 512mb) > > > > I think that simple change would go a long ways to cutting down the > > number of OOM reports we see. ALSO IMHO there should be a way for > > sub systems to easily tell zfs they are memory pigs too and need to > > share the space. Ie, bhyve is horrible if you do not tune zfs arc > > based on how much memory your using up for VM's. > > > > Another formulation might be > > percore_memory_reserve = alpha * memory_zire / cores > > > > Alpha most likely falling in the 0.25 to 0.5 range, I think this one > > would have better scalability, would need to run some numbers. > > Probably needs to become non linear above some core count. > > Setting a lower arc_max at boot is unlikely to help. Rust was building on > the 8 GB and 5 GB 4 core machines last night. It completed successfully on > the 8 GB machine, while using 12 MB of swap. ARC was at 1307 MB. > > On the 5 GB 4 core machine the rust build died of OOM. 328 KB swap was > used. ARC was reported at 941 MB. arc_min on this machine is 489.2 MB. What is arc_max? > Cy Schubert -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-current@freebsd.org Mon Jan 27 18:45:53 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A645C1FF74A for ; Mon, 27 Jan 2020 18:45:53 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 485zGS4xqYz3DQm for ; Mon, 27 Jan 2020 18:45:52 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id w9ONi2DVb17ZDw9OPiybqo; Mon, 27 Jan 2020 11:45:50 -0700 X-Authority-Analysis: v=2.3 cv=ZsqT1OzG c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=IkcTkHD0fZMA:10 a=Jdjhy38mL1oA:10 a=YxBL1-UpAAAA:8 a=iKhvJSA4AAAA:8 a=6I5d2MoRAAAA:8 a=8YyLshPAjw1AOyHiOtcA:9 a=Ka11LL8GkENx6Qmj:21 a=LmpARAxJ31HlJoXj:21 a=QEXdDO2ut3YA:10 a=7FgKuMUr8FYA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=odh9cflL3HIXMm4fY7Wr:22 a=IjZwj45LgO3ly-622nXo:22 Received: from Resas-iPad.esitwifi.local (S0106788a207e2972.gv.shawcable.net [70.66.154.233]) by spqr.komquats.com (Postfix) with ESMTPSA id 1BAB55E7; Mon, 27 Jan 2020 10:45:47 -0800 (PST) Date: Mon, 27 Jan 2020 10:20:35 -0800 User-Agent: K-9 Mail for Android In-Reply-To: <202001271309.00RD96nr005876@slippy.cwsent.com> References: <202001261745.00QHjkuW044006@gndrsh.dnsmgr.net> <202001271309.00RD96nr005876@slippy.cwsent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: After update to r357104 build of poudriere jail fails with 'out of swap space' To: "Rodney W. Grimes" CC: sgk@troutmask.apl.washington.edu, freebsd-current@freebsd.org, Mark Millard , yasu@utahime.org From: Cy Schubert Message-ID: X-CMAE-Envelope: MS4wfB0b8VKzouA3fTbAvRvbGKswx6ZBIN9Akj+dv5ei6PZ8OBfgcPe3iYNvOxNgCXM2gdd22Kz9k6nItXWDxKZqDxp/NnFNEaCR/0u1EXRcsapEF3aGQW2c ks7rpTqxTAGPHHXb6DwaAj2shaNH9F6q/cZrzMYn5niPOIKmHvy2UtzA+cfYMT8Suk6RYrBh12k6VZmuND4WhFdhgrraJWWZLPjhUfHhi9Tdf559wUPdQBTx MLJ0/LVhgtJc2Cpu5xrAEwL/lmoupN1awyWrSoJajRDzsz73al09RCmUBnU1LYysn7TJKob7FUauewie0gD9GPGoHxQzLtDMs91lRpkEq7M= X-Rspamd-Queue-Id: 485zGS4xqYz3DQm X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 64.59.136.137) smtp.mailfrom=cy.schubert@cschubert.com X-Spamd-Result: default: False [-4.58 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[233.154.66.70.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11,17.125.67.70.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[137.136.59.64.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(-2.38)[ip: (-6.16), ipnet: 64.59.128.0/20(-3.18), asn: 6327(-2.47), country: CA(-0.09)]; FROM_EQ_ENVFROM(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 27 Jan 2020 18:45:53 -0000 On January 27, 2020 5:09:06 AM PST, Cy Schubert wrote: >In message <202001261745=2E00QHjkuW044006@gndrsh=2Ednsmgr=2Enet>, "Rodney= W=2E=20 >Grimes" >writes: >> > In message <20200125233116=2EGA49916@troutmask=2Eapl=2Ewashington=2Ee= du>, >Steve=20 >> > Kargl w >> > rites: >> > > On Sat, Jan 25, 2020 at 02:09:29PM -0800, Cy Schubert wrote: >> > > > On January 25, 2020 1:52:03 PM PST, Steve Kargl >> ingt >> > > on=2Eedu> wrote: >> > > > >On Sat, Jan 25, 2020 at 01:41:16PM -0800, Cy Schubert wrote: >> > > > >>=20 >> > > > >> It's not just poudeiere=2E Standard port builds of chromium, >rust >> > > > >> and thunderbird also fail on my machines with less than 8 >GB=2E >> > > > >> >> > > > > >> > > > >Interesting=2E I routinely build chromium, rust, firefox, >> > > > >llvm and few other resource-hunger ports on a i386-freebsd >> > > > >laptop with 3=2E4 GB available memory=2E This is done with >> > > > >chrome running with a few tabs swallowing a 1-1=2E5 GB of >> > > > >memory=2E No issues=2E =20 >> > > >=20 >> > > > Number of threads makes a difference too=2E How many core/threads >does yo >> ur l >> > > aptop have? >> > > >> > > 2 cores=2E >> >=20 >> > This is why=2E >> >=20 >> > > >> > > > Reducing number of concurrent threads allowed my builds to >complete >> > > > on the 5 GB machine=2E My build machines have 4 cores, 1 thread >per >> > > > core=2E Reducing concurrent threads circumvented the issue=2E=20 >> > > >> > > I use portmaster, and AFIACT, it uses 'make -j 2' for the build=2E >> > > Laptop isn't doing too much, but an update and browsing=2E It does >> > > take a long time especially if building llvm is required=2E >> >=20 >> > I use portmaster as well (for quick incidental builds)=2E It uses=20 >> > MAKE_JOBS_NUMBER=3D4 (which is equivalent to make -j 4)=2E I suppose >machines=20 >> > with not enough memory to support their cores with certain builds >might=20 >> > have a better chance of having this problem=2E >> >=20 >> > MAKE_JOBS_NUMBER_LIMIT to limit a 4 core machine with less than 2 >GB per=20 >> > core might be an option=2E Looking at it this way, instead of an >extra 3 GB,=20 >> > the extra 60% more memory in the other machine makes a big >difference=2E A=20 >> > rule of thumb would probably be, have ~ 2 GB RAM for every core or >thread=20 >> > when doing large parallel builds=2E >> >> Perhaps we need to redo some boot time calculations, for one the >> ZFS arch cache, IMHO, is just silly at a fixed percent of total >> memory=2E A high percentage at that=2E >> >> One idea based on what you just said might be: >> >> percore_memory_reserve =3D 2G (Your number, I personally would use 1G >here) >> arc_max =3D MAX(memory size - (Cores * percore_memory_reserve), 512mb) >> >> I think that simple change would go a long ways to cutting down the >> number of OOM reports we see=2E ALSO IMHO there should be a way for >> sub systems to easily tell zfs they are memory pigs too and need to >> share the space=2E Ie, bhyve is horrible if you do not tune zfs arc >> based on how much memory your using up for VM's=2E >> >> Another formulation might be >> percore_memory_reserve =3D alpha * memory_zire / cores >> >> Alpha most likely falling in the 0=2E25 to 0=2E5 range, I think this on= e >> would have better scalability, would need to run some numbers=2E >> Probably needs to become non linear above some core count=2E > >Setting a lower arc_max at boot is unlikely to help=2E Rust was building >on=20 >the 8 GB and 5 GB 4 core machines last night=2E It completed successfully >on=20 >the 8 GB machine, while using 12 MB of swap=2E ARC was at 1307 MB=2E > >On the 5 GB 4 core machine the rust build died of OOM=2E 328 KB swap was= =20 >used=2E ARC was reported at 941 MB=2E arc_min on this machine is 489=2E2 = MB=2E MAKE_JOBS_NUMBER=3D3 worked building rust on the 5 GB 4 core machine=2E A= RC is at 534 MB with 12 MB swap used=2E --=20 Pardon the typos and autocorrect, small keyboard in use=2E=20 Cy Schubert FreeBSD UNIX: Web: https://www=2EFreeBSD=2Eorg The need of the many outweighs the greed of the few=2E Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E From owner-freebsd-current@freebsd.org Mon Jan 27 19:09:54 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9B00F2284AE for ; Mon, 27 Jan 2020 19:09:54 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 485zp94b22z3Frs for ; Mon, 27 Jan 2020 19:09:53 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id w9lci6Tr6kqGXw9ldiIEDE; Mon, 27 Jan 2020 12:09:51 -0700 X-Authority-Analysis: v=2.3 cv=c/jVvi1l c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=IkcTkHD0fZMA:10 a=Jdjhy38mL1oA:10 a=iKhvJSA4AAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=JJEPTso-pDyPorNxduYA:9 a=pum2oeXq2iKrGOMB:21 a=WZbiQQmD437hizDH:21 a=QEXdDO2ut3YA:10 a=7FgKuMUr8FYA:10 a=odh9cflL3HIXMm4fY7Wr:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 Received: from Resas-iPad.esitwifi.local (S0106788a207e2972.gv.shawcable.net [70.66.154.233]) by spqr.komquats.com (Postfix) with ESMTPSA id AEEC15F9; Mon, 27 Jan 2020 11:09:47 -0800 (PST) Date: Mon, 27 Jan 2020 11:09:24 -0800 User-Agent: K-9 Mail for Android In-Reply-To: <202001271819.00RIJo3e056049@gndrsh.dnsmgr.net> References: <202001271819.00RIJo3e056049@gndrsh.dnsmgr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: After update to r357104 build of poudriere jail fails with 'out of swap space' To: "Rodney W. Grimes" CC: sgk@troutmask.apl.washington.edu, freebsd-current@freebsd.org, Mark Millard , yasu@utahime.org From: Cy Schubert Message-ID: <6EE01D8C-FD95-4C69-A8E6-AAA619135E5A@cschubert.com> X-CMAE-Envelope: MS4wfCjY1AFwju0JxBkF53HW5iQqtYZro9qDuEkMFvSsA0b1NgonQShjnKKKotCdZNl0wxYLdvpU5IdDzRBbp5SUcBWJuZd2kArJRW7MkeKEfy5YxwLwO/OT mVBL19xc9BMZf3v5oxpVj9oY27F1kSBlWwSV94r7aTkoDZxEwYY2d9cZV9uZp0FqPr4/QTQgQmRvRYtChkp9WKGd7unVPxixOEsi/sBt8BMYY5pU7VeiFxL0 l0VGGdy3kOFmwy1SD8OKnM9qQaLlHwYVRUY5IVXV8tW5bMwOVdZQoCCHIkJx0WlxV2T2IXc2CODlbIiz3EVzNNvGFslowk/xQjemwacGpms= X-Rspamd-Queue-Id: 485zp94b22z3Frs X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 64.59.134.12) smtp.mailfrom=cy.schubert@cschubert.com X-Spamd-Result: default: False [-4.67 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[233.154.66.70.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11,17.125.67.70.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[12.134.59.64.rep.mailspike.net : 127.0.0.18]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[12.134.59.64.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(-2.47)[ip: (-6.60), ipnet: 64.59.128.0/20(-3.18), asn: 6327(-2.47), country: CA(-0.09)]; FROM_EQ_ENVFROM(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 27 Jan 2020 19:09:54 -0000 On January 27, 2020 10:19:50 AM PST, "Rodney W=2E Grimes" wrote: >> In message <202001261745=2E00QHjkuW044006@gndrsh=2Ednsmgr=2Enet>, "Rodn= ey >W=2E=20 >> Grimes" >> writes: >> > > In message <20200125233116=2EGA49916@troutmask=2Eapl=2Ewashington= =2Eedu>, >Steve=20 >> > > Kargl w >> > > rites: >> > > > On Sat, Jan 25, 2020 at 02:09:29PM -0800, Cy Schubert wrote: >> > > > > On January 25, 2020 1:52:03 PM PST, Steve Kargl >> > ingt >> > > > on=2Eedu> wrote: >> > > > > >On Sat, Jan 25, 2020 at 01:41:16PM -0800, Cy Schubert wrote: >> > > > > >>=20 >> > > > > >> It's not just poudeiere=2E Standard port builds of chromium, >rust >> > > > > >> and thunderbird also fail on my machines with less than 8 >GB=2E >> > > > > >> >> > > > > > >> > > > > >Interesting=2E I routinely build chromium, rust, firefox, >> > > > > >llvm and few other resource-hunger ports on a i386-freebsd >> > > > > >laptop with 3=2E4 GB available memory=2E This is done with >> > > > > >chrome running with a few tabs swallowing a 1-1=2E5 GB of >> > > > > >memory=2E No issues=2E =20 >> > > > >=20 >> > > > > Number of threads makes a difference too=2E How many >core/threads does yo >> > ur l >> > > > aptop have? >> > > > >> > > > 2 cores=2E >> > >=20 >> > > This is why=2E >> > >=20 >> > > > >> > > > > Reducing number of concurrent threads allowed my builds to >complete >> > > > > on the 5 GB machine=2E My build machines have 4 cores, 1 thread >per >> > > > > core=2E Reducing concurrent threads circumvented the issue=2E= =20 >> > > > >> > > > I use portmaster, and AFIACT, it uses 'make -j 2' for the >build=2E >> > > > Laptop isn't doing too much, but an update and browsing=2E It >does >> > > > take a long time especially if building llvm is required=2E >> > >=20 >> > > I use portmaster as well (for quick incidental builds)=2E It uses= =20 >> > > MAKE_JOBS_NUMBER=3D4 (which is equivalent to make -j 4)=2E I suppos= e >machines=20 >> > > with not enough memory to support their cores with certain builds >might=20 >> > > have a better chance of having this problem=2E >> > >=20 >> > > MAKE_JOBS_NUMBER_LIMIT to limit a 4 core machine with less than 2 >GB per=20 >> > > core might be an option=2E Looking at it this way, instead of an >extra 3 GB,=20 >> > > the extra 60% more memory in the other machine makes a big >difference=2E A=20 >> > > rule of thumb would probably be, have ~ 2 GB RAM for every core >or thread=20 >> > > when doing large parallel builds=2E >> > >> > Perhaps we need to redo some boot time calculations, for one the >> > ZFS arch cache, IMHO, is just silly at a fixed percent of total >> > memory=2E A high percentage at that=2E >> > >> > One idea based on what you just said might be: >> > >> > percore_memory_reserve =3D 2G (Your number, I personally would use 1G >here) >> > arc_max =3D MAX(memory size - (Cores * percore_memory_reserve), >512mb) >> > >> > I think that simple change would go a long ways to cutting down the >> > number of OOM reports we see=2E ALSO IMHO there should be a way for >> > sub systems to easily tell zfs they are memory pigs too and need to >> > share the space=2E Ie, bhyve is horrible if you do not tune zfs arc >> > based on how much memory your using up for VM's=2E >> > >> > Another formulation might be >> > percore_memory_reserve =3D alpha * memory_zire / cores >> > >> > Alpha most likely falling in the 0=2E25 to 0=2E5 range, I think this >one >> > would have better scalability, would need to run some numbers=2E >> > Probably needs to become non linear above some core count=2E >>=20 >> Setting a lower arc_max at boot is unlikely to help=2E Rust was >building on=20 >> the 8 GB and 5 GB 4 core machines last night=2E It completed >successfully on=20 >> the 8 GB machine, while using 12 MB of swap=2E ARC was at 1307 MB=2E >>=20 >> On the 5 GB 4 core machine the rust build died of OOM=2E 328 KB swap >was=20 >> used=2E ARC was reported at 941 MB=2E arc_min on this machine is 489=2E= 2 >MB=2E > >What is arc_max? =20 > >> Cy Schubert 3=2E8 GB=2E It never exceeds 1=2E5 to 2 GB when doing a NO_CLEAN buildworl= d, where it gets a 95-99% hit ratio with 8 threads=2E There are a couple of things going on here=2E First, four large multithrea= ded rust compiles in memory simultaneously=2E Secondly, a reluctance to use= swap=2E My guess is the working set for each of the four compiles was larg= e enough to trigger the OOM=2E I haven't had time to seriously look at thi= s though but I'm guessing that the locality of reference was large enough t= o keep much of the memory in RAM, so here we are=2E --=20 Pardon the typos and autocorrect, small keyboard in use=2E=20 Cy Schubert FreeBSD UNIX: Web: https://www=2EFreeBSD=2Eorg The need of the many outweighs the greed of the few=2E Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E From owner-freebsd-current@freebsd.org Mon Jan 27 20:11:33 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 62EF522C763; Mon, 27 Jan 2020 20:11:33 +0000 (UTC) (envelope-from salvadore@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48619K2dZbz46PL; Mon, 27 Jan 2020 20:11:33 +0000 (UTC) (envelope-from salvadore@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1472) id 4E994699D; Mon, 27 Jan 2020 20:11:33 +0000 (UTC) To: freebsd-hackers@FreeBSD.org Subject: FreeBSD Quarterly Status Report - Fourth Quarter 2019 Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Message-Id: <20200127201133.4E994699D@freefall.freebsd.org> Date: Mon, 27 Jan 2020 20:11:33 +0000 (UTC) From: Lorenzo Salvadore X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 27 Jan 2020 20:11:33 -0000 FreeBSD Project Quarterly Status Report - Fourth Quarter 2019 Here is the last quarterly status report for 2019. As you might remember from last report, we changed our timeline: now we collect reports the last month of each quarter and we edit and publish the full document the next month. Thus, we cover here the period October 2019 - December 2019. If you thought that the FreeBSD community was less active in the Christmas' quarter you will be glad to be proven wrong: a quick glance at the summary will be sufficient to see that much work has been done in the last months. Have a nice read! -- Lorenzo Salvadore __________________________________________________________________ FreeBSD Team Reports * FreeBSD Core Team * FreeBSD Foundation * FreeBSD Release Engineering Team * Cluster Administration Team * Continuous Integration Projects * IPSec Extended Sequence Number (ESN) support * NFS Version 4.2 implementation * DTS Update * RockChip Support * Creating virtual FreeBSD appliances from RE VMDK images Kernel * SoC audio framework and RK3399 audio drivers * FreeBSD on Microsoft HyperV and Azure * FreeBSD on EC2 ARM64 * ENA FreeBSD Driver Update Architectures * PowerPC on Clang * NXP ARM64 SoC support Userland Programs * Linux compatibility layer update Ports * Ports Collection * KDE on FreeBSD * Java on FreeBSD * Electron and VSCode * Bastille * Universal Packaging Tool (upt) * Wine on FreeBSD Third-Party Projects * sysctlbyname-improved * pot and the nomad pot driver * 7 Days Challenge * NomadBSD __________________________________________________________________ FreeBSD Team Reports Entries from the various official and semi-official teams, as found in the Administration Page. FreeBSD Core Team Contact: FreeBSD Core Team The FreeBSD Core Team is the governing body of FreeBSD. * Julie Saravanos, the sister of Bruce D. Evans (bde), mailed core with the sad news that Bruce passed away on 2019-12-18 at the age of 68 years. Bruce was a deeply respected member of the community, served on the Core team, and made over 5,000 commits. Bruce's impact on our culture was so profound that new terminology was spawned. This is an excerpt of a message from Poul-Henning Kamp to Julie. I don't know precisely when I first communicated with Bruce, it was in the late 1980'ies via "UseNET", but I can say with certainty that few people have inspired me more, or improved my programming more, than Bruce he did over the next half of my life. All large projects invent its own vocabulary and in FreeBSD two of the neologisms are "Brucification", and "Brucified". A "brucification" meant receiving a short, courteous note pointing out a sometimes subtle deficiency, or an overlooked detail in a source code change. Not necessarily a serious problem, possibly not even a problem to anybody at all, but nonetheless something which was wrong and ought to be fixed. It was not uncommon for the critique to be considerably longer than the change in question. If one ignored brucifications one ran the risk of being "brucified", which meant receiving a long and painstakingly detailed list of every single one of the errors, mistakes, typos, shortcomings, bad decisions, questionable choices, style transgressions and general sloppiness of thinking, often expressed with deadpan humor sharpened to a near-fatal point. The most frustrating thing was that Bruce would be perfectly justified and correct. I can only recall one or two cases where I were able to respond "Sorry Bruce, but you're wrong there..." - and I confess that on those rare days I felt like I should cut a notch in my keyboard. The last email we received from Bruce is a good example of the depth of knowledge and insight he provided for the project: https://docs.freebsd.org/cgi/getmsg.cgi?fetch=1163414+0+archive/2019/svn-src-all/20191027.svn-src-all * The 12.1 release was dedicated to another FreeBSD developer who passed away in the fourth quarter of 2019, Kurt Lidl. The FreeBSD Foundation has a memorial page to Kurt. https://www.freebsdfoundation.org/blog/in-memory-of-kurt-lidl/ We send our condolences to both the families of Bruce and Kurt. * Core has documented The Project's policy on support tiers. https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/archs.html * Core approved a source commit bit for James Clarke. Brooks Davis (brooks) will mentor James and John Baldwin (jhb) will co-mentor. * The Project's first Season of Docs ended with a negative result. The work was not completed and contact could not be established with the writer. No payment was made and the financing was set aside for future work. * Google Summer of Code completed. Information about the seven accepted projects can be found on the wiki page. https://wiki.freebsd.org/SummerOfCode2019Projects * Adam Weinberger (admaw) was added to conduct@. Adam has demonstrated competence, understanding, and fairness in personal matters. * Li-Wen Hsu (lwhsu) contacted Core after receiving a report from concerned local community members about past updates to The Project's internationalization policy. Lengthy discussions took place to determine how to reaffirm that The Project maintains a neutral position in political disputes. Updates were made to the document and it was decided that any future changes would require explicit Core approval. https://www.freebsd.org/internal/i18n.html * After nomination by Edward Napierała (trasz), core voted to grant Daniel Ebdrup (debdrup) and Lorenzo Salvadore (salvadore) membership in The Project. Both Daniel and Lorenzo have been working on the quarterly reports for the past few quarters. * The Core-initiated Git Transition Working Group continued to meet over the last quarter of 2019. Their report is still forthcoming. __________________________________________________________________ FreeBSD Foundation Contact: Deb Goodkin The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to supporting and promoting the FreeBSD Project and community worldwide. Funding comes from individual and corporate donations and is used to fund and manage software development projects, conferences and developer summits, and provide travel grants to FreeBSD contributors. The Foundation purchases and supports hardware to improve and maintain FreeBSD infrastructure and provides resources to improve security, quality assurance, and release engineering efforts; publishes marketing material to promote, educate, and advocate for the FreeBSD Project; facilitates collaboration between commercial vendors and FreeBSD developers; and finally, represents the FreeBSD Project in executing contracts, license agreements, and other legal arrangements that require a recognized legal entity. Here are some highlights of what we did to help FreeBSD last quarter: Partnerships and Commercial User Support We help facilitate collaboration between commercial users and FreeBSD developers. We also meet with companies to discuss their needs and bring that information back to the Project. In Q4, Ed Maste and Deb Goodkin met with a few commercial users in the US. It's not only beneficial for the above, but it also helps us understand some of the applications where FreeBSD is used. We were also able to meet with a good number of commercial users at the Bay Area Vendor/Developer Summit and Open Source Summit Europe. These venues provide an excellent opportunity to meet with commercial and individual users and contributors to FreeBSD. Fundraising Efforts In 2019, we focused on supporting a few key areas where the Project needed the most help. The first area was software development. Whether it was contracting FreeBSD developers to work on projects like wifi support, to providing internal staff to quickly implement hardware workarounds, we've stepped in to help keep FreeBSD innovative, secure, and reliable. Software development includes supporting the tools and infrastructure that make the development process go smoothly, and we're on it with team members heading up the Continuous Integration efforts, and actively involved in the clusteradmin and security teams. Our advocacy efforts focused on recruiting new users and contributors to the Project. We attended and participated in 38 conferences and events in 21 countries. From giving FreeBSD presentations and workshops to staffing tables, we were able to have 1:1 conversations with thousands of attendees. Our travels also provided opportunities to talk directly with FreeBSD commercial and individual users, contributors, and future FreeBSD users/contributors. We've seen an increase in use and interest in FreeBSD from all of these organizations and individuals. These meetings give us a chance to learn more about what organizations need and what they and other individuals are working on. The information helps inform the work we should fund. In 2019, your donations helped us continue our efforts of supporting critical areas of FreeBSD such as: * Operating System Improvements: Providing staff to immediately respond to urgent problems and implement new features and functionality allowing for the innovation and stability you've come to rely on. * Improving and increasing test coverage, continuous integration, and automated testing with a full-time software engineer to ensure you receive the highest quality, secure, and reliable operating system. * Security: Providing engineering resources to bolster the capacity and responsiveness of the Security team providing you with peace of mind when security issues arise. * Growing the number of FreeBSD contributors and users from our global FreeBSD outreach and advocacy efforts, including expanding into regions such as China, India, Africa, and Singapore. * Offering FreeBSD workshops and presentations at more conferences, meetups, and universities around the world. * Providing opportunities such as developer and vendor summits and company visits to help facilitate collaboration between commercial users and FreeBSD developers, as well as helping to get changes pushed into the FreeBSD source tree, and creating a bigger and healthier ecosystem. We've accomplished a lot this year, but we are still only a small 501(c)3 organization focused on supporting FreeBSD and not a trade organization like many other open source Foundations. Please consider making a donation at https://www.FreeBSDfoundation.org/donate/ to help us continue and increase our support for FreeBSD. We also have the Partnership Program, to provide more benefits for our larger commercial donors. Find out more information at https://www.FreeBSDfoundation.org/FreeBSD-foundation-partnership-program/ and share with your companies! OS Improvements The Foundation supports software development projects to improve FreeBSD through our full time technical staff, contractors, and project grant recipients. They maintain and improve critical kernel subsystems, add new features and functionality, and fix bugs. Between October and December there were 236 commits to the FreeBSD source repository tagged with FreeBSD Foundation sponsorship. This is about 10% of all commits during this period. Some of these projects have their own entries in the quarterly report, and are not repeated here, while others are briefly described below. As usual, Foundation staff member Konstantin Belousov committed a large number of UFS, NFS, tmpfs, VM system, and low-level Intel x86 bug fixes and improvements. Kostik also committed improvements to the run-time linker (rtld), and participated in very many code reviews, helping to get changes from other developers integrated into the tree. Following on from his work to improve debugging tools in the Linuxulator environment, Edward Napierała integrated the Linux Test Project (LTP) with FreeBSD's CI system, and committed a number of small bug fixes to the Linuxulator itself. Mark Johnston continued working on infrastructure for the Syzkaller system call fuzzing tool, and committed fixes for many issues identified by it. Mark committed improvements to RISC-V infrastructure, the network stack, performance and locking, and x86 pmap. Mark also added support for newer Intel WiFi chipsets to the iwm driver, enabling WiFi support for the Lenovo X1 Carbon 7th generation, and other contemporary laptops. Ed Maste committed a number of improvements and cleanups in build infrastructure, vt console fixes including issues with keyboard maps, some blacklistd updates, documentation updates, and other small changes. Ed also committed some work to prepare for the removal of GCC 4.2.1 from the FreeBSD source tree, currently planned for Q1 2020. Continuous Integration and Quality Assurance The Foundation provides a full-time staff member who is working on improving our automated testing, continuous integration, and overall quality assurance efforts. During the fourth quarter of 2019, Foundation staff continued to improve the project's CI infrastructure, worked with contributors to fix the failing build and test cases. We worked with other teams in the project for their testing needs and also worked with many external projects and companies to improve their support of FreeBSD. We added several new CI jobs and brought the FreeBSD Hardware Testing Lab online. We published 2019 in Review: CI and Testing Advancements on the Foundation's blog. See the FreeBSD CI section of this report for completed work items and detailed information. Supporting FreeBSD Infrastructure The Foundation provides hardware and support to improve the FreeBSD infrastructure. Last quarter, we continued supporting FreeBSD hardware located around the world. FreeBSD Advocacy and Education A large part of our efforts are dedicated to advocating for the Project. This includes promoting work being done by others with FreeBSD; producing advocacy literature to teach people about FreeBSD and help make the path to starting using FreeBSD or contributing to the Project easier; and attending and helping other FreeBSD contributors volunteer to run FreeBSD events, staff FreeBSD tables, and give FreeBSD presentations. The FreeBSD Foundation sponsors many conferences, events, and summits around the globe. These events can be BSD-related, open source, or technology events geared towards underrepresented groups. We support the FreeBSD-focused events to help provide a venue for sharing knowledge, to work together on projects, and to facilitate collaboration between developers and commercial users. This all helps provide a healthy ecosystem. We support the non-FreeBSD events to promote and raise awareness of FreeBSD, to increase the use of FreeBSD in different applications, and to recruit more contributors to the Project. Check out some of the advocacy and education work we did last quarter: * Organized the 2019 Bay Area FreeBSD Vendor and Developers Summit in Santa Clara, CA * Presented at COSCON '19 in Shanghai, China * Represented FreeBSD at All Things Open 2019, in Raleigh, North Carolina * Industry Partner Sponsor for LISA '19 in Portland, OR * Silver Sponsor of OpenZFS in San Francisco, CA * Gave a technical presentation at School of Mines in Golden, CO * Presenting and representing FreeBSD at Seagl, in Seattle, WA * Presented at Open Source Summit Europe in Lyon France * Committed to sponsoring LinuxConfAu 2020, in Gold Coast, Australia in addition to holding a FreeBSD Mini-Conf * Accepted to present at the BSD Dev Room at FOSDEM '20, in Brussels, Belgium * Accepted to have a stand at FOSDEM '20, in Brussels, Belgium * Committed to sponsoring FOSSASIA 2020, in Singapore * Committed to hold FreeBSD Day at SCALE 18x, in Pasadena, CA We continued producing FreeBSD advocacy material to help people promote FreeBSD. Learn more about our efforts in 2019 to advocate for FreeBSD: https://www.freebsdfoundation.org/blog/2019-in-review-advocacy/ Our Faces of FreeBSD series is back. Check out the latest post: Mahdi Mokhtari. https://www.freebsdfoundation.org/blog/faces-of-freebsd-2019-mahdi-mokhtari/ Read more about our conference adventures in the conference recaps and trip reports in our monthly newsletters: https://www.freebsdfoundation.org/news-and-events/newsletter/ We help educate the world about FreeBSD by publishing the professionally produced FreeBSD Journal. As we mentioned previously, the FreeBSD Journal is now a free publication. Find out more and access the latest issues at https://www.FreeBSDfoundation.org/journal/. You can find out more about events we attended and upcoming events at https://www.FreeBSDfoundation.org/news-and-events/. We have continued our work with a new website developer to help us improve our website. Work has begun to make it easier for community members to find information more easily and to make the site more efficient. Legal/FreeBSD IP The Foundation owns the FreeBSD trademarks, and it is our responsibility to protect them. We also provide legal support for the core team to investigate questions that arise. Go to http://www.FreeBSDfoundation.org to find out how we support FreeBSD and how we can help you! __________________________________________________________________ FreeBSD Release Engineering Team Links FreeBSD 12.1-RELEASE schedule URL: https://www.freebsd.org/releases/12.1R/schedule.html FreeBSD 12.1-RELEASE announcement URL: https://www.freebsd.org/releases/12.1R/announce.html FreeBSD development snapshots URL: https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/ Contact: FreeBSD Release Engineering Team The FreeBSD Release Engineering Team is responsible for setting and publishing release schedules for official project releases of FreeBSD, announcing code freezes and maintaining the respective branches, among other things. The FreeBSD Release Engineering Team continued work on the 12.1-RELEASE, which started September 6th. This release cycle was the first "freeze-less" release from the Subversion repository, and the test bed for eliminating the requirement of a hard code freeze on development branches. The 12.1-RELEASE cycle concluded with the final build beginning November 4th, preceded by three BETA builds and two RC builds. The RC3 build had been included in the original schedule, but had been decided to not be required. Additionally throughout the quarter, several development snapshots builds were released for the head, stable/12, and stable/11 branches. Much of this work was sponsored by Rubicon Communications, LLC (netgate.com) and the FreeBSD Foundation. __________________________________________________________________ Cluster Administration Team Links Cluster Administration Team members URL: https://www.freebsd.org/administration.html#t-clusteradm Contact: Cluster Administration Team The FreeBSD Cluster Administration Team consists of the people responsible for administering the machines that the Project relies on for its distributed work and communications to be synchronised. In this quarter, the team has worked on the following: * Upgrade ref11-{amd64,i386}.freebsd.org to 11.3-STABLE r353313 * Ongoing systems administration work: * Creating accounts for new committers. * Backups of critical infrastructure. * Keeping up with security updates in 3rd party software. Work in progress: * Review the service jails and service administrators operation. * South Africa Mirror (JINX) in progress. * NVME issues on PowerPC64 Power9 blocking dual socket machine from being used as pkg builder. * Drive upgrade test for pkg builders (SSDs) courtesy of the FreeBSD Foundation. * Boot issues with Aarch64 reference machines. * New NYI.net sponsored colocation space in Chicago-land area. * Setup new host for CI staging environment. * Plan how to add new semi-official pkg mirrors __________________________________________________________________ Continuous Integration Links FreeBSD Jenkins Instance URL: https://ci.FreeBSD.org FreeBSD Hardware Testing Lab URL: https://ci.FreeBSD.org/hwlab FreeBSD CI artifact archive URL: https://artifact.ci.FreeBSD.org FreeBSD CI weekly report URL: https://hackmd.io/@FreeBSD-CI freebsd-testing Mailing List URL: https://lists.FreeBSD.org/mailman/listinfo/freebsd-testing FreeBSD Jenkins wiki URL: https://wiki.freebsd.org/Jenkins Hosted CI wiki URL: https://wiki.freebsd.org/HostedCI 3rd Party Software CI URL: https://wiki.freebsd.org/3rdPartySoftwareCI Tickets related to freebsd-testing@ URL: https://preview.tinyurl.com/y9maauwg FreeBSD CI Repository URL: https://github.com/freebsd/freebsd-ci Contact: Jenkins Admin Contact: Li-Wen Hsu The FreeBSD CI team maintains continuous integration system and related tasks for the FreeBSD project. The CI system regularly checks the committed changes can be successfully built, then performs various tests and analysis of the results. The results from build jobs are archived in an artifact server, for the further testing and debugging needs. The CI team members examine the failing builds and unstable tests, and work with the experts in that area to fix the code or adjust test infrastructure. The details are of these efforts are available in the weekly CI reports. During the fourth quarter of 2019, we worked with the contributors and developers in the project for their testing needs and also worked with many external projects and companies to improve their support of FreeBSD. The FreeBSD Hardware Testing Lab is online in this quarter. It's still in work in progress stage and we are merging the different versions and will integrate more tightly to the main CI server. We are also working on make this work more easierly to be reproduced. Work in progress: * Collecting and sorting CI tasks and ideas at https://hackmd.io/bWCGgdDFTTK_FG0X7J1Vmg * Setup the CI stage environment and put the experimental jobs on it * Implementing automatic tests on bare metal hardware * Adding drm ports building test against -CURRENT * Testing and merging pull requests at https://github.com/freebsd/freebsd-ci/pulls * Planning for running ztest and network stack tests * Helping more 3rd software get CI on FreeBSD through a hosted CI solution * Adding LTP test jobs. * Adding non-x86 test jobs. * Adding external toolchin related jobs. Please see freebsd-testing@ related tickets for more WIP information. This project was sponsored by The FreeBSD Foundation. __________________________________________________________________ Projects Projects that span multiple categories, from the kernel and userspace to the Ports Collection or external projects. IPSec Extended Sequence Number (ESN) support Contact: Patryk Duda Contact: Marcin Wojtas Extended Sequence Number (ESN) is IPSec extension defined in RFC4303 Section 2.2.1. It makes possible to implement high-speed IPSec implementations where standard, 32-bit sequence number is not sufficent. Key feature of the ESN is that only low order 32 bits of sequence number are transmitted over the wire. High-order 32 bits are maintained by sender and receiver. Additionally high-order bits are included in the computation of Integrity Check Value (ICV) field. Extended Sequence Number support contains following: * Modification of existing anti-replay algorithm to fulfil ESN requirements * Trigger soft lifetime expiration at 80% of UINT32_MAX when ESN is disabled * Implement support for including ESN into ICV in cryptosoft engine in both encrypt and authenticate mode (eg. AES-CBC and SHA256 HMAC) and combined mode (eg. AES-GCM) * Implement support for including ESN into ICV in AES-NI engine in both encrypt and authenticate mode and combined mode Remaining work: * Upstream patches of the anti-replay algorithm * Adjust implementation of crypto part after the reworked Open Crypto Framework gets stable This project was sponsored by Stormshield. __________________________________________________________________ NFS Version 4.2 implementation Contact: Rick Macklem RFC-7862 describes a new minor revision to the NFS Version 4 protocol. This project implements this new minor revision. The NFS Version 4 Minorversion 2 protocol adds several optional features to NFS, such as support for SEEK_DATA/SEEK_HOLE, file copying done on the server that avoids data transfer over the wire and support for posix_fallocate(), posix_fadvise(). Hopefully these features can improve performance for certain applications. This project has basically been completed. The code changes have now all been committed to head/current and should be released in FreeBSD 13. Testing by others would be appreciated. To do testing, an up to date head/current system is required. Client mounts need the "minorversion=2" mount option to enable this protocol. The NFS server will have NFSv4.2 enabled by default. __________________________________________________________________ DTS Update Contact: Emmanuel Vadot DTS files (Device Tree Sources) were updated to be on par with Linux 5.4 for HEAD and 5.2 for the 12-STABLE branch. The DTS for the RISC-V architecture are now imported as well. __________________________________________________________________ RockChip Support Contact: Contact: Emmanuel Vadot Contact: Michal Meloun RockChip RK3399 now has USB3 support, some configuration such as device mode are still not supported however host mode should work on any board. Support for SPI has been committed which enables ability to interact with SPI flash if present. All regulators for the RK808 PMIC (Power Management IC) have been added. All clocks are now supported which completes clock and reset implementation, previously only clocks from devices with drivers were supported. The TS-ADC (Temperature Sensor ADC) is now supported, this adds the ability to read temperature of the CPU and GPU via sysctl hw.temperature . Initial PCIe support has been committed and verified working on several different boards. Known working devices are NVMe devices and PCIe cards that doesn't utilize PCIe switching or bridge functionality. Card Detection for SDCard on RK3328 and RK3399 is now supported. There is still some problems if the board is using a GPIO for CD instead of the internal detection mechanism. __________________________________________________________________ Creating virtual FreeBSD appliances from RE VMDK images Links freebsd-mkova URL: https://github.com/gonzoua/freebsd-mkova Contact: Oleksandr Tymoshenko OVA is a file format for packaging and distributing virtual appliances: pre-configured virtual machine images. Virtual appliance file contains full VM information like the number of CPUs, amount of memory, list of virtual devices, it also includes disk images. Applications like VirtualBox or VMWare can import OVA files; this process can be easily automated. freebsd-mkova is a CLI tool to create OVA files using VMDK images provided by FreeBSD RE. For now, only a limited set of attributes can be specified: VM name, number of CPU, amount of memory, and disk size. The tool also does only cursory sanity checks on the VMDK file format, assuming it's a monolithic sparse file and that it has to be converted to the stream-optimized format. The script can be extended to make hardware configuration more flexible and VMDK parser more robust. __________________________________________________________________ Kernel Updates to kernel subsystems/features, driver support, filesystems, and more. SoC audio framework and RK3399 audio drivers Links rk3399_audio URL: https://github.com/gonzoua/freebsd/tree/rk3399_audio Contact: Oleksandr Tymoshenko Most modern SoCs and devboards have audio support in one form or another, but it's one of the areas that are overlooked by FreeBSD driver developers. The most common architecture for the audio pipeline on a single-board computer consists of two DAIs (digital audio interfaces): CPU and codec, connected by a serial bus. CPU DAI is a SoC IP block that operates with samples: obtains them from the driver for playback or provides them to the driver for recording through FIFOs or DMA requests. Audio samples leave (or arrive at) the SoC through a serial bus, usually I2S, that is connected to Codec DAI. Codec DAI is an external (to the SoC) chip that packs one or more DAC/ADC blocks along with mixers, amplifiers, and probably more specialized devices like filters and/or sound effects. The analog part of the codec is connected to microphones/headphones/speakers. On SBCs, the codec usually communicates with SoC through two interfaces: data path, over which audio samples travel, and a control interface that is used to read/write chip registers and configure its behavior. The most common choices for these are I2S and I2C buses, respectively. For FDT-enabled devices, an audio pipeline is described as a virtual DTB node that has links to the CPU and codec device(s), and which specifies the data format, and clock details that both the CPU and the codec chips would use. It also may have more than one CPU/codec pair. Using Firefly-RK3399 as a test device, I was able to implement I2S driver for RK3399 SoC (PIO mode, playback only), the driver for Realtek's RT5640 chip (headphones playback only + mixer controls) and a base outline of SoC audio framework. Some bits of rk_i2s and the framework were ported from the NetBSD code developed by Jared McNeill. On my WIP branch, I can play mp3 audio and control playback volume. The primary missing functionalities at the moment are recording support, multi-link audio cards, DMA support. The most critical among these is DMA support. In the current implementation, all buffer management is placed at the ausoc layer, which is not going to work for DMA, because only the CPU DAI driver would know about the memory constraints and access mechanisms. The current state of RK3399 support does not allow to implement DMA transfers for rk_i2s easily, but I plan to look into this right after adding recording support, which should not be a lot of work. __________________________________________________________________ FreeBSD on Microsoft HyperV and Azure Links FreeBSD on MicrosoftAzure wiki URL: https://wiki.freebsd.org/MicrosoftAzure FreeBSD on Microsoft HyperV URL: https://wiki.freebsd.org/HyperV Contact: FreeBSD Integration Services Team Contact: Wei Hu Contact: Li-Wen Hsu Wei is working on HyperV Socket support for FreeBSD. HyperV Socket provides a way for host and guest to communicate using common socket interfaces without networking support. Some features in Azure require HyperV Socket support in guest. It is planned to commit the code by the end of February. This project is sponsored by Microsoft. Details of HyperV Socket is available at https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/user-guide/make-integration-service Li-Wen and Wei are working on improving FreeBSD release on Azure. During this quarter, Wei has published the 11.3-RELEASE on Azure. Li-Wen is working on the FreeBSD release codes related to Azure for the -CURRENT and 12-STABLE branches. This project is sponsored by Microsoft and FreeBSD Foundation. __________________________________________________________________ FreeBSD on EC2 ARM64 Links FreeBSD/ARM 12 in AWS Marketplace URL: https://aws.amazon.com/marketplace/pp/B081NF7BY7 FreeBSD/EC2 Patreon URL: https://www.patreon.com/cperciva M6G vs M5 buildworld cost/time performance URL: https://twitter.com/cperciva/status/1206688489518985216 Contact: Colin Percival In November 2018, Amazon Web Services announced the first Elastic Compute Cloud (EC2) instances built around the ARM64 platform. While FreeBSD supported the ARM64 platform, running on this specific virtual machines took some additional work, but by April 2019 the weekly snapshot builds performed by the Release Engineering Team included ARM64 AMIs for FreeBSD HEAD. In November 2019 FreeBSD 12.1 was released, including the first "RELEASE" FreeBSD EC2/ARM64 AMIs. A few weeks later, FreeBSD/ARM64 was added as a new "product" to the AWS Marketplace. At the re:Invent 2019 conference in December 2019, Amazon announced a second family of ARM64 instances, known variously as "Graviton 2" and "M6G". These are far more powerful than the first-generation ARM64 EC2 instances, and have a roughly 40% price/performance advantage over the "M5" family of x86 EC2 instances; and existing FreeBSD 12.1 and HEAD AMIs run "out of the box" on these instances. Work is currently underway to improve kernel locking scalability on these instances; with high levels of parallelism (e.g. buildworld -j64) the G6M instances have approximately 1.5x higher sys:user ratios than equally-sized M5 instances, suggesting that there is room for improvement here. Two issues have been recently identified, both likely relating to ACPI: * EC2 "StopInstance" API calls, which translate to ACPI "power button" notifications, do not trigger FreeBSD to shut down; this results in a timeout from EC2 and a "hard poweroff". * Hotplugging/unplugging EBS volumes, which normally operates via ACPI device notifications, does not work. Help from developers familiar with ARM64 and ACPI would be much appreciated. This project was sponsored by FreeBSD/EC2 Patreon. __________________________________________________________________ ENA FreeBSD Driver Update Links ENA README URL: https://github.com/amzn/amzn-drivers/blob/master/kernel/fbsd/ena/README Contact: Michal Krawczyk Contact: Maciej Bielski Contact: Marcin Wojtas ENA (Elastic Network Adapter) is the smart NIC available in the virtualized environment of Amazon Web Services (AWS). The ENA driver supports multiple transmit and receive queues and can handle up to 100 Gb/s of network traffic, depending on the instance type on which it is used. Completed since the last update: * Upstream of the driver v2.1.0 version, introducing: * Netmap support * Driver structure rework (split datapath code from initialization) * Fix for keep-alive timeout due to prolonged reset * Enable LLQ mode on arm64 instances by enabling memory mapped as WC Work in progress:: * ENA v2.2.0 release, introducing new bug fixes, features and other improvements This project was sponsored by Amazon.com Inc. __________________________________________________________________ Architectures Updating platform-specific features and bringing in support for new hardware platforms. PowerPC on Clang Contact: Justin Hibbits Contact: Brandon Bergren Contact: Alfredo Dal'Ava Júnior Shortly before the end of the year all 3 PowerPC targets (powerpc, powerpc64, powerpcspe) switched to Clang as the base compiler. This was an effort spanning nearly the full year, with several people involved. 32-bit PowerPC platforms (powerpc, powerpcspe) still require GNU ld, but powerpc64 uses LLD as the base linker. The other two platforms will migrate as soon as LLD is ready, which should be in the next several months. With the switch to Clang and LLD, powerpc64 also switched to ELFv2, a modern ABI initially targeted for Linux powerpc64le (little endian), but the ABI itself is endian agnostic; however, ELFv2 is binary incompatible with ELFv1. FreeBSD is still big endian on all powerpc targets. __________________________________________________________________ NXP ARM64 SoC support Contact: Marcin Wojtas Contact: Artur Rojek The Semihalf team initiated working on FreeBSD support for the NXP LS1046A SoC LS1046A are quad-core 64-bit ARMv8 Cortex-A72 processors with integrated packet processing acceleration and high speed peripherals including 10 Gb Ethernet, PCIe 3.0, SATA 3.0 and USB 3.0 for a wide range of networking, storage, security and industrial applications. Completed since the last update: * QSPI * Network performance improvements Todo: * Upstreaming of developed features. This work is expected to be submitted/merged to HEAD in the Q1 of 2020. This project was sponsored by Alstom Group. __________________________________________________________________ Userland Programs Changes affecting the base system and programs in it. Linux compatibility layer update Contact: Edward Tomasz Napierala Linux binaries of Linux Test Projects tests are now part of the FreeBSD Continuous Integration infrastructure. This makes it easy to track progress in improving the Linux compatibility layer, and to detect regressions. There was a fair number of all kinds of improvements to the layer, ranging from updated linux(4) man page, to a new linux rc script, which now takes care of eg mounting Linux-specific filesystems or setting ELF fallback brand, to new syscalls, to tiny improvements such as making ^T work for Linux binaries. From the user point of view, when running 13-CURRENT, Linux jails are now in a mostly working state: you can SSH into a jail with CentOS 8 binaries, run screen(1), Emacs, Postgres, OpenJDK 11, use yum upgrade... Of course there's still a bunch of things that need work: * There is a patch from chuck@ that makes core dumps work for Linux binaries; this will make debugging much easier * There are pending reviews for patches that add extended attributes support, fexecve(2) syscall, sendfile; they require wrapping up and committing * There are over 400 failing LTP tests. Some of them are false positives, some are easy to fix bugs, some require adding new system calls. Any help is welcome. This project was sponsored by FreeBSD Foundation. __________________________________________________________________ Ports Changes affecting the Ports Collection, whether sweeping changes that touch most of the tree, or individual ports themselves. Ports Collection Links About FreeBSD Ports URL: https://www.FreeBSD.org/ports/ Contributing to Ports URL: https://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing/ports-contributing.html FreeBSD Ports Monitoring URL: http://portsmon.freebsd.org/index.html Ports Management Team URL: https://www.freebsd.org/portmgr/index.html Contact: René Ladan Contact: FreeBSD Ports Management Team The Ports Management Team is responsible for overseeing the overall direction of the Ports Tree, building packages, and personnel matters. This entry shows what happened in the last quarter. 2019Q4 closed with a total of 38,200 ports and 2180 open PRs of which a small 470 PRs are unassigned. Last quarter saw 7907 commits from 157 committers to the HEAD branch and 358 commits from 61 committers to the 2019Q4 branch. This seems to suggest a small increase in activity compared to the quarter before. During the last quarter, we welcomed Oleksii "Alex" Samorukov (samm@) and Scott Long (scottl@, already a source committer) as new ports committers. We also said goodbye to az@, brd@, dtekse@, eadler@, and johans@. The default versions of some ports changed: Lazarus is now at version 2.0.6, Samba at 4.10, and Python at 3.7. The web browsers received their updates too: Chromium is now at version 78.0.3904.108, Firefox at version 72.0 and its ESR counterpart at version 68.4.0. Finally, the Qt stack got updated to version 5.13.2. Some modernizations took place: the "palm" category was removed as well as the virtual "ipv6" category. IPv6 support (next to IPv4) is now considered the norm. Lastly, the CentOS 6 ports were removed after their CentOS 7 counterparts were made the default in the previous quarter. As always, antoine@ was happy to take your exp-runs, this time a total of 30, for various ports and framework updates, default version updates, and the removal of OpenJDK 6 and OpenJRE 6. __________________________________________________________________ KDE on FreeBSD Links KDE FreeBSD URL: https://freebsd.kde.org/ KDE Community FreeBSD URL: https://community.kde.org/FreeBSD Contact: Adriaan de Groot The KDE on FreeBSD project packages the software produced by the KDE Community for FreeBSD. The software includes a full desktop environment, the art application https://kdenlive.org and hundreds of other applications that can be used on any FreeBSD desktop machine. The monthly releases of KDE Frameworks, bugfix-releases of KDE Plasma Desktop and the quarterly feature release of KDE Plasma Desktop were all landed in the ports tree shortly after upstream releases. There were also monthly KDE Applications bugfix-releases which also landed in a timely manner. Digikam landed a new release thanks to Dima Panov. We hope this gets rid of the instability caused by the previous release update from last quarter. The open bugs list grew to 32 this quarter with a handful of strange build failures. We welcome detailed bug reports and patches. KDE packaging updates are prepared in a copy of the ports repository on GitHub and then merged in SVN. We welcome pull requests there as well. __________________________________________________________________ Java on FreeBSD Links OpenJDK 11 repository at FreeBSD GitHub URL: https://github.com/freebsd/openjdk-jdk11u Contact: Greg Lewis During Q4 the FreeBSD java porting effort features smaller updates than those of the previous quarters. However, the following changes are worth mentioning: * Updated ports for OpenJDK 8u232, 11.0.5, and 13.0.1 * Removal of the EOL'ed Java 6, 9, and 10 ports * Fixed remote debugging for Java 11+ * Fixed a problem with running external processes for Java 11+ This project was sponsored by FreeBSD Foundation. __________________________________________________________________ Electron and VSCode Links Electron port URL: https://github.com/tagattie/FreeBSD-Electron VSCode port URL: https://github.com/tagattie/FreeBSD-VSCode Contact: Hiroki Tagato Contact: Luca Pizzamiglio Electron is a popular framework to build desktop application using JavaScript, HTML and CSS. Few months ago, electronjs has been added to the ports tree. Currently version 4.x and 6.x are supported. In the last quarter, a popular application, the powerful VSCode editor, has been added to the ports tree as well. VSCode is based on electron 6.x atom, another popular editor, is still a work in progress and it's based on electron 4.x Many thanks to Hiroki, for the hard work, and to Antoine, for support of the special poudriere configuration needed to build VSCode. __________________________________________________________________ Bastille Links Bastille GitHub URL: https://github.com/BastilleBSD/bastille Bastille Templates URL: https://gitlab.com/bastillebsd-templates Bastille Website URL: https://bastillebsd.org Contact: Christer Edwards What is Bastille? Bastille is an open-source system for automating deployment and management of containerized applications on FreeBSD. Bastille uses FreeBSD jails as a container platform and adds template automation to create a Docker-like collection of containerized software. The template collection currently validates 30-40 applications from the ports tree, and is growing! Templates take care of installing, configuring, enabling, and starting the software, providing an automated way of building containerized stacks. Bastille is available in ports at sysutils/bastille. Q4 2019 Status In Q4 2019 Bastille published three releases (for a total of ten releases in 2019). Highlights from these updates include: * support for "thin" (shared base) and "thick" (unique base) jails * support for INCLUDE and FSTAB in template system * upgrade support for shared and unique base jails * GitLab CI/CD testing for all official templates * automatic template validation and CVE scan * dedicated pf table for private IP jails Bastille saw an increase in community contributions with six new GitHub contributors. These people generously improved error checking, release validation (sha256), firewall functionality, flexible networking and initial support for resource limits! We want to thank everyone that contributed to Bastille in 2019. Your support has been amazing! __________________________________________________________________ Universal Packaging Tool (upt) Links Upt repositories URL: https://framagit.org/upt/ Upt itself URL: https://framagit.org/upt/upt/ The FreeBSD backend URL: https://framagit.org/upt/upt-freebsd Contact: The upt mailing list Contact: <#upt-packaging> The Universal Package Manager (upt) is a tool designed to easily port software from common upstream package archives (such as https://rubygems.org/) to various operating systems, including FreeBSD, of course. A lot of similar tools already exist: pytoport (which creates FreeBSD ports for PyPI packages), gem2deb (which creates Debian packages from a Ruby gem), and many others. The main difference between these tools and upt is that the latter uses a modular design, allowing it to handle packages from many sources and support many different operating systems through plugins. You may try upt by installing sysutils/py-upt, sysutils/py-upt-pypi and sysutils/py-upt-freebsd. Suppose you would like to package "upt-cran", which is hosted on PyPI. You could do it like so: # upt package -f pypi -b freebsd -o /usr/ports/sysutils/ upt-cran $ tree /usr/ports/sysutils/py-upt-cran /usr/ports/sysutils/py-upt-cran |-- Makefile |-- distinfo `-- pkg-descr $ cat sysutils/py-upt-cran/Makefile # $FreeBSD: head/en_US.ISO8859-1/htdocs/news/status/report-2019-10-2019-12.xml 53827 2020-01-26 13:49:47Z trasz $ PORTNAME= upt-cran DISTVERSION= 0.1 CATEGORIES= sysutils python MASTER_SITES= CHEESESHOP PKGNAMEPREFIX= ${PYTHON_PKGNAMEPREFIX} MAINTAINER= python@FreeBSD.org COMMENT= CRAN frontend for upt LICENSE= BSD3CLAUSE LICENSE_FILE= ${WRKSRC}/XXX RUN_DEPENDS= ${PYTHON_PKGNAMEPREFIX}lxml>0:devel/py-lxml@${PY_FLAVOR} \ ${PYTHON_PKGNAMEPREFIX}requests>0:www/py-requests@${PY_FLAVOR} \ ${PYTHON_PKGNAMEPREFIX}upt>0:sysutils/py-upt@${PY_FLAVOR} TEST_DEPENDS= ${PYTHON_PKGNAMEPREFIX}requests-mock>0:www/py-requests-mock@${PY_FLAVOR } USES= python USE_PYTHON= autoplist distutils .include Note that the Rubygems and CPAN frontends are also available (sysutils/py-upt-rubygems and sysutils/py-upt-cpan). Bug reports and comments about this new tool are welcome. __________________________________________________________________ Wine on FreeBSD Links Wine homepage URL: https://www.winehq.org Contact: Gerald Pfeifer A lot has happened since our last quarterly report. The Wine 4 release series has been in our tree for nearly a year and proven rather stable. Both that port and wine-devel, which tracks bi-weekly development releases, have seen regular adjustments to infrastructure changes and small improvements, in particular also around non-default options. Now we need help! WoW64 (or Wine on Wine 64) allows running both 32-bit and 64-bit Windows applications in one installation. A volunteer has proposed * a general framework for lib32- companion libraries https://reviews.freebsd.org/D16830 * an approach directly using our Wine ports https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242625 to make this work and we do not have the expertise nor facilities to properly review, test, and maintain those ourselves. If you can facilitate getting (at least one of) these into the tree, please help! And if you'd like to assume co-maintainership or sole maintainership of emulators/wine*, that is an option, too. __________________________________________________________________ Third-Party Projects Many projects build upon FreeBSD or incorporate components of FreeBSD into their project. As these projects may be of interest to the broader FreeBSD community, we sometimes include brief updates submitted by these projects in our quarterly report. The FreeBSD project makes no representation as to the accuracy or veracity of any claims in these submissions. sysctlbyname-improved Links gitlab.com/alfix/sysctlbyname-improved URL: https://gitlab.com/alfix/sysctlbyname-improved Contact: Alfonso Sabato Siciliano The FreeBSD kernel maintains a Management Information Base (MIB) where a component (object) represents a parameter of the system. The sysctl() system call explores the MIB to find an object by its Object Identifier (OID) and calls its handler to get or set the value of the parameter. The sysctlbyname() syscall (or the old function) accepts the name of the object (instead of its OID) to identify it. The purpose of this project is to allow sysctlbyname() to handle: * a CTLTYPE_NODE with a no-NULL handler, example "kern.proc.pid.\"; * an object with some level-name equals to the '\0' character, example "security.jail.param.allow.mount."; A sysctlbyname() clone is provided: sysctlbyname_improved(), the implementation core is a new sysctl internal node to get the OID of a node by its name eventually expanded with an input for its handler; both, can be installed via _sysutils/sysctlbyname-improved-kmod_. The internal node is also used by the sysctlmif_oidinputbyname() function of the _devel/libsysctlmibinfo2_ userland library and can be handled by the SYSCTLINFO_BYNAME macro of the sysctlinfo interface (described in the previous quarterly status report). __________________________________________________________________ pot and the nomad pot driver Links Nomad pot driver URL: https://github.com/trivago/nomad-pot-driver Pot project URL: https://github.com/pizzamig/pot minipot URL: https://github.com/pizzamig/minipot Contact: Luca Pizzamiglio Contact: Esteban Barrios The pot utility added support to private bridges: a group of jail can now use a dedicated bridge, instead of the public one, improving isolation. Moreover, several small bugs have been found and fixed, and support to pre/post start/stop hook script has been added. The nomad pot driver received support for nomad restart without drain and improved configuration stability. A new port called minipot has been added: this port will install configuration files and dependencies, converting a FreeBSD machine in a single node cluster. It will install nomad, consul, pot, the nomad pot driver and traefik, already configured and ready to use. Experimental work has been done on a tool that allows to create and run pot images (FreeBSD jails) on other operating systems (Linux and Mac), adopting an approach similar to docker machine. We hope to make this tool available soon. Next steps: * add dual IP stack support to pot * add private bridge support to the nomad pot driver * improve usability to create images This project was sponsored by trivago N.V.. __________________________________________________________________ 7 Days Challenge Links 7 Days Challenge URL: https://wiki.freebsd.org/MichaelCrilly/7dayschallenge Contact: Michael Crilly The 7 Days Challenge is an educational initiative to help people onboard with FreeBSD more easily. It will use a combination of tutorials, guides and how-tos to get users engaged with FreeBSD quickly, target specific end goals the user might have for FreeBSD, and more. The primary objective is to demonstrate FreeBSD's capabilities as a modern, relevant operating system in today's Cloud centric, automated business models. This project was sponsored by OpsFactory Pty Ltd (Australia). __________________________________________________________________ NomadBSD Links NomadBSD Website URL: https://www.nomadbsd.org/ NomadBSD Github URL: https://www.github.com/NomadBSD/NomadBSD NomadBSD Developer Mailing List URL: https://www.freelists.org/list/nomadbsddevs Contact: NomadBSD Team NomadBSD is a persistent live system for USB flash drives, based on FreeBSD. Together with automatic hardware detection and setup, it is configured to be used as a desktop system that works out of the box, but can also be used for data recovery, for educational purposes, or testing FreeBSD's hardware compatibility. After one release candidate the NomadBSD Team finished and released NomadBSD 1.3 on December 7th. This release is based on FreeBSD 12.1, fixed a lot of bugs and added new packages and features. Along those features are the option to install NomadBSD on ZFS and the use of an automatic configuration when running NomadBSD in VirtualBox. New tools developed by the NomadBSD Team and added to version 1.3 are nomadbsd-dmconfig to select a display manager theme, nomadbsd-adduser which adds new user accounts and DSBBg to change the background image. All these are using the Qt-Toolkit. In Q4 we added two mirrors in France and Germany and would like to thank nosheep.fr and fau.de for them. We are looking for people to help the project. Help is much appreciated in all areas: * Translation of program interfaces * Design artwork * Programming new tools, extend existing ones * Tests and Bug reports / UX and feature suggestions * Mirrors outside of Europe Open tasks: * Support installation on disk partitions and add a partition editor GUI. * Complete disk encryption * Add a user-friendly network manager From owner-freebsd-current@freebsd.org Mon Jan 27 20:36:37 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5FEF622E17B for ; Mon, 27 Jan 2020 20:36:37 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-20.consmr.mail.gq1.yahoo.com (sonic317-20.consmr.mail.gq1.yahoo.com [98.137.66.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4861kD3WfHz49N4 for ; Mon, 27 Jan 2020 20:36:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: WvpiRxkVM1nehU5YT44ndzcgjJQjYhhDWPNSxK0kfYp9Th4v.8wIYPyTIAZvyf3 EbWh3sLK.q5l9dRD5ERmVNarU63xkXtPUvknljRc9BiTSgFkdpemG5T9taQDNvPDeO2qsVKNWLZs Qle3jK6hSUEmLF6gfyK_eMNy7yVfjzZSvDndb5_D6WT9MHrxalUcbNGO3Yx_lHFYTDhEixNdG0Go LXJdVq_tTzsw4OO1X6B8YoK1rUgHKTUo1Vw9qHEzL6s88Kx3f13YJubqwcGpZfMNW9xSpRLmSd2U lNavyL5xOm1IevCEZWufle1Y.Nv4FMh33ydcndyhj_0DyOO9MclGYjz5FlkxakIZPWZsdCq8qiaa eqr4ex_xwVghXRLi6r3oWX26tmhDyYAmq_zhcX7N.SYP.wrJDax85tniw9X0ZzChJ0vvcHeQnlFK rk3r1h_2UkrfaTDbPrtVpr0m76mNTpQIs_UdFCTdx19XSkZpwpAFeawzri5_jI81rGmky5.lyIXz vcvLKC0QsOKcxNOo5.fAKZ9DRtlIE5t2nVBblmJaQIF5QLGzvNRx9i4VMUT4DAM8QhcIyZ5DZAmG R2GsrpDQdhvLz3Usb_OSw0kzVCCjiuPocxHWNm.HGBBH1PrOmeAOWHdGGzgbdD3eDZHQynPR.gPQ OO2DKcweJrq5CmoXP6lo1xNDro91FW14gV_SdcI51YivKsDmcul9c8Uz80k4SEMYZKHNsBHaf_2x B1EaoOVrhYRqVI973kBWuj4ddcbombWF4_09.opSIwmX3ZXtGEKcSTkEObRjke0AymSEQgi5LWg4 F5ptstobCSLxeEr2U.pBK33ZzXDQ.TjXn6zffyMlXY3ACC0fyqUrZXPjO32c.G48NvxorwvUgxWK nnf_EZaOQtpq2G0Pw_r7Nb6BtyGJmSGUK_f5Mfp2WyWQ3VGiGiv0ehRAU0o44vXX308FTZGEZcPY tOJY7wK8VEbyL4qF8E3eFrD0uwvNRWAT8ugq65KlTltlxHoyODdya3FiPp.4nx3IR2h4nHEXAGzG 9J6hGIZRszeRxPnpTypUuIDkE32VLBEjgx0PxCZiQfdsY5tQMDB7y4au9.qpeaEg_oJ3PEU0EnEA 08r.WEnkT0a0zNEkB_GBiyvFxELtIi.PC8fTtUjFKHh5LyLUO_ZDzu1pQakJ_Xo44_D4eqB9WO.i D2kK1l8.JuivbQ07IoOLtYrNzag86NzYXO75u4b_voSU6z5r_BKcpMuxDWAS_lr04S0B.pd78g9d r3MsAtnX6OcnMn5rs2IrBd7FOow5PGnCBDPJXbc88dAZD6kuoAs68BE8jfkaFUcRzwvzmHqqmRCE vMwWsBHV5DBvyubDSNZHAbjHCLVx2Y_mabwooL32I7.NVMmaNwdPYch_iGAOMtIp9BRb8s7pvRzo 5i_4UR1Lj0mrdY6cL_G77JOrS5sCHD0mrc_MSYEnTBGGXt1r3NpCgQ6_hvfDRhHexzGhaYA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Mon, 27 Jan 2020 20:36:34 +0000 Received: by smtp432.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID dd65fcb9de299ccb491ebb566e1d1d57; Mon, 27 Jan 2020 20:36:29 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Subject: Re: After update to r357104 build of poudriere jail fails with 'out of swap space' From: Mark Millard In-Reply-To: Date: Mon, 27 Jan 2020 12:36:27 -0800 Cc: "Rodney W. Grimes" , sgk@troutmask.apl.washington.edu, freebsd-current@freebsd.org, yasu@utahime.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <202001261745.00QHjkuW044006@gndrsh.dnsmgr.net> <202001271309.00RD96nr005876@slippy.cwsent.com> To: Cy Schubert X-Mailer: Apple Mail (2.3608.40.2.2.4) X-Rspamd-Queue-Id: 4861kD3WfHz49N4 X-Spamd-Bar: / X-Spamd-Result: default: False [-0.96 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.45)[-0.452,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_GOOD(-0.10)[text/plain]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-0.01)[-0.009,0]; RCVD_COUNT_TWO(0.00)[2]; RCPT_COUNT_FIVE(0.00)[5]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[146.66.137.98.list.dnswl.org : 127.0.5.0]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.00)[ip: (3.16), ipnet: 98.137.64.0/21(0.84), asn: 36647(0.67), country: US(-0.05)]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 27 Jan 2020 20:36:37 -0000 On 2020-Jan-27, at 10:20, Cy Schubert = wrote: > On January 27, 2020 5:09:06 AM PST, Cy Schubert = wrote: >>> . . .=20 >>=20 >> Setting a lower arc_max at boot is unlikely to help. Rust was = building >> on=20 >> the 8 GB and 5 GB 4 core machines last night. It completed = successfully >> on=20 >> the 8 GB machine, while using 12 MB of swap. ARC was at 1307 MB. >>=20 >> On the 5 GB 4 core machine the rust build died of OOM. 328 KB swap = was=20 >> used. ARC was reported at 941 MB. arc_min on this machine is 489.2 = MB. >=20 > MAKE_JOBS_NUMBER=3D3 worked building rust on the 5 GB 4 core machine. = ARC is at 534 MB with 12 MB swap used. If you increase vm.pageout_oom_seq to, say, 10 times what you now use, does MAKE_JOBS_NUMBER=3D4 complete --or at least go notably longer = before getting OOM behavior from the system? (The default is 12 last I checked. So that might be what you are now using.) Have you tried also having: vm.pfault_oom_attempts=3D"-1" (Presuming you are not worried about actually running out of swap/page space, or can tolerate a deadlock if it does run out.) This setting presumes head, not release or stable. (Last I checked anyway.) It would be interesting to know what difference those two settings together might make for your context: it seems to be a good context for testing in this area. (But you might already have set them. If so, it would be good to report the figures in use.) Of course, my experiment ideas need not be your actions. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Mon Jan 27 20:48:53 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2F85D22E7FF for ; Mon, 27 Jan 2020 20:48:53 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 48620M5gg3z4BMg for ; Mon, 27 Jan 2020 20:48:51 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id wBJOi3ARN17ZDwBJQiz8My; Mon, 27 Jan 2020 13:48:49 -0700 X-Authority-Analysis: v=2.3 cv=ZsqT1OzG c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=kj9zAlcOel0A:10 a=Jdjhy38mL1oA:10 a=CjxXgO3LAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=o_fEvd48_l3giiTbq5UA:9 a=fA33GuqEjCHS9fZ1:21 a=MqgclpkY7po7t7Dk:21 a=CjuIK1q_8ugA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 Received: from slippy.cwsent.com (slippy8 [10.2.2.6]) by spqr.komquats.com (Postfix) with ESMTPS id 96CFDB6E; Mon, 27 Jan 2020 12:48:45 -0800 (PST) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id 00RKmjFW006729; Mon, 27 Jan 2020 12:48:45 -0800 (PST) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id 00RKmiZs006726; Mon, 27 Jan 2020 12:48:44 -0800 (PST) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <202001272048.00RKmiZs006726@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Mark Millard cc: Cy Schubert , "Rodney W. Grimes" , sgk@troutmask.apl.washington.edu, freebsd-current@freebsd.org, yasu@utahime.org Subject: Re: After update to r357104 build of poudriere jail fails with 'out of swap space' In-reply-to: References: <202001261745.00QHjkuW044006@gndrsh.dnsmgr.net> <202001271309.00RD96nr005876@slippy.cwsent.com> Comments: In-reply-to Mark Millard message dated "Mon, 27 Jan 2020 12:36:27 -0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 27 Jan 2020 12:48:44 -0800 X-CMAE-Envelope: MS4wfJs4Lvme5bWWEocbnJ3A3+ZXgDINNTJhZhOdi+UYh8gApqbPR5dab4arlJ93xGikLsDY8otZXB1Mxvm/8kmWaQlF4A2DWDWS9F6q7pGVsnjGTbj4QCxA KHMZx94ZhhKqtHSQxonLlBo5zmMdXzI7lhRBt+WpU3BEtSQEcTyu/5/jfQqCOWpYxKaY75zYS3q2umURXg4D26mFmST2oVL3/0LgxnFN4/6+6u7Y8cJhEJuY sYQz7YWNyoxCN+1r9s4cJ/KtpUU8uuol8FCEJ82uDQUP5fSSFSRdgJEWC832cdiVoqQ4pFkGnydljpGJq8jHczf/aQYGHOpCC9TGSLJKXYs= X-Rspamd-Queue-Id: 48620M5gg3z4BMg X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 64.59.136.137) smtp.mailfrom=cy.schubert@cschubert.com X-Spamd-Result: default: False [-4.08 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; RECEIVED_SPAMHAUS_PBL(0.00)[17.125.67.70.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; RCPT_COUNT_FIVE(0.00)[6]; REPLYTO_EQ_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_SPF_NA(0.00)[]; FREEMAIL_TO(0.00)[yahoo.com]; RCVD_IN_DNSWL_LOW(-0.10)[137.136.59.64.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; RCVD_TLS_LAST(0.00)[]; IP_SCORE(-2.38)[ip: (-6.14), ipnet: 64.59.128.0/20(-3.18), asn: 6327(-2.47), country: CA(-0.09)]; FROM_EQ_ENVFROM(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 27 Jan 2020 20:48:53 -0000 In message , Mark Millard write s: > > > > On 2020-Jan-27, at 10:20, Cy Schubert wrote: > > > On January 27, 2020 5:09:06 AM PST, Cy Schubert > wrote: > >>> . . . > >> > >> Setting a lower arc_max at boot is unlikely to help. Rust was building > >> on > >> the 8 GB and 5 GB 4 core machines last night. It completed successfully > >> on > >> the 8 GB machine, while using 12 MB of swap. ARC was at 1307 MB. > >> > >> On the 5 GB 4 core machine the rust build died of OOM. 328 KB swap was > >> used. ARC was reported at 941 MB. arc_min on this machine is 489.2 MB. > > > > MAKE_JOBS_NUMBER=3 worked building rust on the 5 GB 4 core machine. ARC is > at 534 MB with 12 MB swap used. > > If you increase vm.pageout_oom_seq to, say, 10 times what you now use, > does MAKE_JOBS_NUMBER=4 complete --or at least go notably longer before > getting OOM behavior from the system? (The default is 12 last I checked. > So that might be what you are now using.) It's already 4096 (default is 12). > > Have you tried also having: vm.pfault_oom_attempts="-1" (Presuming > you are not worried about actually running out of swap/page space, > or can tolerate a deadlock if it does run out.) This setting presumes > head, not release or stable. (Last I checked anyway.) Already there. The box is a sandbox with remote serial console access so deadlocks are ok. > > It would be interesting to know what difference those two settings > together might make for your context: it seems to be a good context > for testing in this area. (But you might already have set them. > If so, it would be good to report the figures in use.) > > Of course, my experiment ideas need not be your actions. It's a sandbox machine. We already know 8 GB works with 4 threads on as many cores. And, 5 GB works with 3 threads on 4 cores. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-current@freebsd.org Mon Jan 27 22:26:06 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A4D40230CC2 for ; Mon, 27 Jan 2020 22:26:06 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-24.consmr.mail.gq1.yahoo.com (sonic312-24.consmr.mail.gq1.yahoo.com [98.137.69.205]) (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 48648Y68sfz4HDX for ; Mon, 27 Jan 2020 22:26:05 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: GqyJprAVM1kZNFHRHv0OpGLFHAi0IqEegE10oxPMNVpTEJCSPi9BuyCDsFZeA2f 1k.Z4dCGqOILRTDXWj_xzVtFvPitkHpDuw9oT_Ei7Ok28fiKWdi6iSbY1RKPxzG.o54IqZFoEs8q XgJHfI6qcLTVpjIJSo9Zwd19snBcReHCwinj4J78oqlL2GZLq_JbBMWmMk4OyvvKGvuVGG2vYBj8 YW_ItwviwOnlWXPQrtxksKPjkYLuI4ukVrdvgHr0AmprDjAmRqhy1WSS6P22o11Phm8EbupQ3_cP j6Pt.EudG8WkqGFiDhLaS4LBLkI3aduws2C.adPC6gWbv9_N.sDr.8cuLZydjZO.aPgC1My.yzIV 2PQQiyccmWhoVDyMUg5i3og0CAvT_W9_irznF25YXW0kHBHUBHogIxoTYBvGV1QGzHjDRT4h.F7O BRBMoukru8pYpLOjcHPxzBAcVQuIGitGRPdoIonfYWJ0BUiuNf2FlZvDmDnmCwIE9Wz9JY4AHJJ2 XrwA7pRwELsS.Nl_FHkH9aWW0HioTHyivk8_ON2XsY3J0eKi2V..RMWkHy3_fPNjf6AhE0UH5zDM cde8y2P_Pv0f._jjSX0t9C8W2oVDTgTiCK5jd6KpzK29jYih0N.75EUwB9Wp2nW2fgv3A9wiT.wi SbIDC8uq830.HkNHsUoSD7.IZU3zz1pjwQDzW5_WsKPPu6MRNJgg4E1S5yxlOA_FpKil8JIsHR_k xJP0HlAmuzxDtGhsLdAb1UMzzzM1YHBW32VCjl48k6JLNTXMkpTcEswvemNy_copWcd72T3wZcPP fVSW95AZk929GRh4osl4AmiouW9ecnovaEsrdfjQpkj232vZC3ljC01leYBM86KXuZuITbvT_qHC Wi8qaThF8Y9PYjGSu5e5DTo2ebCzpqSQqRJTvvJph_2eKLedXK0YzrpXAXBXvndsR7_Mm6kIrlP5 qO4a_Fy1cF5v1ge2ymYO5lkSTDqWfUvtmPuVwAesdJaCiow.VsK3m3FaGaFSgiflPl2TcUc.ykZP AgYybS64pMEXdsXHU982n_z8AZcQ.oouDYybA.2MUJDsrL.VU1SU8t1r9wMmg0AvBWHHPgD6OpB7 UbEWquona.sQVU81hJCOWq3B63xGVW8ZJfZhBpt62JmEO3WxfICf2t0guWNajzqYROuGLuwRPCtk 50qi2_.pDWkEql8v0B4y0rWpq_d9g90ph4Q5zO7e1I13Us9t2cho9xcdewhqSewdpbdRfWzw8T36 td1.ejmGCi6WcSzwBI2jDd7QOwSSB7MIWsiEBggToyGVhfYSGtOyA5GLdn.6Bao1A_ZVJ9DBDvaC pS1MFkbzpEQ97bAaVnF12JE5lUV.VZVhpstV.dJLXo16r11joYPVdmwdgDQGmgaTfkqY9U853Ep9 HULi2tk1Y2ci4zqPRbNK_k76kZRq90mgqWUAshh5hzgWUkQTg8GPvzd_9NJg46jed.Mx2M2w- Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Mon, 27 Jan 2020 22:26:04 +0000 Received: by smtp431.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 3fd107ed9dde4ed448e14cbf5ccc608b; Mon, 27 Jan 2020 22:26:01 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Subject: Re: After update to r357104 build of poudriere jail fails with 'out of swap space' From: Mark Millard In-Reply-To: <202001272048.00RKmiZs006726@slippy.cwsent.com> Date: Mon, 27 Jan 2020 14:25:59 -0800 Cc: "Rodney W. Grimes" , sgk@troutmask.apl.washington.edu, freebsd-current@freebsd.org, yasu@utahime.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <202001261745.00QHjkuW044006@gndrsh.dnsmgr.net> <202001271309.00RD96nr005876@slippy.cwsent.com> <202001272048.00RKmiZs006726@slippy.cwsent.com> To: Cy Schubert X-Mailer: Apple Mail (2.3608.40.2.2.4) X-Rspamd-Queue-Id: 48648Y68sfz4HDX X-Spamd-Bar: / X-Spamd-Result: default: False [-0.52 / 15.00]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; RCPT_COUNT_FIVE(0.00)[5]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.28)[-0.276,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (4.00), ipnet: 98.137.64.0/21(0.84), asn: 36647(0.67), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.25)[0.255,0]; RCVD_IN_DNSWL_NONE(0.00)[205.69.137.98.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[205.69.137.98.rep.mailspike.net : 127.0.0.17]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 27 Jan 2020 22:26:06 -0000 On 2020-Jan-27, at 12:48, Cy Schubert = wrote: > In message , Mark = Millard=20 > write > s: >>=20 >>=20 >>=20 >> On 2020-Jan-27, at 10:20, Cy Schubert = wrote: >>=20 >>> On January 27, 2020 5:09:06 AM PST, Cy Schubert = >> wrote: >>>>> . . .=20 >>>>=20 >>>> Setting a lower arc_max at boot is unlikely to help. Rust was = building >>>> on=20 >>>> the 8 GB and 5 GB 4 core machines last night. It completed = successfully >>>> on=20 >>>> the 8 GB machine, while using 12 MB of swap. ARC was at 1307 MB. >>>>=20 >>>> On the 5 GB 4 core machine the rust build died of OOM. 328 KB swap = was=20 >>>> used. ARC was reported at 941 MB. arc_min on this machine is 489.2 = MB. >>>=20 >>> MAKE_JOBS_NUMBER=3D3 worked building rust on the 5 GB 4 core = machine. ARC is >> at 534 MB with 12 MB swap used. >>=20 >> If you increase vm.pageout_oom_seq to, say, 10 times what you now = use, >> does MAKE_JOBS_NUMBER=3D4 complete --or at least go notably longer = before >> getting OOM behavior from the system? (The default is 12 last I = checked. >> So that might be what you are now using.) >=20 > It's already 4096 (default is 12). Wow. Then the count of tries to get free RAM above the threshold does not seem likely to be the source of the OOM kills. >>=20 >> Have you tried also having: vm.pfault_oom_attempts=3D"-1" (Presuming >> you are not worried about actually running out of swap/page space, >> or can tolerate a deadlock if it does run out.) This setting presumes >> head, not release or stable. (Last I checked anyway.) >=20 > Already there. Then page-out delay does not seem likely to be the source of the OOM = kills. > The box is a sandbox with remote serial console access so deadlocks = are ok. >=20 >>=20 >> It would be interesting to know what difference those two settings >> together might make for your context: it seems to be a good context >> for testing in this area. (But you might already have set them. >> If so, it would be good to report the figures in use.) >>=20 >> Of course, my experiment ideas need not be your actions. >=20 > It's a sandbox machine. We already know 8 GB works with 4 threads on = as=20 > many cores. And, 5 GB works with 3 threads on 4 cores. It would be nice to find out what category of issue in the kernel is driving the OOM kills for your 5GB context with MAKE_JOBS_NUMBER=3D4. Too bad the first kill does not report a backtrace spanning the code choosing to do the kill (or otherwise report the type of issue leading the the kill). Your is consistent with the small arm board folks reporting that = recently contexts that were doing buildworld and the like fine under somewhat older kernels have started getting OOM kills, despite the two settings. At the moment I'm not sure how to find the category(s) of issue(s) that is(are) driving these OOM kills. Thanks for reporting what settings you were using. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Mon Jan 27 23:28:27 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 46DEE232413 for ; Mon, 27 Jan 2020 23:28:27 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-qb1can01on0620.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe5c::620]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4865XW0gtsz4LXy; Mon, 27 Jan 2020 23:28:26 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bre4rz2E8JkvpTwjVtV+pfGtgmqhSp9w+5kOwwaPVN8oH1eHwA1/9I6imhlvfnIKYA9PC4sKTj1cztpB0O/8ibgyHeBQkjR//a5TUPhUTie4orz3Y25r9PdCNlTvZgaJGKxU+bi6+wPThbb25HB9KB7zcxadhC5f122is4h3bffsJJNlKrk/U+LWdnd8pCrLCHRV0wBeBIw2K3NXBENS+75B32msjyTu1BvoLVK3OekfpKjxLdbBN+8yYBz8KopqfHTimdZFBoKU9VLIygx+Ys0C8cp3eO7UGUCT3qcuox36JtHuxnyWzRorZHPCQRiiHamWcze8z1mQv6ppAqJrDA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XjIwH66pSMyCcEu7+7N/aowVthFe1gl31qgJYUoBk7Q=; b=atx3Qo3bgiPhGmYz3hQFci45DCNAB5pxt+OQaeYy/3+nh89IjzwHsMtRHbct5v6DFebXqpeSjpnKUQNN7nZoHpXDXbprleNL/fc0gZRu/sVmr7Z181VDyNQBtEEQxrjKhX96O7IijE02/yzjeAE1JiMgwBYImiztBSIMv66sCvm/r4Uc/i4uNNSztudBrGi1lw4Au8P7P0U/37gVjZuWBX7KU88ZyU6Yh3w4bN4t7QDT301tQP8KC6XA2uglsePdJz919QbXqhVEGAVdPHb3ucitLh0GMIHWbdt3XS3OpAmT1DtmZwVAgy1iUTQltww0TW9eqbbe+90ydn3gcARMTQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none Received: from YQBPR0101MB1427.CANPRD01.PROD.OUTLOOK.COM (52.132.69.153) by YQBPR0101MB2033.CANPRD01.PROD.OUTLOOK.COM (52.132.71.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.23; Mon, 27 Jan 2020 23:28:24 +0000 Received: from YQBPR0101MB1427.CANPRD01.PROD.OUTLOOK.COM ([fe80::6588:45c3:4892:f98]) by YQBPR0101MB1427.CANPRD01.PROD.OUTLOOK.COM ([fe80::6588:45c3:4892:f98%7]) with mapi id 15.20.2665.025; Mon, 27 Jan 2020 23:28:24 +0000 From: Rick Macklem To: John Baldwin , "freebsd-current@FreeBSD.org" Subject: Re: how to use the ktls Thread-Topic: how to use the ktls Thread-Index: AQHVxa2HeRfmo36hWEyrGcMaBhE88KfhEeoAgBxnlpmAAOgvAIAA4IKR Date: Mon, 27 Jan 2020 23:28:24 +0000 Message-ID: References: <5be57c87-90fe-fcbe-ea37-bdb1bcff2da8@FreeBSD.org> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f8380221-8255-45ff-0dd1-08d7a3809b04 x-ms-traffictypediagnostic: YQBPR0101MB2033: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-forefront-prvs: 02951C14DC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(376002)(346002)(136003)(39860400002)(366004)(199004)(189003)(5660300002)(55016002)(9686003)(110136005)(478600001)(8676002)(81156014)(81166006)(786003)(6506007)(186003)(8936002)(7696005)(316002)(26005)(2906002)(71200400001)(66476007)(66556008)(64756008)(66446008)(450100002)(86362001)(91956017)(76116006)(52536014)(66946007)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:YQBPR0101MB2033; H:YQBPR0101MB1427.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-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: iju2krU/IE5n9ginlN9mARJJ9qMBWTD4BH2vycM6JqSGpy/4ymX3ihyv8nx4lUlisHwg/nFo36L6Li89prBg3hJLml1SadrM13ZuDbuaPjAUfBu7omGArZXZWTURMxddHbMgUD/toh2UHRD8Y1vJ/LEvfcbc89YF8Gyu/08/Vtf004lCof3qJClT6Ivxv84WtSOkWkrkSL5sw9zoNKbOB+lDpb/5H/bxOuqhLXRyHSsoL7RoaKLWdiOX/K49evJAe/v0ta65wt643IS/gYa3YwM/plM/G/wpSm12WUdXpAg3mm71gFM8ujnMyUPxBOeA3z546aUwB/EcyH8Ho46kMei78HOgaJOSnIufx733nD/r/CGYn17s6nPqakOhKxc9X9QyKSxZ2FvS94EyQGWpmDmMhD34qL9kgHmITHbNMzcUhj/D28wIFqM8QH7dkw6V x-ms-exchange-antispam-messagedata: OSwp1cjb6I1/ZuJzAbGbptsVrcrgqLXbWDj5XUrC/K5I1EY7iOAtyrhuh6buDfp3i3gtezFM/R7eSb9lVjGBormhYQpirUfv1De+rLh46qkEsGi/lHVapXxeY5EniFVAdngxQpORsjLvhMmH5KME2w== x-ms-exchange-transport-forked: True 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: f8380221-8255-45ff-0dd1-08d7a3809b04 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jan 2020 23:28:24.6810 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: W0OlR7SpsuD5pM2HbUNEt/iWCPezbQ+LvS/uB20HPKDLh+jkZZzyIbGpWzYjnJwXETxZik9Xj9HwC/HWNGi7Sg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQBPR0101MB2033 X-Rspamd-Queue-Id: 4865XW0gtsz4LXy X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 27 Jan 2020 23:28:27 -0000 John Baldwin wrote:=0A= >On 1/26/20 8:08 PM, Rick Macklem wrote:=0A= >> John Baldwin wrote:=0A= >> [stuff snipped]=0A= >>> Hmmm, this might be a fair bit of work indeed.=0A= >>>=0A= >>> Right now KTLS only works for transmit (though I have some WIP for rece= ive).=0A= >>>=0A= >>> KTLS does assumes that the initial handshake and key negotiation is han= dled by=0A= >>> OpenSSL. OpenSSL uses custom setockopt() calls to tell the kernel whic= h=0A= >>> session keys to use.=0A= >>>=0A= >>> I think what you would want to do is use something like OpenSSL_connect= () in=0A= >>> userspace, and then check to see if KTLS "worked". If it did, you can = tell=0A= >>> the kernel it can write to the socket directly, otherwise you will have= to=0A= >>> bounce data back out to userspace to run it through SSL_write() and hav= e=0A= >>> userspace do SSL_read() and then feed data into the kernel.=0A= >>>=0A= >>> The pseudo-code might look something like:=0A= >>>=0A= >>> SSL *s;=0A= >>>=0A= >>> s =3D SSL_new(...);=0A= >>>=0A= >>> /* fd is the existing TCP socket */=0A= >>> SSL_set_fd(s, fd);=0A= >>> OpenSSL_connect(s);=0A= >>> if (BIO_get_ktls_send(SSL_get_wbio(s)) {=0A= >>> /* Can use KTLS for transmit. */=0A= >>> }=0A= >>> if (BIO_get_ktls_recv(SSL_get_rbio(s)) {=0A= >>> /* Can use KTLS for receive. */=0A= >>> }=0A= >>=0A= >> So, I've been making some progress. The first stab at the daemons that d= o the=0A= >> handshake are now on svn in base/projects/nfs-over-tls/usr.sbin/rpctlscd= and=0A= >> rpctlssd.=0A= >>=0A= >> A couple of questions...=0A= >> 1 - I haven't found BIO_get_ktls_send() or BIO_get_ktls_recv(). Are they= in some=0A= >> different library?=0A= >=0A= >They only existing currently in OpenSSL master (which will be OpenSSL 3.0.= 0 when it=0A= >is released). I have some not-yet-tested WIP changes to backport those ch= anges into=0A= >the base OpenSSL, but it will also add overhead to future OpenSSL imports = perhaps,=0A= >so it is something I need to work with secteam@ on to decide if it's viabl= e once I=0A= >have a tested PoC.=0A= >=0A= >I will try to at least provide a patch to the security/openssl port to add= a KTLS=0A= >option "soon" that you could use for testing.=0A= John, I wouldn't worry much about this.=0A= The calls are currently #ifdef notnow in the daemon and I'm fine with that.= =0A= SSL_connect() has returned 1, so the daemon knows that the handshake is com= plete and=0A= the kernel code that did the upcall to the daemon can check for KERN_TLS su= pport.=0A= =0A= >> 2 - After a successful SSL_connect(), the receive queue for the socket h= as 478bytes=0A= >> of stuff in it. SSL_read() seems to know how to skip over it, but = I haven't=0A= >> figured out a good way to do this. (I currently just do a recv(..4= 78,0) on the=0A= >> socket.)=0A= >> Any idea what to do with this? (Or will the receive side of the kt= ls figure out=0A= >> how to skip over it?)=0A= >=0A= >I don't know yet. :-/ With the TOE-based TLS I had been testing with, thi= s doesn't=0A= >happen because the NIC blocks the data until it gets the key and then it's= always=0A= >available via KTLS. With software-based KTLS for RX (which I'm going to s= tart=0A= >working on soon), this won't be the case and you will potentially have som= e data=0A= >already ready by OpenSSL that needs to be drained from OpenSSL before you = can=0A= >depend on KTLS. It's probably only the first few messsages, but I will ne= ed to figure=0A= >out a way that you can tell how much pending data in userland you need to = read via=0A= >SSL_read() and then pass back into the kernel before relying on KTLS (it w= ould just=0A= >be a single chunk of data after SSL_connect you would have to do this for)= .=0A= Well, SSL_read() doesn't return these bytes. I think it just throws them aw= ay.=0A= =0A= I have a simple test client/server where the client sends "HELLO THERE" to = the=0A= server and the server replies "GOODBYE" after the SSL_connect()/SSL_accept(= )=0A= has been done.=0A= --> If the "HELLO THERE"/"GOODBYE" is done with SSL_write()/SSL_read() it w= orks.=0A= however=0A= --> If the above is done with send()/recv(), the server gets the "HELLO THE= RE", but=0A= the client gets 485bytes of data, where the last 7 are "GOODBYE".=0A= --> If I do a recv( ..475..) in the client right after SSL_connect() = it works ok.=0A= =0A= I do this for testing, since it can then do the NFS mount (unencrypted).=0A= =0A= Looking inside SSL_read() I found:=0A= *=0A= 1742 * If we are a client and haven't received the ServerHello etc the= n we=0A= 1743 * better do that=0A= 1744 */=0A= 1745 ossl_statem_check_finish_init(s, 0);=0A= =0A= but all ossl_statem_check_finish_init(s, 0); seems to do is set a variable = "in_init =3D 1".=0A= Then it calls the method->read() function, which I'd guess is in the crypto= code=0A= and it seems to get rid of these bytes. (I hate trying to figure out what c= alls what=0A= for object oriented code;-).=0A= =0A= Btw. SSL_is_finished_init() returns 1 right after the SSL_connect(), so it = seems to=0A= think the hadnshake is done, although it hasn't read these 478 bytes from t= he server.=0A= =0A= Anyhow, I'd guess the TOE engine knows how to do get rid of this stuff like= SSL_read()=0A= does?=0A= =0A= >> I'm currently testing with a kernel that doesn't have options KERN_TLS a= nd=0A= >> (so long as I get rid of the 478 bytes), it then just does unencrypted R= PCs.=0A= >>=0A= >> So, I guess the big question is.... can I get access to your WIP code fo= r KTLS=0A= >> receive? (I have no idea if I can make progress on it, but I can't do a = lot more=0A= >> before I have that.)=0A= >=0A= >The WIP only works right now if you have a Chelsio T6 NIC as it uses the T= 6's TCP=0A= >offload engine to do TLS. If you don't have that gear, ping me off-list. = It=0A= >would also let you not worry about the SSL_read case for now for initial t= esting.=0A= I may contact you in April about this.=0A= Since you've noted above that you haven't started the software version, I m= ight try=0A= coming up with something and will let you know if I do.=0A= =0A= Thanks, rick=0A= From owner-freebsd-current@freebsd.org Mon Jan 27 23:51:08 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8C212232B23 for ; Mon, 27 Jan 2020 23:51:08 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 48662h0nygz4MtJ; Mon, 27 Jan 2020 23:51:07 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (c-73-225-95-104.hsd1.wa.comcast.net [73.225.95.104]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id 00RNox8q051017 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 27 Jan 2020 15:51:00 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: how to use the ktls To: Rick Macklem , John Baldwin , "freebsd-current@FreeBSD.org" References: <5be57c87-90fe-fcbe-ea37-bdb1bcff2da8@FreeBSD.org> From: Julian Elischer Message-ID: Date: Mon, 27 Jan 2020 15:50:54 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Rspamd-Queue-Id: 48662h0nygz4MtJ X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.68 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.78)[-0.782,0]; NEURAL_HAM_LONG(-0.90)[-0.899,0]; ASN(0.00)[asn:36236, ipnet:204.109.60.0/22, country:US] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 27 Jan 2020 23:51:08 -0000 On 1/9/20 2:53 PM, Rick Macklem wrote: > John Baldwin wrote: >> On 1/7/20 3:02 PM, Rick Macklem wrote: Someone once told me they were working on a netgraph node that did TLS encapsulation of a stream. I can not remember who it was, but I do remember they were dubious about being allowed to give it back.  :-( I only mention this as it MAY be an architectural avenue to investigate. Julian >>> Hi, >>> >>> Now that I've completed NFSv4.2 I'm on to the next project, which is making NFS >>> work over TLS. >>> Of course, I know absolutely nothing about TLS, which will make this an interesting >>> exercise for me. >>> I did find simple server code in the OpenSSL doc. which at least gives me a starting >>> point for the initialization stuff. >>> As I understand it, this initialization must be done in userspace? >>> >>> Then somehow, the ktls takes over and does the encryption of the >>> data being sent on the socket via sosend_generic(). Does that sound right? >>> >>> So, how does the kernel know the stuff that the initialization phase (handshake) >>> figures out, or is it magic I don't have to worry about? >>> >>> Don't waste much time replying to this. A few quick hints will keep me going for >>> now. (From what I've seen sofar, this TLS stuff isn't simple. And I thought Kerberos >>> was a pain.;-) >>> >>> Thanks in advance for any hints, rick >> Hmmm, this might be a fair bit of work indeed. > If it was easy, it wouldn't be fun;-) FreeBSD13 is a ways off and if it doesn't make that, oh well.. > >> Right now KTLS only works for transmit (though I have some WIP for receive). > Hopefully your WIP will make progress someday, or I might be able to work on it. > >> KTLS does assumes that the initial handshake and key negotiation is handled by >> OpenSSL. OpenSSL uses custom setockopt() calls to tell the kernel which >> session keys to use. > Yea, I figured I'd need a daemon like the gssd for this. The krpc makes it a little > more fun, since it handles TCP connections in the kernel. > >> I think what you would want to do is use something like OpenSSL_connect() in >> userspace, and then check to see if KTLS "worked". > Thanks (and for the code below). I found the simple server code in the OpenSSL doc, > but the client code gets a web page and is quite involved. > >> If it did, you can tell >> the kernel it can write to the socket directly, otherwise you will have to >> bounce data back out to userspace to run it through SSL_write() and have >> userspace do SSL_read() and then feed data into the kernel. > I don't think bouncing the data up/down to/from userland would work well. > I'd say "if it can't be done in the kernel, too bad". The above could be used for > a NULL RPC to see it is working, for the client. > >> The pseudo-code might look something like: >> >> SSL *s; >> >> s = SSL_new(...); >> >> /* fd is the existing TCP socket */ >> SSL_set_fd(s, fd); >> OpenSSL_connect(s); >> if (BIO_get_ktls_send(SSL_get_wbio(s)) { >> /* Can use KTLS for transmit. */ >> } >> if (BIO_get_ktls_recv(SSL_get_rbio(s)) { >> /* Can use KTLS for receive. */ >> } > Thanks John, rick > > > -- > 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" > From owner-freebsd-current@freebsd.org Tue Jan 28 03:53:07 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1153923A0E3; Tue, 28 Jan 2020 03:53:07 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 486CPs6TM1z4cjY; Tue, 28 Jan 2020 03:53:05 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id 00S3rIqY012683 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 27 Jan 2020 19:53:19 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id 00S3rHDQ012682; Mon, 27 Jan 2020 19:53:17 -0800 (PST) (envelope-from fbsd) Date: Mon, 27 Jan 2020 19:53:17 -0800 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org, freebsd-current@freebsd.org, bob prohaska Subject: Re: OOMA kill with vm.pfault_oom_attempts="-1" on RPi3 at r357147 Message-ID: <20200128035317.GA12644@www.zefox.net> References: <20200127190709.GA11328@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Rspamd-Queue-Id: 486CPs6TM1z4cjY X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net X-Spamd-Result: default: False [3.49 / 15.00]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; IP_SCORE(0.06)[ip: (0.27), ipnet: 50.1.16.0/20(0.13), asn: 7065(-0.04), country: US(-0.05)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.56)[0.559,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.97)[0.967,0]; R_SPF_NA(0.00)[]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; MID_RHS_WWW(0.50)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 28 Jan 2020 03:53:07 -0000 On Mon, Jan 27, 2020 at 06:22:20PM -0800, Mark Millard wrote: > > So far as I know, in the past progress was only made when someone > already knowledgable got involved in isolating what was happening > and how to control it. > Indeed. One can only hope said knowledgeables are reading.... Thanks for reading! bob prohaska From owner-freebsd-current@freebsd.org Tue Jan 28 05:30:01 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DA43823C48F for ; Tue, 28 Jan 2020 05:30:01 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-22.consmr.mail.gq1.yahoo.com (sonic309-22.consmr.mail.gq1.yahoo.com [98.137.65.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 486FYh2B6xz4hXf for ; Tue, 28 Jan 2020 05:30:00 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: HgzgAewVM1m_dMFeIInC42Gy1tZK7tXOWysSCh3.ZvgqZ1_RLiIWLmb7_lPD4SG 3IXrbEJrtFv41l.AmLsDyVe8ypz3cAdVNSdAc8hfAHE9Hk6mr8B2Sjy9lzLRRcCkgXSCHmCj.3kX b75rOrVvzi5DuQ1D_kDaamnA7fQhUN4sCD8XjFLEx8dEtiuBgaULExT4o2AKn92Oi1M6gCxvpRAM qEAgO694do2_lgddzQ0LRbBtC95IbwOmFFjz5FrDaaZBZkuStsqmWfp2BLr5J8kT24lsquUARdI4 uZp0hBHK8QOzH5cMWevkklg5lGnU97gYYbbCur.3rdW7wAYdSN4SGNN_aAazLwMb0wrIIpy1fMoL _wZokjK67U3NrE8DveEPJ21bsGHMahuPpBIbtfqjAGOV4_xigua5NQkJdyklrGSsOUlUDkKK2T9Q Ucrpxs5s23K9S_p1UA0qTYYdkAV14HBm6NturjN_ipWMoZRbMpXRBgdZU7Ioq6A2U_kusUQCKpS_ 5NyglfiXZjGOlYVp4cb6Ll2o0QrMJxBAne_sVzcmyDhuT272McafA.MSKFm21j8S4SofxiUCnssw zcVvJZo4WCNlYpiN.NHCj6z2ejZdhswJp6ewjbFZsq_4n_uFkS8co9XRgEAWQK94pdFwxsWDlAaO xiLt.8Ew.8oa5yFQMtoWL6c3ZiXvsw6o7eADOi4mbJiZps6n5bawB21mAjiWUdthUQ7q1WqGt.IF YLblYuIf_Ux0WHnfzOkQRtwW3e6V8I5iFyIheLCaKTQyY.38UDft6EICDH7tpsr.XK5m9kKdAOBH s4X6u5JLF5KjPsgbDvzC4wPxpZkbnGfwJy0tsT..xha9ZyON3t_PRMNAUoQ8afnT_dkY3LN4Ihfj _5qWZdnH0zkg.WZv5cooKYC73Mx..H_ascV94c4Em0kcdhoWHkKHndc0TBNAXSfLFIADrjCiqmxl aASqwbN6v2.eFnMqXtKipXLlt6kjtYVMjhjFLzm6wlQNl7KK0RhyKF_cBE78gLk_.cf1.CB01syn Vqng8jp_kgfM3YQqpFvANmfm6H9Pe9qa4DCY4g7mdex65oSHIIB21mE7w8W7X_MRXP4d5G65Qgws _x6wgzicSrg7gSP3f0XRUU_u7DHJzBlY71vBlrKOs3nQKHT0SnorNwuPNv24_cNddR.5Uf5v7260 P3JBE7bRfCRIPYPL2U8RjZMybMqIneEYboes85Gyq8C9UYVvVMLXUyz8zVQcoMpYDyXrpmEgc.5B B8ueyfE0RrwnKhJic9GCCJivt_Q22TWLzzzXWIBpDbGKHveNfvAKhEHGddGIvt0feMGL18gfgi6E jWbL7gyNoNj5rU_ie7ZOtty3RkbtesA.Voooc5EUu2s7yIDM1I.vQUOTlQqyt0COwcEMYplJvR4V Pc.HODwOo687E5AR2maM.VeHlmGLcb0zz6A-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Tue, 28 Jan 2020 05:29:58 +0000 Received: by smtp426.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 9b21b4bcea3a4224488b3b33387beaea; Tue, 28 Jan 2020 05:29:54 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Subject: Re: OOMA kill with vm.pfault_oom_attempts="-1" on RPi3 at r357147 From: Mark Millard In-Reply-To: <20200128035317.GA12644@www.zefox.net> Date: Mon, 27 Jan 2020 21:29:52 -0800 Cc: freebsd-arm@freebsd.org, freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <18150258-6210-451E-A5B9-528129A05974@yahoo.com> References: <20200127190709.GA11328@www.zefox.net> <20200128035317.GA12644@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3608.40.2.2.4) X-Rspamd-Queue-Id: 486FYh2B6xz4hXf X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.50 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_GOOD(-0.10)[text/plain]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_DN_SOME(0.00)[]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[148.65.137.98.list.dnswl.org : 127.0.5.0]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.00)[ip: (-2.15), ipnet: 98.137.64.0/21(0.84), asn: 36647(0.67), country: US(-0.05)]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 28 Jan 2020 05:30:01 -0000 On 2020-Jan-27, at 19:53, bob prohaska wrote: > On Mon, Jan 27, 2020 at 06:22:20PM -0800, Mark Millard wrote: >>=20 >> So far as I know, in the past progress was only made when someone >> already knowledgable got involved in isolating what was happening >> and how to control it. >>=20 > Indeed. One can only hope said knowledgeables are reading.... May be I can suggest something that might kick-start evidence gathering a little bit: add 4 unconditional printf's to the kernel code, each just before one of the vm_pageout_oom(. . .) calls. Have the message uniquely identify which of the 4 it is before. The details of what I found that suggested this follows. I found: #define VM_OOM_MEM 1 #define VM_OOM_MEM_PF 2 #define VM_OOM_SWAPZ 3 In vm_fault(. . .) : . . . if (vm_pfault_oom_attempts < 0 || oom < vm_pfault_oom_attempts) { oom++; vm_waitpfault(dset, vm_pfault_oom_wait * hz); goto RetryFault_oom; } if (bootverbose) printf( "proc %d (%s) failed to alloc page on fault, starting OOM\n", curproc->p_pid, = curproc->p_comm); vm_pageout_oom(VM_OOM_MEM_PF); . . . (I'd not have guessed that bootverbose would control messages about OOM activity.) The above one looks to be blocked by the "-1" setting that we have been using. In vm_pageout_mightbe_oom(. . .) : . . . if (starting_page_shortage <=3D 0 || starting_page_shortage !=3D page_shortage) vmd->vmd_oom_seq =3D 0; else vmd->vmd_oom_seq++; if (vmd->vmd_oom_seq < vm_pageout_oom_seq) { if (vmd->vmd_oom) { vmd->vmd_oom =3D FALSE; atomic_subtract_int(&vm_pageout_oom_vote, 1); } return; } =20 /* * Do not follow the call sequence until OOM condition is * cleared. */ vmd->vmd_oom_seq =3D 0; =20 if (vmd->vmd_oom) return; =20 vmd->vmd_oom =3D TRUE; old_vote =3D atomic_fetchadd_int(&vm_pageout_oom_vote, 1); if (old_vote !=3D vm_ndomains - 1) return; =20 /* * The current pagedaemon thread is the last in the quorum to * start OOM. Initiate the selection and signaling of the * victim. */ vm_pageout_oom(VM_OOM_MEM); =20 /* * After one round of OOM terror, recall our vote. On the * next pass, current pagedaemon would vote again if the low * memory condition is still there, due to vmd_oom being * false. */ vmd->vmd_oom =3D FALSE; atomic_subtract_int(&vm_pageout_oom_vote, 1); . . . The above is where the other setting we have been using extends the number of tries before doing the OOM kill. If the rate of attempts increased, less time would go by for the same figure? This case might still be happening, even for the > 4000 figure used on the 5 GiByte amd64 system with the i386 jail that was reported? No specific printf above as things are. In swp_pager_meta_build(. . .) : . . . if (uma_zone_exhausted(swblk_zone)) { if = (atomic_cmpset_int(&swblk_zone_exhausted, 0, 1)) printf("swap blk zone exhausted, = " "increase = kern.maxswzone\n"); vm_pageout_oom(VM_OOM_SWAPZ); pause("swzonxb", 10); } else uma_zwait(swblk_zone); . . . if (uma_zone_exhausted(swpctrie_zone)) { if = (atomic_cmpset_int(&swpctrie_zone_exhausted, 0, 1)) printf("swap pctrie zone = exhausted, " "increase = kern.maxswzone\n"); vm_pageout_oom(VM_OOM_SWAPZ); pause("swzonxp", 10); } else uma_zwait(swpctrie_zone); . . . The above we have not been controlling: uma zone exhaustion for swblk_zone and swpctrie_zone. (Not that I'm familiar with them or the rest of this material.) On a small memory machine, there may be nothing that can be directly done that does not have other, nasty tradeoffs. Of course, there might be reasons that one or both of these exhaust faster then they used to. There are the 2 printf messages, but they are conditional. Still, they give something else to look for in console or log output. One possibility is always having an unconditional printf just before each of the 4 vm_pageout_oom calls, each of which identifies which of the 4 contexts is making the call. That would at least be a start at figuring things out. (swp_pager_meta_build's code means that the argument to vm_pageout_oom is not as specific for such identification.) The vm_pageout_oom(. . .) routine has: . . . if (bigproc !=3D NULL) { if (vm_panic_on_oom !=3D 0) panic("out of swap space"); PROC_LOCK(bigproc); killproc(bigproc, "out of swap space"); sched_nice(bigproc, PRIO_MIN); _PRELE(bigproc); PROC_UNLOCK(bigproc); } . . . That is where the can-be-a-misnomer "out of swap space" is from. Looks like it is correct for some conditions, but not the conditions we have historically got for our contexts. It takes looking at other messages to figure out if it is a misnomer: Another type of message carries the actual out-of-swap information and if that message is not present then the one based on the above is a misnomer. vm_pageout_oom could use its argument to be somewhat more specific for the text it passes to killproc(. . .). For reference: # grep -r "VM_OOM_" /usr/src/sys/ | more /usr/src/sys/vm/vm_fault.c: = vm_pageout_oom(VM_OOM_MEM_PF); /usr/src/sys/vm/vm_pageout.c: vm_pageout_oom(VM_OOM_MEM); /usr/src/sys/vm/vm_pageout.c: if (shortage =3D=3D VM_OOM_MEM_PF && /usr/src/sys/vm/vm_pageout.c: if (shortage =3D=3D = VM_OOM_MEM || shortage =3D=3D VM_OOM_MEM_PF) /usr/src/sys/vm/swap_pager.c: = vm_pageout_oom(VM_OOM_SWAPZ); /usr/src/sys/vm/swap_pager.c: = vm_pageout_oom(VM_OOM_SWAPZ); /usr/src/sys/vm/vm_pageout.h:#define VM_OOM_MEM 1 /usr/src/sys/vm/vm_pageout.h:#define VM_OOM_MEM_PF 2 /usr/src/sys/vm/vm_pageout.h:#define VM_OOM_SWAPZ 3 =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 Jan 28 08:49:48 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8404C1F9EDA for ; Tue, 28 Jan 2020 08:49:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-23.consmr.mail.gq1.yahoo.com (sonic303-23.consmr.mail.gq1.yahoo.com [98.137.64.204]) (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 486L0C1MH1z4rvX for ; Tue, 28 Jan 2020 08:49:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: LtQoIUsVM1npwviTre99yxqBH2Hoez9avEXZrZ4UTpr7d8kqGVXND2seg9ck.ue RhlJ8rtTB4RexAhsTTJp8ads6LieO2xWdDT9WO3N9d3BGLlWvC0lFNrEA5brXnvOSy6bjMgOmLM4 UJxN5AiH6os6f2HF.paKzo4nnvQuAJbZaPl1RsRLuURkoChsObc8uXsAAOWlS2iuQ30L2_zpLME. 2lLud.SPL4y41HzJuMu15zDRQLPY_FkbP86l6iaulvPZbVPAFbRU_jEbCZA_Y4tjn7DZMRWwFL9O o2gxr4qIy7f2TzBbM_87Cfb7vHfto1ckgeAnpz2NopgF9X14n3zgLnPEWKaOvU7pb9God_njbkPD 2KSoM4dq6wPRfWmjwFKu9BRM40rJ.oss0_wAwxClhkqBteDY9npcERG2MqX4tpMdLx5AGNzferOf hn.WAhwVjOEE9vq4Fz18nfoR.2h4aKNvWkxh1HBRQ9O_.MSU4xXVeGAqp0nhTBi3cCoP72VztON5 bIZpw0rkZpGPp3HOV138Q7PwS8ApP3gkQ3wgeJnVSuHigYNNDpQOnobzz4FEJAC3EYDdg4w.bxjI aOIvOz1QbK_LO8TLqkT459imluNPMyuaI3iyIzDJ3RfSKgNPVpy6iREA3K8j4QiiGVWSIlke4R0m K9iS5zJ9PMz1PrZlA2JTpQRHmLE8Ab3f._IXI3EXOOLL5Dejn6Qd21mXRLRywYlxiE.BBjxT4EHo SihS6Xgk6rZZ6OGAgycVVcheTqClfGf4o6p__Pg5binrmyo5lgc1aZR1UxaoMC..ct06IphqvIFK F80tF49iKgitrwO3wky7RLWO6ykpIefaGf7jl3HmL51jP84EUzpJ.WBk9No.gasqPlNCELHlaAMo DPtmz8MRKUklKNOunNU8e7eSCOfvm6fRCSwlbH1rBfPS46kuAO5WTqaiAlumZjsZkG_.k46Lhtbt .zWphv5oieTvwFwK.860JAteHmDVTxOpLeQ34haNbGoGJDvJPXJl5dYVjsqVuda684CsWTJXCbxr T57POjPbM0itFS3XRkAIHOmBx1jxO2_bwkLkSq9BrgJCgM11q9kmhzB4qACu.56inWxcb43w7z5P wU07iWekcNcbpiPL92h9xvRNrO7Ibb6iIP9j7KdofeE8KFMW1EIm1cwHM7KUujhoyyCUUkGBCw7u ZAzYeHXGUe_Bp3urwy0gQJ.QdoGBSkvQ0YgD6XMxDzmT.LujMPqOC3_1jLkYYoV4yrf3KMEuf3Fi pkbIoFo8vum6EK6SWRKUl7fTsvg.nuFg48CWn_KGf9VRsYBjt_Zw58KmAP0mNnj0.qf3su58GM1Q VfrDEAGNkQBBdbExSXHrULNsmnElni2HuecRXFOts9WnkbMWkxPQqUARpWrJW2286wO5raLLpaSK FU4N5jm1K.tHkMjg2aAYzC3SnGwzIuDnCkNkdp6w- Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Tue, 28 Jan 2020 08:49:45 +0000 Received: by smtp414.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 55dfa43afc642adea1c2113df8510244; Tue, 28 Jan 2020 08:49:42 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Subject: Re: OOMA kill with vm.pfault_oom_attempts="-1" on RPi3 at r357147 From: Mark Millard In-Reply-To: <18150258-6210-451E-A5B9-528129A05974@yahoo.com> Date: Tue, 28 Jan 2020 00:49:41 -0800 Cc: freebsd-arm@freebsd.org, freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <9BF68EF1-F83A-473B-9A7B-B3956D6A5EFD@yahoo.com> References: <20200127190709.GA11328@www.zefox.net> <20200128035317.GA12644@www.zefox.net> <18150258-6210-451E-A5B9-528129A05974@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3608.40.2.2.4) X-Rspamd-Queue-Id: 486L0C1MH1z4rvX X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.39 / 15.00]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.95)[-0.948,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-0.94)[-0.939,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (0.42), ipnet: 98.137.64.0/21(0.84), asn: 36647(0.67), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[204.64.137.98.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[204.64.137.98.rep.mailspike.net : 127.0.0.17]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 28 Jan 2020 08:49:48 -0000 On 2020-Jan-27, at 21:29, Mark Millard wrote: > On 2020-Jan-27, at 19:53, bob prohaska wrote: >=20 >> On Mon, Jan 27, 2020 at 06:22:20PM -0800, Mark Millard wrote: >>>=20 >>> So far as I know, in the past progress was only made when someone >>> already knowledgable got involved in isolating what was happening >>> and how to control it. >>>=20 >> Indeed. One can only hope said knowledgeables are reading.... >=20 > May be I can suggest something that might kick-start > evidence gathering a little bit: add 4 unconditional > printf's to the kernel code, each just before one of > the vm_pageout_oom(. . .) calls. Have the message > uniquely identify which of the 4 it is before. >=20 > . . . Below is a stab at implementing the suggestion. A couple of the printf's are basically what Mark Johnston supplied long ago. (Other code from what he supplied back then did not survive updates made to FreeBSD.) One of his printf's is not tied to indicating vm_pageout_oom use. (Sent this way some whitespace might not be preserved.) # svnlite diff /usr/src/sys/vm/=20 Index: /usr/src/sys/vm/swap_pager.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/vm/swap_pager.c (revision 356426) +++ /usr/src/sys/vm/swap_pager.c (working copy) @@ -2021,6 +2021,7 @@ 0, 1)) printf("swap blk zone exhausted, = " "increase = kern.maxswzone\n"); + printf("swp_pager_meta_build: swap blk = uma zone exhausted\n"); vm_pageout_oom(VM_OOM_SWAPZ); pause("swzonxb", 10); } else @@ -2051,6 +2052,7 @@ 0, 1)) printf("swap pctrie zone = exhausted, " "increase = kern.maxswzone\n"); + printf("swp_pager_meta_build: swap = pctrie uma zone exhausted\n"); vm_pageout_oom(VM_OOM_SWAPZ); pause("swzonxp", 10); } else Index: /usr/src/sys/vm/vm_fault.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/vm/vm_fault.c (revision 356426) +++ /usr/src/sys/vm/vm_fault.c (working copy) @@ -943,9 +943,9 @@ vm_pfault_oom_wait * hz); goto RetryFault_oom; } - if (bootverbose) + // HAVE PRINTF BE UNCONDITIONAL FOR = TESTING: if (bootverbose) printf( - "proc %d (%s) failed to alloc page on fault, starting OOM\n", + "vm_fault: proc %d (%s) failed to alloc page on fault, starting = OOM\n", curproc->p_pid, = curproc->p_comm); vm_pageout_oom(VM_OOM_MEM_PF); goto RetryFault; Index: /usr/src/sys/vm/vm_page.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/vm/vm_page.c (revision 356426) +++ /usr/src/sys/vm/vm_page.c (working copy) @@ -3139,6 +3139,7 @@ * race-free vm_wait_domain(). */ if (curproc =3D=3D pageproc) { + printf("thread %d waiting for memory\n", = curthread->td_tid); mtx_lock(&vm_domainset_lock); vm_pageproc_waiters++; msleep(&vm_pageproc_waiters, &vm_domainset_lock, PVM | = PDROP, Index: /usr/src/sys/vm/vm_pageout.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/vm/vm_pageout.c (revision 356426) +++ /usr/src/sys/vm/vm_pageout.c (working copy) @@ -1741,6 +1741,8 @@ * start OOM. Initiate the selection and signaling of the * victim. */ + printf("vm_pageout_mightbe_oom: kill context: v_free_count: %u, = v_inactive_count: %u\n", + vmd->vmd_free_count, = vmd->vmd_pagequeues[PQ_INACTIVE].pq_cnt); vm_pageout_oom(VM_OOM_MEM); =20 /* @@ -1933,10 +1935,24 @@ } sx_sunlock(&allproc_lock); if (bigproc !=3D NULL) { + char *reason_text; + switch (shortage) { + case VM_OOM_MEM_PF: + reason_text=3D "fault's page allocation failed"; + break; + case VM_OOM_MEM: + reason_text=3D "free RAM stayed below = threshold"; + break; + case VM_OOM_SWAPZ: + reason_text=3D "swblk or swpctrie zone = exhausted"; + break; + default: + reason_text=3D "Unknown Reason"; + } if (vm_panic_on_oom !=3D 0) - panic("out of swap space"); + panic("%s",reason_text); PROC_LOCK(bigproc); - killproc(bigproc, "out of swap space"); + killproc(bigproc, reason_text); sched_nice(bigproc, PRIO_MIN); _PRELE(bigproc); PROC_UNLOCK(bigproc); =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 Jan 28 10:10:32 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id CFDCC1FCBE9 for ; Tue, 28 Jan 2020 10:10:32 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 486MnM567bz3CgQ for ; Tue, 28 Jan 2020 10:10:31 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2020.home.selasky.org (unknown [62.141.129.235]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 572A7260165 for ; Tue, 28 Jan 2020 11:10:23 +0100 (CET) To: FreeBSD Current From: Hans Petter Selasky Subject: [HEADS UP] EPOCH breakage in [USB/PCI] network drivers after r357004 Message-ID: Date: Tue, 28 Jan 2020 11:10:01 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 486MnM567bz3CgQ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-4.97 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[selasky.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE(-2.67)[ip: (-9.22), ipnet: 2a01:4f8::/29(-2.53), asn: 24940(-1.56), country: DE(-0.02)]; TO_DN_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 28 Jan 2020 10:10:32 -0000 Hi, Currently 8 of 10 USB WLAN drivers are broken and multiple PCI ones too. I have some patches, which I would like to have more attention that try to address these issues. The patches are currently being worked on. 1) https://reviews.freebsd.org/D23348 2) https://reviews.freebsd.org/D23347 If you have some comments please sign up! I hope all issues will be addressed by end of week. --HPS From owner-freebsd-current@freebsd.org Tue Jan 28 11:36:31 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 41CD722807C for ; Tue, 28 Jan 2020 11:36:31 +0000 (UTC) (envelope-from nick@van-laarhoven.org) Received: from violet.van-laarhoven.org (violet.van-laarhoven.org [IPv6:2a01:4f8:1c0c:72ba::3]) by mx1.freebsd.org (Postfix) with ESMTP id 486PhZ0XvFz3Jy6 for ; Tue, 28 Jan 2020 11:36:26 +0000 (UTC) (envelope-from nick@van-laarhoven.org) Received: from hille.fritz.box (217-19-28-102.dsl.cambrium.nl [217.19.28.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by violet.van-laarhoven.org (Postfix) with ESMTPSA id A23F49CC5A for ; Tue, 28 Jan 2020 12:36:19 +0100 (CET) From: Nick Hibma Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Subject: btxld not found Message-Id: <8B42F93A-7B9E-4F99-9D77-43DA3BB7F045@van-laarhoven.org> Date: Tue, 28 Jan 2020 12:36:18 +0100 To: FreeBSD Current Mailing List X-Mailer: Apple Mail (2.3608.40.2.2.4) X-Rspamd-Queue-Id: 486PhZ0XvFz3Jy6 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of nick@van-laarhoven.org designates 2a01:4f8:1c0c:72ba::3 as permitted sender) smtp.mailfrom=nick@van-laarhoven.org X-Spamd-Result: default: False [-2.52 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[van-laarhoven.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE(-0.82)[ipnet: 2a01:4f8::/29(-2.53), asn: 24940(-1.56), country: DE(-0.02)]; TO_DN_ALL(0.00)[]; MV_CASE(0.50)[]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 28 Jan 2020 11:36:31 -0000 Folks, Could anyone explain to me what I am doing wrong? make installworld = fails each time with the following error =3D=3D=3D> stand/i386/libi386 (install) =3D=3D=3D> stand/i386/loader_4th (install) strip -R .comment -R .note -o loader_4th.bin loader_4th.sym btxld -v -f aout -e 0x200000 -o loader_4th -l = /usr/obj/usr/src/i386.i386/stand/i386/btx/btxldr/btxldr -b = /usr/obj/usr/src/i386.i386/stand/i386/btx/btx/btx loader_4th.bin make[6]: exec(btxld) failed (No such file or directory) *** Error code 1 This is with source of last week. I had this problem before (from old = sources) and fixed it by specifying the full path to btxld in the = stand/i386/*/Makefile.=20 Any pointers? Nick Hibma nick@van-laarhoven.org -- Open Source: We stand on the shoulders of giants. From owner-freebsd-current@freebsd.org Tue Jan 28 11:39:13 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DB77422828E for ; Tue, 28 Jan 2020 11:39:13 +0000 (UTC) (envelope-from tsoome@me.com) Received: from pv50p00im-ztdg10021201.me.com (pv50p00im-ztdg10021201.me.com [17.58.6.45]) (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 486Plj1RD6z3K9M for ; Tue, 28 Jan 2020 11:39:13 +0000 (UTC) (envelope-from tsoome@me.com) Received: from [192.168.150.41] (148-52-235-80.sta.estpak.ee [80.235.52.148]) by pv50p00im-ztdg10021201.me.com (Postfix) with ESMTPSA id 91705A4031F; Tue, 28 Jan 2020 11:39:10 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Subject: Re: btxld not found From: Toomas Soome In-Reply-To: <8B42F93A-7B9E-4F99-9D77-43DA3BB7F045@van-laarhoven.org> Date: Tue, 28 Jan 2020 13:39:08 +0200 Cc: FreeBSD Current Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: References: <8B42F93A-7B9E-4F99-9D77-43DA3BB7F045@van-laarhoven.org> To: Nick Hibma X-Mailer: Apple Mail (2.3608.40.2.2.4) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-01-28_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 mlxscore=0 mlxlogscore=690 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-2001280095 X-Rspamd-Queue-Id: 486Plj1RD6z3K9M X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.60 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:17.58.0.0/16]; FREEMAIL_FROM(0.00)[me.com]; MV_CASE(0.50)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[me.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[me.com,quarantine]; RECEIVED_SPAMHAUS_PBL(0.00)[148.52.235.80.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; RCVD_IN_DNSWL_LOW(-0.10)[45.6.58.17.list.dnswl.org : 127.0.5.1]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:714, ipnet:17.58.0.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[me.com]; R_DKIM_ALLOW(-0.20)[me.com:s=1a1hai]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (-3.75), ipnet: 17.58.0.0/20(-1.94), asn: 714(-2.27), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; DWL_DNSWL_LOW(-1.00)[me.com.dwl.dnswl.org : 127.0.5.1]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 28 Jan 2020 11:39:13 -0000 > On 28. Jan 2020, at 13:36, Nick Hibma wrote: >=20 > Folks, >=20 > Could anyone explain to me what I am doing wrong? make installworld = fails each time with the following error >=20 > =3D=3D=3D> stand/i386/libi386 (install) > =3D=3D=3D> stand/i386/loader_4th (install) > strip -R .comment -R .note -o loader_4th.bin loader_4th.sym > btxld -v -f aout -e 0x200000 -o loader_4th -l = /usr/obj/usr/src/i386.i386/stand/i386/btx/btxldr/btxldr -b = /usr/obj/usr/src/i386.i386/stand/i386/btx/btx/btx loader_4th.bin > make[6]: exec(btxld) failed (No such file or directory) > *** Error code 1 >=20 > This is with source of last week. I had this problem before (from old = sources) and fixed it by specifying the full path to btxld in the = stand/i386/*/Makefile.=20 >=20 > Any pointers? >=20 it should be /usr/sbin/btxld; are you missing /usr/sbin from the path? rgds, toomas From owner-freebsd-current@freebsd.org Tue Jan 28 11:45:26 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 29894228645 for ; Tue, 28 Jan 2020 11:45:26 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [IPv6:2001:678:618::40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "plan-b.pwste.edu.pl", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 486Ptr3fVDz3KcH for ; Tue, 28 Jan 2020 11:45:24 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from bsdondell.lab.pwste.edu.pl ([IPv6:2001:678:618:3067:a0ed:ada9:e145:988d]) (authenticated bits=0) by plan-b.pwste.edu.pl (8.15.2/8.15.2) with ESMTPSA id 00SBjFI8027768 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 28 Jan 2020 12:45:15 +0100 (CET) (envelope-from zarychtam@plan-b.pwste.edu.pl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plan-b.pwste.edu.pl; s=plan-b-mailer; t=1580211915; bh=8bMhieaYdkkiLjrIQ9VkvdOERTc7okrrkLo7W0Y0QAA=; h=To:References:From:Subject:Date:In-Reply-To; b=c+yusl1AF+PKnG40NUn14MRj1pArahZhZuH4IPeVb5C7cAQKcofZiHxXsfsCV+zQe 4mKt/CpU2+SbOJSjADeRr3Rw0YtDmta7NLLcpO3nTDKwYIopwYVUswjC9zaMo+Waao 8Tn5ITIG2Ef9RheNQFWDDgXn306mpkQCS8MXMcI/k0y3LvRe13D53n3eaRDW8PxVjc VHPRkUc0SF9Oy4sCLtIFktrPBBWx7M3mj50NE1F7a0mxJHTFlwiEUtq2SchImFFzw5 0dZpqcOgyVdamq1dXH/grJV5aqc9EOyVqZ9KXnes1MtdOaB/8ZH8ByXTfM0J27WIgR tcOXuhrf+bYaw== X-Authentication-Warning: plan-b.pwste.edu.pl: Host [IPv6:2001:678:618:3067:a0ed:ada9:e145:988d] claimed to be bsdondell.lab.pwste.edu.pl To: freebsd-current@freebsd.org References: <8B42F93A-7B9E-4F99-9D77-43DA3BB7F045@van-laarhoven.org> From: Marek Zarychta Autocrypt: addr=zarychtam@plan-b.pwste.edu.pl; keydata= mQENBFfi3cMBCADLecMTFXad4uDXqv3eRuB4qJJ8G9tzzFezeRnnwxOsPdytW5ES2z1ibSrR IsiImx6+PTqrAmXpTInxAi7yiZGdSiONRI4CCxKY9d1YFiNYT/2WyNXCekm9x29YeIU7x0JB Llbz0f/9HC+styBIu2H+PY/X98Clzm110CS+n/b9l1AtiGxTiVFj7/uavYAKxH6LNWnbkuc5 v8EVNc7NkEcl5h7Z9X5NEtzDxTOiBIFQ/kOT7LAtkYUPo1lqLeOM2DtWSXTXQgXl0zJI4iP1 OAu4qQYm2nXwq4b2AH9peknelvnt1mpfgDCGSKnhc26q6ibTfMwydp+tvUtQIQYpA6b9ABEB AAG0N01hcmVrIFphcnljaHRhIChQbGFuLWIpIDx6YXJ5Y2h0YW1AcGxhbi1iLnB3c3RlLmVk dS5wbD6JATcEEwEIACEFAlfi4LkCGwMFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQHZW8 vIFppoJXdgf8D9X3VRFSNaR9lthSx/+uqas17J3FJKBo1xMQsC2a+44vzNvYJSuPGLLJ+LW2 HPVazjP/BWZJbxOYpliY4zxNRU0YCp0BLIVLibc//yax+mE42FND/+NiIZhqJscl6MLPrSwo sIwXec4XYkldkyqW/xBbBYXoIkBqdKB9j5j42Npy1IV/RizOSdmvTWY27ir8e/yGMR1RLr4F 8P5K3OWTdlGy2H2F/3J8bIPBLG6FpaIyLQw4dHSx8V02PYqDxK1cNo2kAOnU8PnZL/AGuMOH iv3MN1VYL8ehcmpBBsrZGebQJxrjY2/5IaTSgp9xHYT70kshuU6Qb97vk1mOjNZxgbkBDQRX 4t3DAQgA10h6RCXuBLMHxq5B8X/ZIlj9sgLoeyfRdDZEc9rT2KUeUJVHDsbvOFf4/7F1ovWY hJbA6GK/LUZeHHTjnbZcH1uDYQeHly4UOLxeEvhGoz4JhS2C7JzN/uRnwbdOAUbJr8rUj/IY a7gk906rktsc/Ldrxrxh7O6WO0JCh2XO/p4pDfEwwB37g4xHprSab28ECYJ9JMbtA8Sy4M55 g3+GQ28FvSlGnx48OoGXU2BZdc1vZKSQmNOlikB+9/hDX8zdYWVfDaX1TLQ8Ib4+xTUmapza mV/bxIsaZRBw+jFjLQHhTbIMfPEU+4mxFDvTdbKPruKPqVf1ydgMnPZWngowdwARAQABiQEf BBgBCAAJBQJX4t3DAhsMAAoJEB2VvLyBaaaC6qkIAJs9sDPqrqW0bYoRfzY6XjDWQ59p9tJi v8aogxacQNCfAu+WkJ8PNVUtC1dlVcG5NnZ80gXzd1rc8ueIvXlvdanUt/jZd8jbb3gaDbK3 wh1yMCGBl/1fOJTyEGYv1CRojv97KK89KP5+r8x1P1iHcSrunlDNqGxTMydNCwBH23QcOM+m u4spKnJ/s0VRBkw3xoKBZfZza6fTQ4gTpAipjyk7ldOGBV+PvkKATdhK2yLwuWXhKbg/GRlD 1r5P0gxzSqfV4My+KJuc2EDcrqp1y0wOpE1m9iZqCcd0fup5f7HDsYlLWshr7NQl28f6+fQb sylq/j672BHXsdeqf/Ip9V65AQ0EV+OTdwEIAMxnGg7OO/ZAnSwiIiABA9lil1Lfa5BWTH3c l1rz4slz7Gw99G9J3bX3FiPA0vU89dgBZ2k0/UVk5cI5EsMAvwJN4bPwRsfBELQqjCKkVZr4 vUeGyvgQ2jnoK1fcEFOnCRdwFy4EJ6Y/fsZCTj4IfQpkM1W7C3KuSGPcjPDA9XCLDjjp8bbA Q9VgQ68MntAnYxMqK0S3CrHp5Pruvb0x4MfFLNwaKtWK+UnJGPT4umj8PMP6XLsFC3g+SGoP aWoYRDI297ZGx4IBWEaJq181oEC5iUQ6WREti9fNQ3TsAB3Q2CjNlkx1geSczIFJSyOHmyJZ RqAocw1sIuPopvhWtR0AEQEAAYkCRAQYAQgADwUCV+OTdwIbAgUJCWYBgAEpCRAdlby8gWmm gsBdIAQZAQgABgUCV+OTdwAKCRB1n+z//VKNLOETCAC3ggwAAQij4hkIxQFapnRuIVb5vq7D AwJ9+Ld5/zYHOj2Tfu+BPSNGzI2edqboz2w1t55UHEYzYDp2axxIfPrZrXsBV4DsjtGwzVV/ jZ9or5qTaYFDEStRkzL4mRpTyYhl/T7GgWpwOJWOih+cU7RWzjSOxiYMi4QSYlkpDUCcZew0 C3HfcxeFqpeL46zgysHC2ptjINXQ+xR2/F6dbed+l7OsvJAfkBqJoQ/48m+8ly1lbViKck7q gWw143ljaKn2qGIjZdb95zcI/CP4L45SXq8NOweACdx2NfUphLrIMbNCqLkMUJcrnruKfbnp C8OMjFJIqlu+PsW593NcZyOugEAH/0cBsDxlSauSVK4kp8ald26pcBI6igNnIMgjaxMiZBjn eoxBiKAOAO93sPnPr9/64CMMwv1T+0vU2lj8SMKOdHVrB9sW/ICGji5skE85xPEAtUkdAQN+ +c2clotujcaj9lBZKJdncKmSxY0SshEa66H+s76u+2Q3jGK6vOrdxakWYCvh2P0/l52Nd/t2 eazLFgwtk5rbo7O0MSC1GNXUsG07vtZ+zxJXFRx7PQ3ZIn0Y4HqwvXUvqgZ9EHiKy8F+ondz 9IS8/Fs81N5ieujHhSWqbaibapnpeDHvT/FWf8iXfJqWq+F7C8lGShSkmsS5AOhB4TNNH5/m ZzECJa1ql64= Subject: Re: btxld not found Message-ID: Date: Tue, 28 Jan 2020 12:45:00 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1 MIME-Version: 1.0 In-Reply-To: <8B42F93A-7B9E-4F99-9D77-43DA3BB7F045@van-laarhoven.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="yny7B53hgwgwltjVbiEVZ9XaOFxfxpZIR" X-Rspamd-Queue-Id: 486Ptr3fVDz3KcH X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=plan-b.pwste.edu.pl header.s=plan-b-mailer header.b=c+yusl1A; dmarc=pass (policy=none) header.from=pwste.edu.pl; spf=none (mx1.freebsd.org: domain of zarychtam@plan-b.pwste.edu.pl has no SPF policy when checking 2001:678:618::40) smtp.mailfrom=zarychtam@plan-b.pwste.edu.pl X-Spamd-Result: default: False [-4.47 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[plan-b.pwste.edu.pl:s=plan-b-mailer]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[pwste.edu.pl.dwl.dnswl.org : 127.0.11.0]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; HAS_ATTACHMENT(0.00)[]; HAS_XAW(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[plan-b.pwste.edu.pl:+]; DMARC_POLICY_ALLOW(-0.50)[pwste.edu.pl,none]; R_SPF_NA(0.00)[]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; IP_SCORE(0.43)[asn: 206006(2.08), country: PL(0.07)]; ASN(0.00)[asn:206006, ipnet:2001:678:618::/48, country:PL]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 28 Jan 2020 11:45:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --yny7B53hgwgwltjVbiEVZ9XaOFxfxpZIR Content-Type: multipart/mixed; boundary="XgMkvNuwHewyuAw9IUwNuD0WSSg5oXUa4"; protected-headers="v1" From: Marek Zarychta To: freebsd-current@freebsd.org Message-ID: Subject: Re: btxld not found References: <8B42F93A-7B9E-4F99-9D77-43DA3BB7F045@van-laarhoven.org> In-Reply-To: <8B42F93A-7B9E-4F99-9D77-43DA3BB7F045@van-laarhoven.org> --XgMkvNuwHewyuAw9IUwNuD0WSSg5oXUa4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US W dniu 28.01.2020 o=C2=A012:36, Nick Hibma pisze: > Folks, > > Could anyone explain to me what I am doing wrong? make installworld fai= ls each time with the following error > > =3D=3D=3D> stand/i386/libi386 (install) > =3D=3D=3D> stand/i386/loader_4th (install) > strip -R .comment -R .note -o loader_4th.bin loader_4th.sym > btxld -v -f aout -e 0x200000 -o loader_4th -l /usr/obj/usr/src/i386.i38= 6/stand/i386/btx/btxldr/btxldr -b /usr/obj/usr/src/i386.i386/stand/i386/= btx/btx/btx loader_4th.bin > make[6]: exec(btxld) failed (No such file or directory) > *** Error code 1 > > This is with source of last week. I had this problem before (from old s= ources) and fixed it by specifying the full path to btxld in the stand/i3= 86/*/Makefile.=20 > > Any pointers? > > Nick Hibma > nick@van-laarhoven.org > > -- Open Source: We stand on the shoulders of giants. > =20 I am experiencing also the same issue on CURRENT for some time (a few months). Removing /usr/src and fresh checkout solved the issue for a while but it returned soon. I am not to complain here but to confirm that it happens. Best regards, --=20 Marek Zarychta --XgMkvNuwHewyuAw9IUwNuD0WSSg5oXUa4-- --yny7B53hgwgwltjVbiEVZ9XaOFxfxpZIR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEMOqvKm6wKvS1/ZeCdZ/s//1SjSwFAl4wHsUACgkQdZ/s//1S jSyMjgf/eEmY/cKi80g1/baMbsu5VQJUo8F4F0JZh0qXEheZVzkmwv9jYtqMj3ZO dlF4GyWQgNuEtp2gmIOjSU1aGBsxaWr/IXZcfPvmQl5MwkYwQSDefubF7j+tc65S k7Gu5i5qYcdXzZ8AgYSSyPakiwfDmFZ8NMp1nq/MXaIBoftp0rGtT7Ct8H1Yj45l R8s94djWKVv9A6pN2Q3Fx2HjeAOCBwi8BcqGmnoXW8mQrb3Y3zRe7jMNbou/3et5 9VdwAun/v12qTCHZkjrMx9yOWLt7uZVhhteUB2/PVZWqUiXqZFDo7QMIfcl1cdXZ w6H1aRUSm0qEZVO1nP75yPxfVA73Lg== =0/0J -----END PGP SIGNATURE----- --yny7B53hgwgwltjVbiEVZ9XaOFxfxpZIR-- From owner-freebsd-current@freebsd.org Tue Jan 28 11:57:41 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 24F792290C8 for ; Tue, 28 Jan 2020 11:57:41 +0000 (UTC) (envelope-from nick@van-laarhoven.org) Received: from violet.van-laarhoven.org (violet.van-laarhoven.org [IPv6:2a01:4f8:1c0c:72ba::3]) by mx1.freebsd.org (Postfix) with ESMTP id 486Q903nkwz3LYB for ; Tue, 28 Jan 2020 11:57:40 +0000 (UTC) (envelope-from nick@van-laarhoven.org) Received: from hille.fritz.box (217-19-28-102.dsl.cambrium.nl [217.19.28.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by violet.van-laarhoven.org (Postfix) with ESMTPSA id 660CE9CCD0; Tue, 28 Jan 2020 12:57:39 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Subject: Re: btxld not found From: Nick Hibma In-Reply-To: Date: Tue, 28 Jan 2020 12:57:38 +0100 Cc: FreeBSD Current Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: References: <8B42F93A-7B9E-4F99-9D77-43DA3BB7F045@van-laarhoven.org> To: Toomas Soome X-Mailer: Apple Mail (2.3608.40.2.2.4) X-Rspamd-Queue-Id: 486Q903nkwz3LYB X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of nick@van-laarhoven.org designates 2a01:4f8:1c0c:72ba::3 as permitted sender) smtp.mailfrom=nick@van-laarhoven.org X-Spamd-Result: default: False [-2.52 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[van-laarhoven.org]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; IP_SCORE(-0.82)[ipnet: 2a01:4f8::/29(-2.53), asn: 24940(-1.56), country: DE(-0.02)]; FREEMAIL_TO(0.00)[me.com]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 28 Jan 2020 11:57:41 -0000 > On 28/01 /2020, at 12:39, Toomas Soome wrote: >=20 >> On 28. Jan 2020, at 13:36, Nick Hibma wrote: >>=20 >> Folks, >>=20 >> Could anyone explain to me what I am doing wrong? make installworld = fails each time with the following error >>=20 >> =3D=3D=3D> stand/i386/libi386 (install) >> =3D=3D=3D> stand/i386/loader_4th (install) >> strip -R .comment -R .note -o loader_4th.bin loader_4th.sym >> btxld -v -f aout -e 0x200000 -o loader_4th -l = /usr/obj/usr/src/i386.i386/stand/i386/btx/btxldr/btxldr -b = /usr/obj/usr/src/i386.i386/stand/i386/btx/btx/btx loader_4th.bin >> make[6]: exec(btxld) failed (No such file or directory) >> *** Error code 1 >>=20 >> This is with source of last week. I had this problem before (from old = sources) and fixed it by specifying the full path to btxld in the = stand/i386/*/Makefile.=20 >>=20 >> Any pointers? >>=20 >=20 > it should be /usr/sbin/btxld; are you missing /usr/sbin from the path? Well, it's an 'installworld' so I would expect it to be providing that = program itself, but no, /usr/sbin/ is in the path of the current shell. Also, in some of the makefiles the target calling btxldr is depending on = the build of that executable: Index: stand/i386/pxeldr/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- stand/i386/pxeldr/Makefile (revision 357042) +++ stand/i386/pxeldr/Makefile (working copy) @@ -39,7 +39,7 @@ CLEANFILES+=3D ${LOADER} ${LOADER}: ${LOADERBIN} ${BTXLDR} ${BTXKERN} - btxld -v -f aout -e ${LOADER_ADDRESS} -o ${.TARGET} -l ${BTXLDR} = \ + /usr/sbin/btxld -v -f aout -e ${LOADER_ADDRESS} -o ${.TARGET} -l = ${BTXLDR} \ -b ${BTXKERN} ${LOADERBIN} Nick= From owner-freebsd-current@freebsd.org Tue Jan 28 15:29:45 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D97D4230453 for ; Tue, 28 Jan 2020 15:29:45 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 486Vsh5D2vz45kD for ; Tue, 28 Jan 2020 15:29:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x72e.google.com with SMTP id j20so13689738qka.10 for ; Tue, 28 Jan 2020 07:29:44 -0800 (PST) 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=zA/r8ti2n6YGIr4lbXWa2AuCHR4nOLGMH0Yc8yB7Or4=; b=Yr5uz2jHVxdHA8j+QRJGoC0XIVb5BAQjTLFc+K3xofB7yJIYOid4QOuplPtghsPd23 EhutYQaOEaU87ZD33uRGfDXxGaze5oELaaj32/MtFZwTjv6zZVVHdjtztdaZhSmO3dMJ MnQqh/FT1LFqCMLi0NvNwmqiSXvKjZjz8YPuFbdhbG0R12sR6hRgo8X6KPe8UwSGytCH 6lwy2ySiIyQExjXupsXcNhq/8lC7XpI40f+y3fXUVvaeny2WOxiQLkpZ/v/L7ba74xrD wR3G2OvI8UnJRbmmQKCdn3PEeaKu41pI4JfEIOqRrP/KW41ZtTL1EBG6tbRwNZitKhh5 7W1Q== 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=zA/r8ti2n6YGIr4lbXWa2AuCHR4nOLGMH0Yc8yB7Or4=; b=gM+3RzCqnToonRMQ+aVQdRA/txj+zPcl1H4JesWc8y64bK97kiywNwcPFLdKivCI7B 5GJVouJoqLlOxYsqJPQqQqb4yeSMmX2gFM/u/QEh6JbSueLFdWsRftUm7io8LQekotc5 qn8Mr3uzvckMk+Na8oGSbd3jmFASZQAYpezwrnPKnWiEI+c+dmyoKWS0sP2FU7xkYmLH TQx4BojJQjOXKYobvVCcp/FXC/+OK/8aapIziaLR3ro6P0a+2l1ZFRvF7ftN1QDV3+Vh /auXJSHbY4cuANQghrgiX76g6uLhEpmfmoEpl7EpuPwZsr2LCtDbIi9Afe6Mh0mUdbT9 0pHg== X-Gm-Message-State: APjAAAWeJn9u0o/dLYB6GlK1r+7iXct52m6VB8ymsJWtDmdBke8xy9al SFEx8nkdLCT3h3osmAqSF/9VuI4CxlktWD1TM4+gSw== X-Google-Smtp-Source: APXvYqxasLAWWHjmhLjNMtcHAR2+ATFIT2LhXjTVCM5v5t7VWS/2MHaXX2CK9P3XvqTU92UEjn99f3xCXo+zxJ/wGKQ= X-Received: by 2002:a05:620a:12c8:: with SMTP id e8mr14285970qkl.380.1580225383299; Tue, 28 Jan 2020 07:29:43 -0800 (PST) MIME-Version: 1.0 References: <8B42F93A-7B9E-4F99-9D77-43DA3BB7F045@van-laarhoven.org> In-Reply-To: From: Warner Losh Date: Tue, 28 Jan 2020 08:29:29 -0700 Message-ID: Subject: Re: btxld not found To: Nick Hibma Cc: Toomas Soome , FreeBSD Current Mailing List X-Rspamd-Queue-Id: 486Vsh5D2vz45kD X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=Yr5uz2jH; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::72e) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.61 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; RCVD_COUNT_TWO(0.00)[2]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; URI_COUNT_ODD(1.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[e.2.7.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-2.61)[ip: (-9.18), ipnet: 2607:f8b0::/32(-2.04), asn: 15169(-1.78), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; FREEMAIL_CC(0.00)[me.com] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 28 Jan 2020 15:29:45 -0000 On Tue, Jan 28, 2020, 4:57 AM Nick Hibma wrote: > > On 28/01 /2020, at 12:39, Toomas Soome wrote: > > > >> On 28. Jan 2020, at 13:36, Nick Hibma wrote: > >> > >> Folks, > >> > >> Could anyone explain to me what I am doing wrong? make installworld > fails each time with the following error > >> > >> ===> stand/i386/libi386 (install) > >> ===> stand/i386/loader_4th (install) > >> strip -R .comment -R .note -o loader_4th.bin loader_4th.sym > >> btxld -v -f aout -e 0x200000 -o loader_4th -l > /usr/obj/usr/src/i386.i386/stand/i386/btx/btxldr/btxldr -b > /usr/obj/usr/src/i386.i386/stand/i386/btx/btx/btx loader_4th.bin > >> make[6]: exec(btxld) failed (No such file or directory) > >> *** Error code 1 > >> > >> This is with source of last week. I had this problem before (from old > sources) and fixed it by specifying the full path to btxld in the > stand/i386/*/Makefile. > >> > >> Any pointers? > >> > > > > it should be /usr/sbin/btxld; are you missing /usr/sbin from the path? > > Well, it's an 'installworld' so I would expect it to be providing that > program itself, but no, /usr/sbin/ is in the path of the current shell. > > Also, in some of the makefiles the target calling btxldr is depending on > the build of that executable: > > Index: stand/i386/pxeldr/Makefile > =================================================================== > --- stand/i386/pxeldr/Makefile (revision 357042) > +++ stand/i386/pxeldr/Makefile (working copy) > @@ -39,7 +39,7 @@ > CLEANFILES+= ${LOADER} > > ${LOADER}: ${LOADERBIN} ${BTXLDR} ${BTXKERN} > - btxld -v -f aout -e ${LOADER_ADDRESS} -o ${.TARGET} -l ${BTXLDR} \ > + /usr/sbin/btxld -v -f aout -e ${LOADER_ADDRESS} -o ${.TARGET} -l > ${BTXLDR} \ > -b ${BTXKERN} ${LOADERBIN} > This is definitely wrong. We have either a path that is wrong, or we aren't reinstalling btxld in the right place. Warner Nick > _______________________________________________ > 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 Jan 28 16:08:19 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D26E323188E for ; Tue, 28 Jan 2020 16:08:19 +0000 (UTC) (envelope-from nick@van-laarhoven.org) Received: from violet.van-laarhoven.org (violet.van-laarhoven.org [IPv6:2a01:4f8:1c0c:72ba::3]) by mx1.freebsd.org (Postfix) with ESMTP id 486WkB6d3Rz48L1 for ; Tue, 28 Jan 2020 16:08:18 +0000 (UTC) (envelope-from nick@van-laarhoven.org) Received: from hille.fritz.box (217-19-28-102.dsl.cambrium.nl [217.19.28.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by violet.van-laarhoven.org (Postfix) with ESMTPSA id 4FF449CCAD; Tue, 28 Jan 2020 17:08:16 +0100 (CET) From: Nick Hibma Message-Id: <5A341389-36CE-49F0-AACD-374CEEF412E0@van-laarhoven.org> Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Subject: Re: btxld not found Date: Tue, 28 Jan 2020 17:08:15 +0100 In-Reply-To: Cc: Toomas Soome , FreeBSD Current Mailing List To: Warner Losh References: <8B42F93A-7B9E-4F99-9D77-43DA3BB7F045@van-laarhoven.org> X-Mailer: Apple Mail (2.3608.40.2.2.4) X-Rspamd-Queue-Id: 486WkB6d3Rz48L1 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of nick@van-laarhoven.org designates 2a01:4f8:1c0c:72ba::3 as permitted sender) smtp.mailfrom=nick@van-laarhoven.org X-Spamd-Result: default: False [-2.52 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.996,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+mx]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[van-laarhoven.org]; NEURAL_HAM_LONG(-1.00)[-0.998,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; IP_SCORE(-0.82)[ipnet: 2a01:4f8::/29(-2.53), asn: 24940(-1.56), country: DE(-0.02)]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; FREEMAIL_CC(0.00)[me.com]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 28 Jan 2020 16:08:19 -0000 > On Tue, Jan 28, 2020, 4:57 AM Nick Hibma > wrote: > > On 28/01 /2020, at 12:39, Toomas Soome > wrote: > >=20 > >> On 28. Jan 2020, at 13:36, Nick Hibma > wrote: > >>=20 > >> Folks, > >>=20 > >> Could anyone explain to me what I am doing wrong? make installworld = fails each time with the following error > >>=20 > >> =3D=3D=3D> stand/i386/libi386 (install) > >> =3D=3D=3D> stand/i386/loader_4th (install) > >> strip -R .comment -R .note -o loader_4th.bin loader_4th.sym > >> btxld -v -f aout -e 0x200000 -o loader_4th -l = /usr/obj/usr/src/i386.i386/stand/i386/btx/btxldr/btxldr -b = /usr/obj/usr/src/i386.i386/stand/i386/btx/btx/btx loader_4th.bin > >> make[6]: exec(btxld) failed (No such file or directory) > >> *** Error code 1 > >>=20 > >> This is with source of last week. I had this problem before (from = old sources) and fixed it by specifying the full path to btxld in the = stand/i386/*/Makefile.=20 > >>=20 > >> Any pointers? > >>=20 > >=20 > > it should be /usr/sbin/btxld; are you missing /usr/sbin from the = path? >=20 > Well, it's an 'installworld' so I would expect it to be providing that = program itself, but no, /usr/sbin/ is in the path of the current shell. >=20 > Also, in some of the makefiles the target calling btxldr is depending = on the build of that executable: >=20 > Index: stand/i386/pxeldr/Makefile > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- stand/i386/pxeldr/Makefile (revision 357042) > +++ stand/i386/pxeldr/Makefile (working copy) > @@ -39,7 +39,7 @@ > CLEANFILES+=3D ${LOADER} >=20 > ${LOADER}: ${LOADERBIN} ${BTXLDR} ${BTXKERN} > - btxld -v -f aout -e ${LOADER_ADDRESS} -o ${.TARGET} -l = ${BTXLDR} \ > + /usr/sbin/btxld -v -f aout -e ${LOADER_ADDRESS} -o ${.TARGET} = -l ${BTXLDR} \ > -b ${BTXKERN} ${LOADERBIN} >=20 > This is definitely wrong. We have either a path that is wrong, or we = aren't reinstalling btxld in the right place. >=20 > Warner This is not a fix, this is to get me through the installworld. As I've = not seen any mention of this the past 6 months it must be something on = my system that makes things go bad, but I have no idea what. They are being built, and installed: {e}nick@fimkjecurrent:/usr/src/stand/i386/btx % find / -name btxld -ls 1908308 48 -r-xr-xr-x 1 root wheel = 22988 Jan 27 23:37 /usr/sbin/btxld 1319010 4 drwxr-xr-x 2 nick nick = 512 Sep 15 2017 /usr/src/usr.sbin/btxld 3369564 4 drwxrwxr-x 2 root wheel = 512 Jan 27 22:33 = /usr/obj/usr/src/i386.i386/usr.sbin/btxld 3371323 52 -rwxr-xr-x 1 root wheel = 25816 Jan 27 22:33 = /usr/obj/usr/src/i386.i386/usr.sbin/btxld/btxld I guess the difference in file size is due to it being stripped during = install? Nick= From owner-freebsd-current@freebsd.org Tue Jan 28 16:18:39 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 702A1231D5B for ; Tue, 28 Jan 2020 16:18:39 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound3d.ore.mailhop.org (outbound3d.ore.mailhop.org [54.186.57.195]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 486Wy706gtz48xh for ; Tue, 28 Jan 2020 16:18:38 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1580228317; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=BshcfeLmKnAM+RtsHKnRLRZFhTg0D4YAba74O2he1NLbxIK+FwAyD6J4EFoachuQrAjREinhi+0yk oFAyw9iB5odDjUWCWeIoZFC7ggaeV4fhFgYBnWEvIWbxkpnkFEu3vXKF+Bg9vqsL7lRJ3TvGean2h7 dlh2ZjyVaNZwHaFC2zp7Eyb8Mpg73QaLyAxNG7CdcWTpG2lyDvznVY83LdZoj0IwSxWONPvc/Alxlo kURlH3owZR+V8lTImmzFi+IONW9Dyo8raFtLDCsINjSd18oHJ0YXZUTa1wqS35MLGkbP56c8eg5JNh cBLhOAw02T/bFqROBfTqw0GK3F1E+rw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=FcPySEN5C1QzA8tJuHvPyvsXGtjKNdVjWXJMB4mU6vw=; b=qZtRHzaaHjXoWRvgScvn+VQj/GznUEGSFkjMNKcHN+cc3Y8eOvr1y2L3rr/jjaGGzd9hCPbDhT+5x lNa1u65TxJQE51zY+Ka+jXwWns1YbYfSAqe4YqrDxfHOd1xJFcDWSwQaUPAe+cTjybcujcU3hQzB7X WMEXNGeq1I9+DxwN37pikYsTuBjweYDWMSA4JJYv5DQfr7z63WS/XkDYHSd2tsZ0V+pELhv53Gj4iz jtwMrlSt2H3rzzwdk25lQ7cf3Fu8OA5qhQQSn49hJkvgxSlLsCWiYye+GLHRfKkaq/uPtuZ27M3CHn hXtLx0eez7oXSOnDVJwPiJgRwhslNPg== ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=FcPySEN5C1QzA8tJuHvPyvsXGtjKNdVjWXJMB4mU6vw=; b=cFNAMdPRFgM690csYWY2yOm1MH/4Jd3VxBHJjDHQx/6zivLenVHhrg0O2sOku9L3YiB2297sancXf +Dug/NGGBeJwHhp+zZsQ4CTjC+Qvlf9bkPIEtPQv1fDce8qYLpNzpU03jVKvddhJ5RLlk3i/gq+vIf qffHTObWZPnkDNUiveOxKyTbWP9qpet8TQo4bqLdU5ye6XgnddLJpMTx6FIHYjbe77+06Qo7GkKxpb vjtVGmaepUjEQB6cDiJrxdZUjDDyGtq1OTJtXh6x4G/yrWW8YSaDHji4lyzY7sgjYyj+PRxxfiWlly pM74wSyMnku1r7/JxJeukwaegPjhJ9Q== X-MHO-RoutePath: aGlwcGll X-MHO-User: d4ca827c-41e9-11ea-b80d-052b4a66b6b2 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 outbound3.ore.mailhop.org (Halon) with ESMTPSA id d4ca827c-41e9-11ea-b80d-052b4a66b6b2; Tue, 28 Jan 2020 16:18:36 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id 00SGIXA2012103; Tue, 28 Jan 2020 09:18:34 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: Subject: Re: btxld not found From: Ian Lepore To: Nick Hibma , Warner Losh Cc: FreeBSD Current Mailing List Date: Tue, 28 Jan 2020 09:18:33 -0700 In-Reply-To: <5A341389-36CE-49F0-AACD-374CEEF412E0@van-laarhoven.org> References: <8B42F93A-7B9E-4F99-9D77-43DA3BB7F045@van-laarhoven.org> <5A341389-36CE-49F0-AACD-374CEEF412E0@van-laarhoven.org> Content-Type: text/plain; charset="ASCII" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 486Wy706gtz48xh X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.96 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.98)[-0.975,0]; NEURAL_HAM_LONG(-0.99)[-0.990,0]; ASN(0.00)[asn:16509, ipnet:54.186.0.0/15, country:US] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 28 Jan 2020 16:18:39 -0000 On Tue, 2020-01-28 at 17:08 +0100, Nick Hibma wrote: > > On Tue, Jan 28, 2020, 4:57 AM Nick Hibma > > wrote: > > > On 28/01 /2020, at 12:39, Toomas Soome > > tsoome@me.com>> wrote: > > > > > > > On 28. Jan 2020, at 13:36, Nick Hibma > > > > wrote: > > > > > > > > Folks, > > > > > > > > Could anyone explain to me what I am doing wrong? make > > > > installworld fails each time with the following error > > > > > > > > ===> stand/i386/libi386 (install) > > > > ===> stand/i386/loader_4th (install) > > > > strip -R .comment -R .note -o loader_4th.bin loader_4th.sym > > > > btxld -v -f aout -e 0x200000 -o loader_4th -l > > > > /usr/obj/usr/src/i386.i386/stand/i386/btx/btxldr/btxldr -b > > > > /usr/obj/usr/src/i386.i386/stand/i386/btx/btx/btx > > > > loader_4th.bin > > > > make[6]: exec(btxld) failed (No such file or directory) > > > > *** Error code 1 > > > > > > > > This is with source of last week. I had this problem before > > > > (from old sources) and fixed it by specifying the full path to > > > > btxld in the stand/i386/*/Makefile. > > > > > > > > Any pointers? > > > > > > > > > > it should be /usr/sbin/btxld; are you missing /usr/sbin from the > > > path? > > > > Well, it's an 'installworld' so I would expect it to be providing > > that program itself, but no, /usr/sbin/ is in the path of the > > current shell. > > > > Also, in some of the makefiles the target calling btxldr is > > depending on the build of that executable: > > > > Index: stand/i386/pxeldr/Makefile > > =================================================================== > > --- stand/i386/pxeldr/Makefile (revision 357042) > > +++ stand/i386/pxeldr/Makefile (working copy) > > @@ -39,7 +39,7 @@ > > CLEANFILES+= ${LOADER} > > > > ${LOADER}: ${LOADERBIN} ${BTXLDR} ${BTXKERN} > > - btxld -v -f aout -e ${LOADER_ADDRESS} -o ${.TARGET} -l > > ${BTXLDR} \ > > + /usr/sbin/btxld -v -f aout -e ${LOADER_ADDRESS} -o > > ${.TARGET} -l ${BTXLDR} \ > > -b ${BTXKERN} ${LOADERBIN} > > > > This is definitely wrong. We have either a path that is wrong, or > > we aren't reinstalling btxld in the right place. > > > > Warner > > This is not a fix, this is to get me through the installworld. As > I've not seen any mention of this the past 6 months it must be > something on my system that makes things go bad, but I have no idea > what. > > They are being built, and installed: > > {e}nick@fimkjecurrent:/usr/src/stand/i386/btx % find / -name btxld > -ls > 1908308 48 -r-xr-xr-x 1 > root wheel > 22988 Jan 27 23:37 /usr/sbin/btxld > 1319010 4 drwxr-xr-x 2 > nick nick > 512 Sep 15 2017 /usr/src/usr.sbin/btxld > 3369564 4 drwxrwxr-x 2 > root wheel > 512 Jan 27 22:33 /usr/obj/usr/src/i386.i386/usr.sbin/btxld > 3371323 52 -rwxr-xr-x 1 > root wheel > 25816 Jan 27 22:33 /usr/obj/usr/src/i386.i386/usr.sbin/btxld/btxld > > I guess the difference in file size is due to it being stripped > during install? > > Nick I would expect the one that gets used during make install to be in the objdir/.../tmp/usr/sbin directory, like other build and install tools. But oddly, I don't have btxld in tmp for amd64 builds, only for i386. -- Ian From owner-freebsd-current@freebsd.org Tue Jan 28 16:58:24 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id ABC212334ED for ; Tue, 28 Jan 2020 16:58:24 +0000 (UTC) (envelope-from jfc@mit.edu) Received: from outgoing-exchange-7.mit.edu (outgoing-exchange-7.mit.edu [18.9.28.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.outgoing-exchange.mit.edu", Issuer "InCommon RSA Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 486Xqz6fJnz4CqL for ; Tue, 28 Jan 2020 16:58:23 +0000 (UTC) (envelope-from jfc@mit.edu) Received: from w92exedge4.exchange.mit.edu (W92EXEDGE4.EXCHANGE.MIT.EDU [18.7.73.16]) by outgoing-exchange-7.mit.edu (8.14.7/8.12.4) with ESMTP id 00SGw807024891 for ; Tue, 28 Jan 2020 11:58:14 -0500 Received: from w92expo29.exchange.mit.edu (18.7.74.41) by w92exedge4.exchange.mit.edu (18.7.73.16) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Tue, 28 Jan 2020 11:55:20 -0500 Received: from OC11EXPO29.exchange.mit.edu (18.9.4.102) by w92expo29.exchange.mit.edu (18.7.74.41) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 28 Jan 2020 11:57:58 -0500 Received: from OC11EXPO29.exchange.mit.edu ([18.9.4.102]) by oc11expo29.exchange.mit.edu ([18.9.4.102]) with mapi id 15.00.1365.000; Tue, 28 Jan 2020 11:57:58 -0500 From: John F Carr To: "freebsd-current@freebsd.org" Subject: Emacs tramp mode doesn't work with CURRENT Thread-Topic: Emacs tramp mode doesn't work with CURRENT Thread-Index: AQHV1fwXD6fi2HIsu0G99z3cF1tJDA== Date: Tue, 28 Jan 2020 16:57:58 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [108.7.221.50] Content-Type: text/plain; charset="us-ascii" Content-ID: <3D76CBE5E7137240B9AEFF38F0CC629C@exchange.mit.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Rspamd-Queue-Id: 486Xqz6fJnz4CqL X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of jfc@mit.edu designates 18.9.28.58 as permitted sender) smtp.mailfrom=jfc@mit.edu X-Spamd-Result: default: False [-3.47 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCVD_COUNT_FIVE(0.00)[5]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:18.9.28.0/24]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[mit.edu]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE(-0.97)[ipnet: 18.9.0.0/16(-4.79), asn: 3(-0.03), country: US(-0.05)]; RCVD_IN_DNSWL_MED(-0.20)[58.28.9.18.list.dnswl.org : 127.0.11.2]; TO_DN_EQ_ADDR_ALL(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[58.28.9.18.rep.mailspike.net : 127.0.0.17]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:3, ipnet:18.9.0.0/16, country:US]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 28 Jan 2020 16:58:24 -0000 I use emacs tramp mode, which opens an ssh connection to a remote machine f= or file access. It works to Linux and FreeBSD 12.1, but not to CURRENT. T= here has been a change in the way characters are echoed by the shell, with = 12.1 treating a consecutive run of backspace as an atomic unit and CURRENT = processing them one at a time. This is not necessarily a bug, but it is a = nuisance and independently it is suboptimal. I would like to blame libedit, which changed since 12.1. I didn't see any = changes in pty code and the problem happens with at least two different she= lls. It could also be caused by a change to sshd or something I haven't th= rough of. Here is a longer explanation. Emacs tramp mode opens an ssh connection to a remote machine. It doesn't w= ant to see input echoed back so it runs stty -inlcr -onlcr -echo kill '^U' erase '^H' This doesn't do anything useful if a shell is running in line editing mode = (raw) instead of using the tty (cooked). So tramp falls back to a hack to = detect echoed input. It sends "_echo" followed by a string of backspace ch= aracters. "_echo" is unlikely to appear in program output. Here is the next command after the initial stty: _echo^H^H^H^H^Hstty icanon erase ^H cols 32767_echo^H^H^H^H^H The groups of 5 ^H represent 5 backspace characters and the lone ^H in the = middle is a two character sequence for stty. The terminal output from a 12.1 system is _echo^H ^H^H ^H^H ^H^H ^H^H ^Hstty icanon erase ^H cols 32767_echo^H ^H^H ^= H^H ^H^H ^H^H ^H #$=20 where again the middle ^H is a two character sequence and the others are ba= ckspace characters. There is a carriage return between the two lines. "#$= " is the shell prompt set by tramp. The terminal output from a CURRENT system is _echo #$ _ech ^H #$ _ec ^H #$ _e ^H #$ _ ^H #$ ^Hstty icanon erase ^H cols 32767_echo #$ stty icanon erase ^H cols 32767_ech ^H #$ stty icanon erase ^H cols 32767_ec ^H #$ stty icanon erase ^H cols 32767_e ^H #$ stty icanon erase ^H cols 32767_ ^H #$ stty icanon erase ^H cols 32767 ^H #$=20 with carriage returns between lines. This does not make sense to emacs. I tried both /bin/sh and /bin/csh as shells and tramp didn't work with eith= er. I put set +V and set +E in my .profile thinking that would turn off li= ne editing but there was no change. Probably the shell still takes raw inp= ut. A possible complicating factor is the CURRENT machines are both 64 bit ARM = and the 12.1 machine is amd64. One has unsigned characters, the other sign= ed. Shouldn't matter, but I haven't tried 12.1 on ARM so I can't swear it = works.= From owner-freebsd-current@freebsd.org Tue Jan 28 17:15:32 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 85493233E51 for ; Tue, 28 Jan 2020 17:15:32 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st43p00im-zteg10073401.me.com (st43p00im-zteg10073401.me.com [17.58.63.181]) (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 486YCl3nq7z4F6l for ; Tue, 28 Jan 2020 17:15:30 +0000 (UTC) (envelope-from tsoome@me.com) Received: from [10.247.0.13] (unknown [91.209.240.229]) by st43p00im-zteg10073401.me.com (Postfix) with ESMTPSA id 303965E0D9B; Tue, 28 Jan 2020 17:15:29 +0000 (UTC) From: Toomas Soome Message-Id: <52681387-567F-4C66-9662-EEF418A7856D@me.com> Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Subject: Re: btxld not found Date: Tue, 28 Jan 2020 19:15:27 +0200 In-Reply-To: <5A341389-36CE-49F0-AACD-374CEEF412E0@van-laarhoven.org> Cc: Warner Losh , FreeBSD Current Mailing List To: Nick Hibma References: <8B42F93A-7B9E-4F99-9D77-43DA3BB7F045@van-laarhoven.org> <5A341389-36CE-49F0-AACD-374CEEF412E0@van-laarhoven.org> X-Mailer: Apple Mail (2.3608.40.2.2.4) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-01-28_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-2001280129 X-Rspamd-Queue-Id: 486YCl3nq7z4F6l X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.60 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:17.58.0.0/16:c]; FREEMAIL_FROM(0.00)[me.com]; MV_CASE(0.50)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[me.com:+]; DMARC_POLICY_ALLOW(-0.50)[me.com,quarantine]; RCVD_IN_DNSWL_LOW(-0.10)[181.63.58.17.list.dnswl.org : 127.0.5.1]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[me.com]; ASN(0.00)[asn:714, ipnet:17.58.63.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[me.com:s=1a1hai]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; IP_SCORE(0.00)[ip: (-1.87), ipnet: 17.58.63.0/24(-1.49), asn: 714(-2.27), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; DWL_DNSWL_LOW(-1.00)[me.com.dwl.dnswl.org : 127.0.5.1]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 28 Jan 2020 17:15:32 -0000 > On 28. Jan 2020, at 18:08, Nick Hibma wrote: >=20 >=20 >> On Tue, Jan 28, 2020, 4:57 AM Nick Hibma > wrote: >> > On 28/01 /2020, at 12:39, Toomas Soome > wrote: >> >=20 >> >> On 28. Jan 2020, at 13:36, Nick Hibma > wrote: >> >>=20 >> >> Folks, >> >>=20 >> >> Could anyone explain to me what I am doing wrong? make = installworld fails each time with the following error >> >>=20 >> >> =3D=3D=3D> stand/i386/libi386 (install) >> >> =3D=3D=3D> stand/i386/loader_4th (install) >> >> strip -R .comment -R .note -o loader_4th.bin loader_4th.sym >> >> btxld -v -f aout -e 0x200000 -o loader_4th -l = /usr/obj/usr/src/i386.i386/stand/i386/btx/btxldr/btxldr -b = /usr/obj/usr/src/i386.i386/stand/i386/btx/btx/btx loader_4th.bin >> >> make[6]: exec(btxld) failed (No such file or directory) >> >> *** Error code 1 >> >>=20 >> >> This is with source of last week. I had this problem before (from = old sources) and fixed it by specifying the full path to btxld in the = stand/i386/*/Makefile.=20 >> >>=20 >> >> Any pointers? >> >>=20 >> >=20 >> > it should be /usr/sbin/btxld; are you missing /usr/sbin from the = path? >>=20 >> Well, it's an 'installworld' so I would expect it to be providing = that program itself, but no, /usr/sbin/ is in the path of the current = shell. >>=20 >> Also, in some of the makefiles the target calling btxldr is depending = on the build of that executable: >>=20 >> Index: stand/i386/pxeldr/Makefile >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- stand/i386/pxeldr/Makefile (revision 357042) >> +++ stand/i386/pxeldr/Makefile (working copy) >> @@ -39,7 +39,7 @@ >> CLEANFILES+=3D ${LOADER} >>=20 >> ${LOADER}: ${LOADERBIN} ${BTXLDR} ${BTXKERN} >> - btxld -v -f aout -e ${LOADER_ADDRESS} -o ${.TARGET} -l = ${BTXLDR} \ >> + /usr/sbin/btxld -v -f aout -e ${LOADER_ADDRESS} -o ${.TARGET} = -l ${BTXLDR} \ >> -b ${BTXKERN} ${LOADERBIN} >>=20 >> This is definitely wrong. We have either a path that is wrong, or we = aren't reinstalling btxld in the right place. >>=20 >> Warner >=20 > This is not a fix, this is to get me through the installworld. As I've = not seen any mention of this the past 6 months it must be something on = my system that makes things go bad, but I have no idea what. >=20 > They are being built, and installed: >=20 > {e}nick@fimkjecurrent:/usr/src/stand/i386/btx % find / -name btxld -ls > 1908308 48 -r-xr-xr-x 1 root = wheel 22988 Jan 27 23:37 /usr/sbin/btxld > 1319010 4 drwxr-xr-x 2 nick nick = 512 Sep 15 2017 = /usr/src/usr.sbin/btxld > 3369564 4 drwxrwxr-x 2 root = wheel 512 Jan 27 22:33 = /usr/obj/usr/src/i386.i386/usr.sbin/btxld > 3371323 52 -rwxr-xr-x 1 root = wheel 25816 Jan 27 22:33 = /usr/obj/usr/src/i386.i386/usr.sbin/btxld/btxld >=20 > I guess the difference in file size is due to it being stripped during = install? >=20 > Nick why it is installed into directory: = /usr/obj/usr/src/i386.i386/usr.sbin/btxld ?=20 rgds, toomas From owner-freebsd-current@freebsd.org Tue Jan 28 17:17:40 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7225F23404E for ; Tue, 28 Jan 2020 17:17:40 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-54.consmr.mail.gq1.yahoo.com (sonic316-54.consmr.mail.gq1.yahoo.com [98.137.69.30]) (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 486YGC0LDWz4FNG for ; Tue, 28 Jan 2020 17:17:38 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: zQi0S_QVM1m59aphmYcoPXh7VCp_w2nsjrvA3_noGb7tgqRueA0VaXnBbZkOBsL T4Jo.EWvnjFgfqjtLusEivnP6rs9YH2FTjDQG740EgpZBq8GhjlzZkC12rDkcqx7Bz4Mp2zgnsFA kmkTV1rb9hMKGhSeoHgQ8VFvhG56nSd3KIdiTllVjmnlIeICRbuy3uPz8MDZlc0Edo.syipyZ5UL inwJiCqldqhZa8APxFKDWw2oM_bOEGYascGoBiNGDUasEFVHKB55zIu5ZdWU_6HDA1s7i8Po1Mfr uXIuXkzO_YRb0zmsiTV6EgBZ.saOFdrUJeTGeTUflMN63GljezDYVURoh8Ti1gvPF6DbnjcbkSH5 UbEsJdy7Qh1GPQkC_B78GezS6Md54pJYT_CMpwPaLAq4x8ZKR6GKGBmSqeCZrCtgGXn_ynSHclOH _26xyPeZPLWvYRjqgRqXirml6R0pobhrIlvqC.8c4dDtQ9FmiYXXV70k9OXXUpOU86U7ws0VL1q0 oSjUr_Du.SEQGwhSFKEVubn6GtYip_i7bOxZ.affwSXTwZQ885nbh0otfPQuQNlRaEIpbmnyXheg I46TpqCWz.C2JSXY0WfCImJVWvCMGsSx6_HPDHEiLorovDNAr7pmPUQT7rNtMnleaOP3mTR_Fvd6 4DvgXlARkmbni9mksA6hry_oWe6mZDlbneYGmWAvgr0mJnCMNdrs12XSBpY7k.JleNSLsqHq.aER rbXKWDiJIH8gb_jxRHDYYCdivNXfl6mIdKp5.YeSqU021UxqjC_nLPW8ot7yb.l3FMSGKk1W8rDz NmgaM.wB2V8HMVqMgDQ2IcAoO4PMuvns9YU.kb2UC.TwzD.KGs9V0aNkH2NpdRUOjVfWrilYY7w2 JVqDl9Un7gWYJ.Ks4meRXHXiYU4mBd.lmRMpYIMkOUNutsblJ9RXjZFx5neFXHY4y42KwmxJ7psF BbokL_yVjbD9D9AzW0lAuepgN_Fjpu.ZPdkOeCXLYkZ_zFfdewkQKAnrMfmLmL44umfcOF1Cwkoi 8wrj0MwOuOl25Hl3aFpcxHNLltXAxfRPan.j76Cz.BBAgpKDjL8q5FKe3wm7VQch9xFj4cYTX5aT Eyfx39opsrtgQrLMTTM4g57oDAnE_85p_ekZ9tf0h6WY5u7a4ZF4WVb0vEVY4BPQpMKbDWO25LLb XnzUmdewnu8LWYGTnxLNHvxa6AKUR9d1RA3hFfa4YgxoRJLn4WJd9qvuameD9qm8XMxgT5cOCUu5 Dj7tHwsk.un3xeYSGtaQ_OKdmNHlU1Xaxaquqcl1IOHybQUTJyRX3t5FIPwhmL6Gi9N6ZeSWSzfj 1LBidmtUzPSmADS8WQAZf2Yq.h_FWn2ScFZUoBraq3mO_ma9n3Rk7LWdsYMcZQNWbmoa1DPNBM0j Y0k8s2xIzlcAohzzqgqD3vwnpG.vAY8W0Cqu1kA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Tue, 28 Jan 2020 17:17:37 +0000 Received: by smtp407.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 357c69d3f9ec290210f30afdd608a7da; Tue, 28 Jan 2020 17:17:32 +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 13.0 \(3608.40.2.2.4\)) Subject: Re: btxld not found Message-Id: <630F13A2-E76C-4B14-9D04-76BFCE108FDD@yahoo.com> Date: Tue, 28 Jan 2020 09:17:31 -0800 To: nick@van-laarhoven.org, FreeBSD Current X-Mailer: Apple Mail (2.3608.40.2.2.4) References: <630F13A2-E76C-4B14-9D04-76BFCE108FDD.ref@yahoo.com> X-Rspamd-Queue-Id: 486YGC0LDWz4FNG X-Spamd-Bar: / X-Spamd-Result: default: False [-0.82 / 15.00]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.41)[-0.412,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (4.46), ipnet: 98.137.64.0/21(0.84), asn: 36647(0.67), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.09)[0.087,0]; RCVD_IN_DNSWL_NONE(0.00)[30.69.137.98.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[30.69.137.98.rep.mailspike.net : 127.0.0.17]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 28 Jan 2020 17:17:40 -0000 Nick Hibma nick at van-laarhoven.org wrote on Tue Jan 28 16:08:19 UTC 2020 : > > On Tue, Jan 28, 2020, 4:57 AM Nick Hibma > wrote: > > > On 28/01 /2020, at 12:39, Toomas Soome > wrote: > > >=20 > > >> On 28. Jan 2020, at 13:36, Nick Hibma > wrote: > > >>=20 > > >> Folks, > > >>=20 > > >> Could anyone explain to me what I am doing wrong? make = installworld fails each time with the following error > > >>=20 > > >> =3D=3D=3D> stand/i386/libi386 (install) > > >> =3D=3D=3D> stand/i386/loader_4th (install) > > >> strip -R .comment -R .note -o loader_4th.bin loader_4th.sym > > >> btxld -v -f aout -e 0x200000 -o loader_4th -l = /usr/obj/usr/src/i386.i386/stand/i386/btx/btxldr/btxldr -b = /usr/obj/usr/src/i386.i386/stand/i386/btx/btx/btx loader_4th.bin > > >> make[6]: exec(btxld) failed (No such file or directory) > > >> *** Error code 1 > > >>=20 > > >> This is with source of last week. I had this problem before (from = old sources) and fixed it by specifying the full path to btxld in the = stand/i386/*/Makefile.=20 > > >>=20 > > >> Any pointers? > > >>=20 > > >=20 > > > it should be /usr/sbin/btxld; are you missing /usr/sbin from the = path? > >=20 > > Well, it's an 'installworld' so I would expect it to be providing = that program itself, but no, /usr/sbin/ is in the path of the current = shell. > >=20 > > Also, in some of the makefiles the target calling btxldr is = depending on the build of that executable: > >=20 > > Index: stand/i386/pxeldr/Makefile > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > --- stand/i386/pxeldr/Makefile (revision 357042) > > +++ stand/i386/pxeldr/Makefile (working copy) > > @@ -39,7 +39,7 @@ > > CLEANFILES+=3D ${LOADER} > >=20 > > ${LOADER}: ${LOADERBIN} ${BTXLDR} ${BTXKERN} > > - btxld -v -f aout -e ${LOADER_ADDRESS} -o ${.TARGET} -l = ${BTXLDR} \ > > + /usr/sbin/btxld -v -f aout -e ${LOADER_ADDRESS} -o = ${.TARGET} -l ${BTXLDR} \ > > -b ${BTXKERN} ${LOADERBIN} > >=20 > > This is definitely wrong. We have either a path that is wrong, or we = aren't reinstalling btxld in the right place. > >=20 > > Warner >=20 > This is not a fix, this is to get me through the installworld. As I've = not seen any mention of this the past 6 months it must be something on = my system that makes things go bad, but I have no idea what. I reported this to toolchain back on 2019-Dec-14 and 15, for updating to head -r355761 then -r355777 at the time: = https://lists.freebsd.org/pipermail/freebsd-toolchain/2019-December/005127= .html = https://lists.freebsd.org/pipermail/freebsd-toolchain/2019-December/005130= .html It is not just your context that has the issue. The 2nd message showed some interesting timestamps from the build. I've found that re-running buildworld (not from scratch) with -j1 then doing installworld seemed to reliably deal with it. Allowing -j32 was unreliable for the rerun. (Despite that early report.) =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 Jan 28 18:11:46 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 23EA123621B for ; Tue, 28 Jan 2020 18:11:46 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 486ZSf09YGz4KYb; Tue, 28 Jan 2020 18:11:46 +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 "Let's Encrypt Authority X3" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id DE9EC1DFF0; Tue, 28 Jan 2020 18:11:45 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:470:7a58::b11e:4a42:c8e1:25b0] (unknown [IPv6:2001:470:7a58:0:b11e:4a42:c8e1:25b0]) (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 C3F91238E0; Tue, 28 Jan 2020 19:11:44 +0100 (CET) From: Dimitry Andric Message-Id: <42284B22-BACD-47E7-A9E0-75B7AC5B6C9C@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_8B080E7B-5DB4-4131-BAFA-B20DADBF372F"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: btxld not found Date: Tue, 28 Jan 2020 19:11:37 +0100 In-Reply-To: <8B42F93A-7B9E-4F99-9D77-43DA3BB7F045@van-laarhoven.org> Cc: FreeBSD Current Mailing List To: Nick Hibma References: <8B42F93A-7B9E-4F99-9D77-43DA3BB7F045@van-laarhoven.org> X-Mailer: Apple Mail (2.3445.104.11) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 28 Jan 2020 18:11:46 -0000 --Apple-Mail=_8B080E7B-5DB4-4131-BAFA-B20DADBF372F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 28 Jan 2020, at 12:36, Nick Hibma wrote: >=20 > Could anyone explain to me what I am doing wrong? make installworld = fails each time with the following error >=20 > =3D=3D=3D> stand/i386/libi386 (install) > =3D=3D=3D> stand/i386/loader_4th (install) > strip -R .comment -R .note -o loader_4th.bin loader_4th.sym > btxld -v -f aout -e 0x200000 -o loader_4th -l = /usr/obj/usr/src/i386.i386/stand/i386/btx/btxldr/btxldr -b = /usr/obj/usr/src/i386.i386/stand/i386/btx/btx/btx loader_4th.bin > make[6]: exec(btxld) failed (No such file or directory) > *** Error code 1 >=20 > This is with source of last week. I had this problem before (from old = sources) and fixed it by specifying the full path to btxld in the = stand/i386/*/Makefile. Yes, this is most likely your clock(s) being off. At installworld time, it should *not* start rebuilding your loader. Usually this happens if you build on one machine, and install on another, while the install machine's time is behind the build machine's time. But it can also happens on one machine, for instance if you start in single user mode, and the clock is not yet synchronized. -Dimitry --Apple-Mail=_8B080E7B-5DB4-4131-BAFA-B20DADBF372F 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 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCXjB5WQAKCRCwXqMKLiCW o24AAKCKBQdnrRZOP4Qo2sftYI95Ey19ywCgnkullnbtbXrQFjfDzOfdELzlKkY= =Skd2 -----END PGP SIGNATURE----- --Apple-Mail=_8B080E7B-5DB4-4131-BAFA-B20DADBF372F-- From owner-freebsd-current@freebsd.org Tue Jan 28 19:28:23 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 64BE0239172 for ; Tue, 28 Jan 2020 19:28:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-55.consmr.mail.gq1.yahoo.com (sonic308-55.consmr.mail.gq1.yahoo.com [98.137.68.31]) (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 486c922YV4z4Qj0 for ; Tue, 28 Jan 2020 19:28:21 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: XwsVmHwVM1nI3sYXDIau3Y2Rp.vCgvBkpuEiE3itAffERb6VBVjTu6wILfYnhLW w8PcmEa.x1ORv.LoO0Xp_osQbhLBW7AWau1aleZr99godSeltbsBx42oUhkT5YNBQiLJjU_lmGp7 QVlEIeGwMflei4D7HFeBEAccpuVoERtWwVPTu7.Dkj5FLnkbqzeke0dKtONbHfAffVPCvTe6b7Nk IVvO4MlhM8jnVkx_299dG.gnwKfdBGDSgzY_qUv8FSOduZn1CxjjlZu_TP9U.UPzMEzB12TAfw7C LqG18g8Ge7baCh3WjXFmMVs8eY7phCXOzKc93AkhcHJsAkL_9l0kqvukGxmHI3Ts48b5Fbefxu0H YRUslCki1CBV5g6Y.G4nqTqMgMgefx6wTx7bUYLokffWWYiBUkTrTk_gCH9My5E5LgInMz8rN4MA rRwUfr0MTJRRjElzBLqs6l3O7oP5Oa7dJ.dCREAfByZgnG7MEUMuk25bC8HVfP781CkRFJ9kVFVU Uuq57acdlp31bD1xM8e58S4h4uhZe5Z6SGcw6vQtQwO2D4WhROpjh1X6Kp5yBI8VdB4qZkaM1WIh PxqNak2hoClaULckWwPp_KqrjSmY51.pKrM2RENGv6mw13vUIBMYWatcvaH0f5iMJEZXRUDmDLQQ OH8XVLtQ29.blgs_pP3EzzCAQ2eVNgCLSC35JesT9ZuQ9AcHGo_5FcOKg.iHhxWw7JdEWvaoThkt Jn693uFi5fDU9MRnKL1Arz5in6jB4lybPRuz03feKKDe2X60VLO.UoH1K5z1DlLxMZ6m7BafTlpq Zv.As.O_awSWjJg4RMAoW8XSezKoyVLD5lqWhREczJ6B9_PtsVk_EAmedWfPOlKisbCFb6eo3QO5 mPHm0OIdS3VGTJn51fPB0_71nWG8KUhcpvDQ.HWjlHyifDUDTeSwUEQTpvPxoAg6Zat9u1gVXoLl WmPCzrmpLEaj1I_emjC67jvIuJ3xL7KVGtaQwXpddT8..cNdC.yKa5GVZQXmlT41MFi4zWDqDNhT y41uG_RnzioXb6PXi2BmoKUv9MsqbNPUm2N2AgxCeDaDHaCFms97UtuVWiIWFOxUwhR7VnKRmXgl iCMuAZ40Og5eCPJgVh0LCx8IBD.7jMLVnNB_fm6STb_DbjtUs5TB7rd5ZbQKC2IxBv1vzQ25pWbw tQPkaBnZeeSNeFYmHR.o5xvw8omXrBjL98ng5bSEROYqU17nk94wBEDrctMSc2RGPmEXzZ13bQMP D_T397vxSI2.g8ANtbbKfWb802gfQUaeUCQy7OSXOVk_4q_wtPIRW8rNzEFjmsHq9o3v8Xd3xk7U 8HkEfx0sSxWFVYZPK7UwEUYPDZrfuxnYIzTRvq.lTcEH4fqH3xx8TqBvtGQkkpClEhAuvhXEJAzW D1y8MwZGVDhHykysSxz0wi7bBEw5HbxXt.blgB5aGir2IWFNv7njBshcSRIbGYjT7_2H9yw5tUBl 5HokQ27Q- Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Tue, 28 Jan 2020 19:28:19 +0000 Received: by smtp429.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID faf0b610faf7debc14864154abeefc8a; Tue, 28 Jan 2020 19:28:14 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Subject: Re: OOMA kill with vm.pfault_oom_attempts="-1" on RPi3 at r357147 (a vm_pfault_oom_attempts < 0 handling bug as of head -r357026) From: Mark Millard In-Reply-To: <20200128190210.GA14784@www.zefox.net> Date: Tue, 28 Jan 2020 11:28:14 -0800 Cc: freebsd-arm , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <94E68249-7751-4B27-AE95-E9C2776D730B@yahoo.com> References: <20200127190709.GA11328@www.zefox.net> <20200128035317.GA12644@www.zefox.net> <18150258-6210-451E-A5B9-528129A05974@yahoo.com> <9BF68EF1-F83A-473B-9A7B-B3956D6A5EFD@yahoo.com> <20200128170518.GA14654@www.zefox.net> <5A3CE2DA-C5B8-4CC1-BEEA-8B9649A20B8B@yahoo.com> <20200128190210.GA14784@www.zefox.net> To: bob prohaska , Konstantin Belousov X-Mailer: Apple Mail (2.3608.40.2.2.4) X-Rspamd-Queue-Id: 486c922YV4z4Qj0 X-Spamd-Bar: - X-Spamd-Result: default: False [-1.92 / 15.00]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.80)[-0.796,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-0.62)[-0.621,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (1.84), ipnet: 98.137.64.0/21(0.84), asn: 36647(0.67), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[31.68.137.98.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[31.68.137.98.rep.mailspike.net : 127.0.0.17]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 28 Jan 2020 19:28:23 -0000 On 2020-Jan-28, at 11:02, bob prohaska wrote: > On Tue, Jan 28, 2020 at 09:42:17AM -0800, Mark Millard wrote: >>=20 >>=20 >>=20 > The (partly)modified kernel compiled and booted without > obvious trouble. It's trying to finish buildworld now. >=20 >> If you are testing with vm.pfault_oom_attempts=3D"-1" then >> the vm_fault printf message should never happen anyway. >>=20 > Would it not be interesting if the message appeared in that > case?=20 Thanks for the question: looking at the new code found a bug causing oom where it used to be avoided in head -r357025 and before. After vm_waitpfault(dset, vm_pfault_oom_wait * hz) the -r357026 code does a vm_pageout_oom(VM_OOM_MEM_PF) no matter what, even when vm_pfault_oom_attempts < 0 || fs->oom < vm_pfault_oom_attempts : New code in head -r357026 ( nothing to avoid the vm_pageout_oom(VM_OOM_MEM_PF) for vm_pfault_oom_attempts < 0 || fs->oom < vm_pfault_oom_attempts ): if (fs->m =3D=3D NULL) { unlock_and_deallocate(fs); if (vm_pfault_oom_attempts < 0 || fs->oom < vm_pfault_oom_attempts) { fs->oom++; vm_waitpfault(dset, vm_pfault_oom_wait * hz); } if (bootverbose) printf( "proc %d (%s) failed to alloc page on fault, starting OOM\n", curproc->p_pid, curproc->p_comm); vm_pageout_oom(VM_OOM_MEM_PF); return (KERN_RESOURCE_SHORTAGE); } Old code in head -r357025 ( has the goto RetryFault_oom after vm_waitpfault(. . .), thereby avoiding the vm_pageout_oom(VM_OOM_MEM_PF) for vm_pfault_oom_attempts < 0 || fs->oom < vm_pfault_oom_attempts ) : if (fs.m =3D=3D NULL) { unlock_and_deallocate(&fs); if (vm_pfault_oom_attempts < 0 || oom < vm_pfault_oom_attempts) { oom++; vm_waitpfault(dset, vm_pfault_oom_wait * hz); goto RetryFault_oom; } if (bootverbose) printf( "proc %d (%s) failed to alloc page on fault, starting OOM\n", curproc->p_pid, = curproc->p_comm); vm_pageout_oom(VM_OOM_MEM_PF); goto RetryFault; } I expect this is the source of the behavioral difference folks have been seeing for OOM kills. As for "gather evidence" messages . . . >> You may be able to just look and manually delete or >> comment out the bootverbose line in the more modern >> source that currently looks like: >>=20 >> if (bootverbose) >> printf( >> "proc %d (%s) failed to alloc page on fault, starting OOM\n", >> curproc->p_pid, curproc->p_comm); >> vm_pageout_oom(VM_OOM_MEM_PF); >> return (KERN_RESOURCE_SHORTAGE); >>=20 >=20 > I can find those lines in /usr/src/sys/vm/vm_fault.c, but > unclear on the motivation to comment the lines out. Perhaps=20 > to eliminate the return(...) ? Anyway, is it sufficient=20 > to insert /* before and */ after?=20 The only line to delete or comment out in that code block is: if (bootverbose) Disabling that line makes the following printf always happen, even when a verbose boot was not done. Based on the above reported code change, having a message before vm_pageout_oom(VM_OOM_MEM_PF) is important to getting a report of the kill being via that code. >> and is now in vm_fault_allocate(. . .). (That file has >> hd a reorganization since where I'm synchronized.) >>=20 >> Having the message indicate vm_fault_allocate is >> optional but would look like: >>=20 >> "vm_fault_allocate: proc %d (%s) failed to alloc page on fault, = starting OOM\n", >>=20 >> Doing the delete/comment-out would avoid waiting for me. >>=20 >>=20 > I'll do it after the next stoppage. =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 Jan 28 19:33:45 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 33B942396DD for ; Tue, 28 Jan 2020 19:33:45 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [IPv6:2001:678:618::40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "plan-b.pwste.edu.pl", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 486cHC5Y2wz4RDX for ; Tue, 28 Jan 2020 19:33:43 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from fomalhaut.potoki.eu ([IPv6:2001:470:71:d47:5a5:b77c:8c04:e45d]) (authenticated bits=0) by plan-b.pwste.edu.pl (8.15.2/8.15.2) with ESMTPSA id 00SJXcdU009059 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 28 Jan 2020 20:33:38 +0100 (CET) (envelope-from zarychtam@plan-b.pwste.edu.pl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plan-b.pwste.edu.pl; s=plan-b-mailer; t=1580240019; bh=W/yxgEgzWZNiyIrw1rting2x4r1SqGdyccDWOFmRJ5U=; h=To:References:From:Subject:Date:In-Reply-To; b=QqKxi+iqeJCQ3ewxSOLfZPDeFXsMv8X9TmeIscdD/nYyx/eXBx8GSh4qBX4t8TqqQ LnCOXtrR8EiN4b9VPSfMb/jsKELlTZcyKpCKuPhOIo2pKrAOWorFc0nzjefMBQmVHs RvRsHwx1xm4lww7Ith6L73ADqm2J2p89N3QFkhMUgYi2Nzi8gcSd303Vr9O1pmX5ao s4TnbIR3SAoWubxyDY3iz9dQh4OP2SeBG8JdfGwcm5Bx+KDtS7N19+1MEGFgeJmJ2A tvWbAC6T0HpRhGxRfN3vxUn9/4YG6EyClC2z+BPCoW559CILvOIUPjD4Gm4+wzAAzJ 4saukw2HCqjHA== X-Authentication-Warning: plan-b.pwste.edu.pl: Host [IPv6:2001:470:71:d47:5a5:b77c:8c04:e45d] claimed to be fomalhaut.potoki.eu To: freebsd-current@freebsd.org References: <8B42F93A-7B9E-4F99-9D77-43DA3BB7F045@van-laarhoven.org> <42284B22-BACD-47E7-A9E0-75B7AC5B6C9C@FreeBSD.org> From: Marek Zarychta Autocrypt: addr=zarychtam@plan-b.pwste.edu.pl; prefer-encrypt=mutual; keydata= mQENBFfi3cMBCADLecMTFXad4uDXqv3eRuB4qJJ8G9tzzFezeRnnwxOsPdytW5ES2z1ibSrR IsiImx6+PTqrAmXpTInxAi7yiZGdSiONRI4CCxKY9d1YFiNYT/2WyNXCekm9x29YeIU7x0JB Llbz0f/9HC+styBIu2H+PY/X98Clzm110CS+n/b9l1AtiGxTiVFj7/uavYAKxH6LNWnbkuc5 v8EVNc7NkEcl5h7Z9X5NEtzDxTOiBIFQ/kOT7LAtkYUPo1lqLeOM2DtWSXTXQgXl0zJI4iP1 OAu4qQYm2nXwq4b2AH9peknelvnt1mpfgDCGSKnhc26q6ibTfMwydp+tvUtQIQYpA6b9ABEB AAG0N01hcmVrIFphcnljaHRhIChQbGFuLWIpIDx6YXJ5Y2h0YW1AcGxhbi1iLnB3c3RlLmVk dS5wbD6JATcEEwEIACEFAlfi4LkCGwMFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQHZW8 vIFppoJXdgf8D9X3VRFSNaR9lthSx/+uqas17J3FJKBo1xMQsC2a+44vzNvYJSuPGLLJ+LW2 HPVazjP/BWZJbxOYpliY4zxNRU0YCp0BLIVLibc//yax+mE42FND/+NiIZhqJscl6MLPrSwo sIwXec4XYkldkyqW/xBbBYXoIkBqdKB9j5j42Npy1IV/RizOSdmvTWY27ir8e/yGMR1RLr4F 8P5K3OWTdlGy2H2F/3J8bIPBLG6FpaIyLQw4dHSx8V02PYqDxK1cNo2kAOnU8PnZL/AGuMOH iv3MN1VYL8ehcmpBBsrZGebQJxrjY2/5IaTSgp9xHYT70kshuU6Qb97vk1mOjNZxgbkBDQRX 4t3DAQgA10h6RCXuBLMHxq5B8X/ZIlj9sgLoeyfRdDZEc9rT2KUeUJVHDsbvOFf4/7F1ovWY hJbA6GK/LUZeHHTjnbZcH1uDYQeHly4UOLxeEvhGoz4JhS2C7JzN/uRnwbdOAUbJr8rUj/IY a7gk906rktsc/Ldrxrxh7O6WO0JCh2XO/p4pDfEwwB37g4xHprSab28ECYJ9JMbtA8Sy4M55 g3+GQ28FvSlGnx48OoGXU2BZdc1vZKSQmNOlikB+9/hDX8zdYWVfDaX1TLQ8Ib4+xTUmapza mV/bxIsaZRBw+jFjLQHhTbIMfPEU+4mxFDvTdbKPruKPqVf1ydgMnPZWngowdwARAQABiQEf BBgBCAAJBQJX4t3DAhsMAAoJEB2VvLyBaaaC6qkIAJs9sDPqrqW0bYoRfzY6XjDWQ59p9tJi v8aogxacQNCfAu+WkJ8PNVUtC1dlVcG5NnZ80gXzd1rc8ueIvXlvdanUt/jZd8jbb3gaDbK3 wh1yMCGBl/1fOJTyEGYv1CRojv97KK89KP5+r8x1P1iHcSrunlDNqGxTMydNCwBH23QcOM+m u4spKnJ/s0VRBkw3xoKBZfZza6fTQ4gTpAipjyk7ldOGBV+PvkKATdhK2yLwuWXhKbg/GRlD 1r5P0gxzSqfV4My+KJuc2EDcrqp1y0wOpE1m9iZqCcd0fup5f7HDsYlLWshr7NQl28f6+fQb sylq/j672BHXsdeqf/Ip9V65AQ0EV+OTdwEIAMxnGg7OO/ZAnSwiIiABA9lil1Lfa5BWTH3c l1rz4slz7Gw99G9J3bX3FiPA0vU89dgBZ2k0/UVk5cI5EsMAvwJN4bPwRsfBELQqjCKkVZr4 vUeGyvgQ2jnoK1fcEFOnCRdwFy4EJ6Y/fsZCTj4IfQpkM1W7C3KuSGPcjPDA9XCLDjjp8bbA Q9VgQ68MntAnYxMqK0S3CrHp5Pruvb0x4MfFLNwaKtWK+UnJGPT4umj8PMP6XLsFC3g+SGoP aWoYRDI297ZGx4IBWEaJq181oEC5iUQ6WREti9fNQ3TsAB3Q2CjNlkx1geSczIFJSyOHmyJZ RqAocw1sIuPopvhWtR0AEQEAAYkCRAQYAQgADwUCV+OTdwIbAgUJCWYBgAEpCRAdlby8gWmm gsBdIAQZAQgABgUCV+OTdwAKCRB1n+z//VKNLOETCAC3ggwAAQij4hkIxQFapnRuIVb5vq7D AwJ9+Ld5/zYHOj2Tfu+BPSNGzI2edqboz2w1t55UHEYzYDp2axxIfPrZrXsBV4DsjtGwzVV/ jZ9or5qTaYFDEStRkzL4mRpTyYhl/T7GgWpwOJWOih+cU7RWzjSOxiYMi4QSYlkpDUCcZew0 C3HfcxeFqpeL46zgysHC2ptjINXQ+xR2/F6dbed+l7OsvJAfkBqJoQ/48m+8ly1lbViKck7q gWw143ljaKn2qGIjZdb95zcI/CP4L45SXq8NOweACdx2NfUphLrIMbNCqLkMUJcrnruKfbnp C8OMjFJIqlu+PsW593NcZyOugEAH/0cBsDxlSauSVK4kp8ald26pcBI6igNnIMgjaxMiZBjn eoxBiKAOAO93sPnPr9/64CMMwv1T+0vU2lj8SMKOdHVrB9sW/ICGji5skE85xPEAtUkdAQN+ +c2clotujcaj9lBZKJdncKmSxY0SshEa66H+s76u+2Q3jGK6vOrdxakWYCvh2P0/l52Nd/t2 eazLFgwtk5rbo7O0MSC1GNXUsG07vtZ+zxJXFRx7PQ3ZIn0Y4HqwvXUvqgZ9EHiKy8F+ondz 9IS8/Fs81N5ieujHhSWqbaibapnpeDHvT/FWf8iXfJqWq+F7C8lGShSkmsS5AOhB4TNNH5/m ZzECJa1ql64= Subject: Re: btxld not found Message-ID: Date: Tue, 28 Jan 2020 20:33:26 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.3.0 MIME-Version: 1.0 In-Reply-To: <42284B22-BACD-47E7-A9E0-75B7AC5B6C9C@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="GMnOzVCJZlq2EZQPpoy853M85weFVUG9K" X-Rspamd-Queue-Id: 486cHC5Y2wz4RDX X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=plan-b.pwste.edu.pl header.s=plan-b-mailer header.b=QqKxi+iq; dmarc=pass (policy=none) header.from=pwste.edu.pl; spf=none (mx1.freebsd.org: domain of zarychtam@plan-b.pwste.edu.pl has no SPF policy when checking 2001:678:618::40) smtp.mailfrom=zarychtam@plan-b.pwste.edu.pl X-Spamd-Result: default: False [-4.49 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[plan-b.pwste.edu.pl:s=plan-b-mailer]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[pwste.edu.pl.dwl.dnswl.org : 127.0.11.0]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; HAS_ATTACHMENT(0.00)[]; HAS_XAW(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[plan-b.pwste.edu.pl:+]; DMARC_POLICY_ALLOW(-0.50)[pwste.edu.pl,none]; R_SPF_NA(0.00)[]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; IP_SCORE(0.41)[asn: 206006(1.98), country: PL(0.07)]; ASN(0.00)[asn:206006, ipnet:2001:678:618::/48, country:PL]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 28 Jan 2020 19:33:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GMnOzVCJZlq2EZQPpoy853M85weFVUG9K Content-Type: multipart/mixed; boundary="BvXGB2juGdVPVwX5Qccua9qAsefbP6PBJ"; protected-headers="v1" From: Marek Zarychta To: freebsd-current@freebsd.org Message-ID: Subject: Re: btxld not found References: <8B42F93A-7B9E-4F99-9D77-43DA3BB7F045@van-laarhoven.org> <42284B22-BACD-47E7-A9E0-75B7AC5B6C9C@FreeBSD.org> In-Reply-To: <42284B22-BACD-47E7-A9E0-75B7AC5B6C9C@FreeBSD.org> --BvXGB2juGdVPVwX5Qccua9qAsefbP6PBJ Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: quoted-printable W dniu 28.01.2020 o=A019:11, Dimitry Andric pisze: > On 28 Jan 2020, at 12:36, Nick Hibma wrote: >> >> Could anyone explain to me what I am doing wrong? make installworld fa= ils each time with the following error >> >> =3D=3D=3D> stand/i386/libi386 (install) >> =3D=3D=3D> stand/i386/loader_4th (install) >> strip -R .comment -R .note -o loader_4th.bin loader_4th.sym >> btxld -v -f aout -e 0x200000 -o loader_4th -l /usr/obj/usr/src/i386.i3= 86/stand/i386/btx/btxldr/btxldr -b /usr/obj/usr/src/i386.i386/stand/i386= /btx/btx/btx loader_4th.bin >> make[6]: exec(btxld) failed (No such file or directory) >> *** Error code 1 >> >> This is with source of last week. I had this problem before (from old = sources) and fixed it by specifying the full path to btxld in the stand/i= 386/*/Makefile. >=20 > Yes, this is most likely your clock(s) being off. At installworld time= , > it should *not* start rebuilding your loader. >=20 > Usually this happens if you build on one machine, and install on > another, while the install machine's time is behind the build machine's= > time. But it can also happens on one machine, for instance if you > start in single user mode, and the clock is not yet synchronized. >=20 > -Dimitry >=20 I build and install on the same machine, WITH_META_MODE=3Dyes the CPU is Origin=3D"AuthenticAMD" Id=3D0x100f43 Family=3D0x10 Model=3D0x4 Stepp= ing=3D3, underlining filesystem is ZFS, OBJDIR is /usr/obj though it's really /usr/amdfam10obj.head mounted with nullfs. For build/install I am using still these old way commands: make -sj4 buildworld && make installworld On the same machine I am building/installing 12-STABLE world as well, but this error is only present for CURRENT. It has appeared for the first time in early October last year and remains unresolved to me. I just ignore errors on installworld since then. =3D=3D=3D> stand/i386/btx (install) =3D=3D=3D> stand/i386/btx/btx (install) =3D=3D=3D> stand/i386/btx/btxldr (install) =3D=3D=3D> stand/i386/btx/lib (install) =3D=3D=3D> stand/i386/boot2 (install) btxld -v -E 0x2000 -f bin -b /usr/obj/usr/src/amd64.amd64/stand/i386/btx/btx/btx -l boot2.ldr -o boot2.ld -P 1 boot2.bin make[6]: exec(btxld) failed (No such file or directory) *** Error code 1 --=20 Marek Zarychta --BvXGB2juGdVPVwX5Qccua9qAsefbP6PBJ-- --GMnOzVCJZlq2EZQPpoy853M85weFVUG9K Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEMOqvKm6wKvS1/ZeCdZ/s//1SjSwFAl4wjJIACgkQdZ/s//1S jSyDvwf/bjOPE0wcyISg6yn82zZpGtBZJv1SclpFo+NwHkqfrzwRHLIqLr2Y3u+u NIIEv3Kh2294xfUNxWBRfYqS0OXkxoQSAhdpI6AkHTBVRyF9g8hXx0jOROQJukJT Ro6Moik/INPK96122TK9oSv+cU45ThAdaPMJCL3xxElmpVq7itS17DHERMwNEi5j MS1Jmj0FjAp5nqvSOcQaZMtHDvnpIXvd4tm1IH3btQ++kvxTizWXxRnwOvnzj5Zt mbLXsKjOyxJKB1O/Av2PcmYXGi3Yh4O4wfrpp3lcEAj39JNCGQCXBJO4rfWgfVu1 +5Pz/yCxtGcRSY1ccUZLRbCgi8lrrg== =0K/l -----END PGP SIGNATURE----- --GMnOzVCJZlq2EZQPpoy853M85weFVUG9K-- From owner-freebsd-current@freebsd.org Tue Jan 28 19:34:00 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A0DF0239746 for ; Tue, 28 Jan 2020 19:34:00 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 486cHW4Rqsz4RKS for ; Tue, 28 Jan 2020 19:33:59 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id wWcUi7AwLnCigwWcWigSVy; Tue, 28 Jan 2020 12:33:57 -0700 X-Authority-Analysis: v=2.3 cv=cZisUULM c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10 a=Jdjhy38mL1oA:10 a=CjxXgO3LAAAA:8 a=YxBL1-UpAAAA:8 a=YVOhz5M6AAAA:8 a=6I5d2MoRAAAA:8 a=btI72j7jPLSCBgcFqRgA:9 a=hcfIkKsiUbtcD7XP:21 a=y-KIT5yIWAFQ5dkf:21 a=QEXdDO2ut3YA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=sbbTL3E6IKcx-RquDtO-:22 a=IjZwj45LgO3ly-622nXo:22 Received: from [IPv6:2605:8d80:401:570e:65af:2990:87df:6dc2] (unknown [72.143.222.28]) by spqr.komquats.com (Postfix) with ESMTPSA id CE07773C; Tue, 28 Jan 2020 11:33:53 -0800 (PST) Date: Tue, 28 Jan 2020 11:33:30 -0800 User-Agent: K-9 Mail for Android In-Reply-To: References: <202001261745.00QHjkuW044006@gndrsh.dnsmgr.net> <202001271309.00RD96nr005876@slippy.cwsent.com> <202001272048.00RKmiZs006726@slippy.cwsent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: After update to r357104 build of poudriere jail fails with 'out of swap space' To: Mark Millard CC: "Rodney W. Grimes" , sgk@troutmask.apl.washington.edu, freebsd-current@freebsd.org, yasu@utahime.org From: Cy Schubert Message-ID: <4682F012-E3C5-4B49-8099-659EBCB7B585@cschubert.com> X-CMAE-Envelope: MS4wfH6qY8lRCa/fnEIo4O8Tb9sIdHkQogxA1X5UdtCy9/uUIoFaHLAv981fvkAJSm94wRtLexUJA5Hg/xd0bq1VWofJgczFmY4U18L/KJzVFw/VFheYCWo4 LnZSPVp+1pR0GPt6t3tnr25e77os0KTKDM7pTc1lw9PaRO0MpGkP9mxO5/ebsTX2KEHqH2NKUqE7f7wWjVWZznpFXkUjTMFE5BSINON6hSw6OxwpraG/zt1F VMwhs2ezFu3WFV8Va3+KMePtHOPRRLVp7IoLh1bgNKBMpjfW7Pvam7a/NjieQgnYqR79avvVmgJJ7A3zPa0fDScLw5HQmLtNSe+HCePTyX4= X-Rspamd-Queue-Id: 486cHW4Rqsz4RKS X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 64.59.134.13) smtp.mailfrom=cy.schubert@cschubert.com X-Spamd-Result: default: False [-4.66 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[28.222.143.72.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11,17.125.67.70.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[]; FREEMAIL_TO(0.00)[yahoo.com]; RCVD_IN_DNSWL_LOW(-0.10)[13.134.59.64.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(-2.46)[ip: (-6.54), ipnet: 64.59.128.0/20(-3.18), asn: 6327(-2.48), country: CA(-0.09)]; FROM_EQ_ENVFROM(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 28 Jan 2020 19:34:00 -0000 On January 27, 2020 2:25:59 PM PST, Mark Millard wrot= e: > > >On 2020-Jan-27, at 12:48, Cy Schubert >wrote: > >> In message , Mark >Millard=20 >> write >> s: >>>=20 >>>=20 >>>=20 >>> On 2020-Jan-27, at 10:20, Cy Schubert >wrote: >>>=20 >>>> On January 27, 2020 5:09:06 AM PST, Cy Schubert > >>> wrote: >>>>>> =2E =2E =2E=20 >>>>>=20 >>>>> Setting a lower arc_max at boot is unlikely to help=2E Rust was >building >>>>> on=20 >>>>> the 8 GB and 5 GB 4 core machines last night=2E It completed >successfully >>>>> on=20 >>>>> the 8 GB machine, while using 12 MB of swap=2E ARC was at 1307 MB=2E >>>>>=20 >>>>> On the 5 GB 4 core machine the rust build died of OOM=2E 328 KB swap >was=20 >>>>> used=2E ARC was reported at 941 MB=2E arc_min on this machine is 489= =2E2 >MB=2E >>>>=20 >>>> MAKE_JOBS_NUMBER=3D3 worked building rust on the 5 GB 4 core >machine=2E ARC is >>> at 534 MB with 12 MB swap used=2E >>>=20 >>> If you increase vm=2Epageout_oom_seq to, say, 10 times what you now >use, >>> does MAKE_JOBS_NUMBER=3D4 complete --or at least go notably longer >before >>> getting OOM behavior from the system? (The default is 12 last I >checked=2E >>> So that might be what you are now using=2E) >>=20 >> It's already 4096 (default is 12)=2E > >Wow=2E Then the count of tries to get free RAM above the threshold >does not seem likely to be the source of the OOM kills=2E > >>>=20 >>> Have you tried also having: vm=2Epfault_oom_attempts=3D"-1" (Presuming >>> you are not worried about actually running out of swap/page space, >>> or can tolerate a deadlock if it does run out=2E) This setting >presumes >>> head, not release or stable=2E (Last I checked anyway=2E) >>=20 >> Already there=2E > >Then page-out delay does not seem likely to be the source of the OOM >kills=2E > >> The box is a sandbox with remote serial console access so deadlocks >are ok=2E >>=20 >>>=20 >>> It would be interesting to know what difference those two settings >>> together might make for your context: it seems to be a good context >>> for testing in this area=2E (But you might already have set them=2E >>> If so, it would be good to report the figures in use=2E) >>>=20 >>> Of course, my experiment ideas need not be your actions=2E >>=20 >> It's a sandbox machine=2E We already know 8 GB works with 4 threads on >as=20 >> many cores=2E And, 5 GB works with 3 threads on 4 cores=2E > >It would be nice to find out what category of issue in the kernel >is driving the OOM kills for your 5GB context with MAKE_JOBS_NUMBER=3D4= =2E >Too bad the first kill does not report a backtrace spanning the >code choosing to do the kill (or otherwise report the type of issue >leading the the kill)=2E > >Your is consistent with the small arm board folks reporting that >recently >contexts that were doing buildworld and the like fine under somewhat >older kernels have started getting OOM kills, despite the two settings=2E > >At the moment I'm not sure how to find the category(s) of issue(s) that >is(are) driving these OOM kills=2E > >Thanks for reporting what settings you were using=2E > >=3D=3D=3D >Mark Millard >marklmi at yahoo=2Ecom >( dsl-only=2Enet went >away in early 2018-Mar) I've been able to reproduce the problem at $JOB in a Virtualbox VM with 1 = vCPU, 1=2E5 GB vRAM, and 2 GB swap building graphics/graphviz: cc killed ou= t of swap space=2E The killed cc had an address space of ~ 500 MB, using on= ly 43 MB of the 2 GB swap=2E Free space is exhausted but swap used never ex= ceeds tens of MB=2E Doubling the swap to 4 GB had no effect=2E The VM doesn= 't use ZFS=2E This appears recent=2E --=20 Pardon the typos and autocorrect, small keyboard in use=2E=20 Cy Schubert FreeBSD UNIX: Web: https://www=2EFreeBSD=2Eorg The need of the many outweighs the greed of the few=2E Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E From owner-freebsd-current@freebsd.org Tue Jan 28 19:49:04 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0FAA523A0FC for ; Tue, 28 Jan 2020 19:49:04 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-24.consmr.mail.gq1.yahoo.com (sonic312-24.consmr.mail.gq1.yahoo.com [98.137.69.205]) (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 486cct497Wz4SC0 for ; Tue, 28 Jan 2020 19:49:02 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: CplGSl8VM1laD9n.E3F.9VA0RPkFc8vcVYCr_WPKBA2mZ6peK_IBjn8an9dwii2 3ba0IGwkQOepi0Xh6p11hslDuY3nNmN1SFymlohTD7aGa6y4HSzFyYSBFDUG9zqBlw0TPVPSzUlS ihsEwuIJ2dvWbVqZlf9nUy5yvGznj8dPAQWLTIiK1X6Taxd2ZfTi6ImdpcIuDMvLnDrVrwfxlBkW MPoNzaUzKjj9FXZoAPswhvcaWOLmgeauP9xJe8TATdQ4W4TCIa4aTfXxzW1FTW8UA1HANi26Jsez 75vITpEmo4z9FzgvBEekjYd.xgsRERMps7jTw.mc2u5sOlmYLtcBWrheokMk7I0inNU2WbiZ0Qcq h9V8UAM74OxSGt10s_BsvcltJ.aoMYFEQPzlh7T5XVTz6md2_w4tOgpoE.6EXa1Dyo7g9F8ALEV0 VCp3NM8JSgHQf66i0pzkYXNI6snzYmpljtM2D43mRninnyUbxqSae51eI9cbSC5VfeDJ2hV_0gWs lZzCYeu0KmiM2WT7ePXbyWbJluAHg3yuzEP2RGSAkQ8XAtEE_exrMAWcIAgDLlH._Z1rGzvAAsZk 7.7SvxqcRXWPMAMp7nyb4Djnrs3z..DDjpXQUFJ0R0gkextAPQpQpxxyKGM2s3MGZBqkesI.38V8 iFtwjNDjssEb272OYji5Mo0ys1GHTCmg8s8marV8en6mT1nkO05rr2edDBEKtVBeJfpemRuvLyNI Vee7Yp6YCorsMcvCvaXG4JdEcg3_442AK7rzdovFUP7U9L_0z9IVQWW9SCqbsSe.Zv7xkHZOAZ6L Ls_md3Y9RlNvzEUod2bEsree9l2WZJFGRHk_FtV00RhqEMacEGVckGgR4OiIhlgtY9u2HeupIsBU ACvaFAvmDpdUrxM.Mw_9EgJgabGFFhe_34w2tZP6m7uBDCp1jz8k7W.EFWlcxm9uLfCyH_GjJXJ2 NyHhkUBYso8PgO1LdKcmQEUMDRvvwyt6.j8qIEpkhuQY16XwIziBC8ZNpKeurXHuSXWTCK5yWQyx N7DHsWdpwgsb2ItvWg9JhqkSQmSHzICxgnBWASsZb_SwpbP_zf.hLIFzTPNjhvZ2LDUh7wWkKP0n H4P5M5dtT_XsVeN7E3zsHf.a7J2e_PK.pS4tOEGvL_eDcB.0t_gXS7uFmegh5.O7kKxP2Se8f.Y2 5cCyQ6KHAg1ZhV6uUfAHAqVB39jxdBoXzyUncxzFAgBeiAE_YaE7FWo.yB3D2StqO4veUbFJHx31 dSiMYOj8stxgn0iR.UsPT2sKmd2vFNB9r8FydvqfTXrYMj8xDf8QLhU4F3qk7SHVcoIa6275A.AM jYHFXM5RJBYh5f7QkfIBdXMVDBt0TMIAAcR963JOQnJPeenu9J_u9CIgl1pRO13YwWq7ub6JATgv JAW4zGBU.5wiRr8wLuZmJ.F1CS1NrKa0fs2DmuPJl Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Tue, 28 Jan 2020 19:49:00 +0000 Received: by smtp401.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID dfd6d62b23afd33023b5f2eba22ea6e5; Tue, 28 Jan 2020 19:48:56 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Subject: Re: After update to r357104 build of poudriere jail fails with 'out of swap space' From: Mark Millard In-Reply-To: <4682F012-E3C5-4B49-8099-659EBCB7B585@cschubert.com> Date: Tue, 28 Jan 2020 11:48:55 -0800 Cc: "Rodney W. Grimes" , sgk@troutmask.apl.washington.edu, freebsd-current@freebsd.org, yasu@utahime.org Content-Transfer-Encoding: quoted-printable Message-Id: <235BECA5-0086-48DF-90F8-3AC24CA86DA3@yahoo.com> References: <202001261745.00QHjkuW044006@gndrsh.dnsmgr.net> <202001271309.00RD96nr005876@slippy.cwsent.com> <202001272048.00RKmiZs006726@slippy.cwsent.com> <4682F012-E3C5-4B49-8099-659EBCB7B585@cschubert.com> To: Cy Schubert X-Mailer: Apple Mail (2.3608.40.2.2.4) X-Rspamd-Queue-Id: 486cct497Wz4SC0 X-Spamd-Bar: / X-Spamd-Result: default: False [-0.79 / 15.00]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; RCPT_COUNT_FIVE(0.00)[5]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.44)[-0.437,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (3.63), ipnet: 98.137.64.0/21(0.84), asn: 36647(0.67), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.15)[0.148,0]; RCVD_IN_DNSWL_NONE(0.00)[205.69.137.98.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[205.69.137.98.rep.mailspike.net : 127.0.0.17]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 28 Jan 2020 19:49:04 -0000 On 2020-Jan-28, at 11:33, Cy Schubert = wrote: > On January 27, 2020 2:25:59 PM PST, Mark Millard = wrote: >> . . . >>=20 >> It would be nice to find out what category of issue in the kernel >> is driving the OOM kills for your 5GB context with = MAKE_JOBS_NUMBER=3D4. >> Too bad the first kill does not report a backtrace spanning the >> code choosing to do the kill (or otherwise report the type of issue >> leading the the kill). >>=20 >> Your is consistent with the small arm board folks reporting that >> recently >> contexts that were doing buildworld and the like fine under somewhat >> older kernels have started getting OOM kills, despite the two = settings. >>=20 >> At the moment I'm not sure how to find the category(s) of issue(s) = that >> is(are) driving these OOM kills. >>=20 >> Thanks for reporting what settings you were using. >>=20 >> . . . >=20 > I've been able to reproduce the problem at $JOB in a Virtualbox VM = with 1 vCPU, 1.5 GB vRAM, and 2 GB swap building graphics/graphviz: cc = killed out of swap space. The killed cc had an address space of ~ 500 = MB, using only 43 MB of the 2 GB swap. Free space is exhausted but swap = used never exceeds tens of MB. Doubling the swap to 4 GB had no effect. = The VM doesn't use ZFS. >=20 > This appears recent. >=20 head -r357026 turned some code that previously avoided vm_pageout_oom(VM_OOM_MEM_PF) into code that always does it for the conditions that should avoid the call. In part, this disabled what we were doing vm.pfault_oom_attempts=3D"-1" for: that case now always kills. Head -r357025 is the last version to avoid the call (until this is fixed). =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 Jan 28 20:11:48 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5C7C123B22B; Tue, 28 Jan 2020 20:11:48 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 486d763cc6z4Tnd; Tue, 28 Jan 2020 20:11:46 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id 00SKBrDa015170 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 28 Jan 2020 12:11:54 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id 00SKBrxN015169; Tue, 28 Jan 2020 12:11:53 -0800 (PST) (envelope-from fbsd) Date: Tue, 28 Jan 2020 12:11:53 -0800 From: bob prohaska To: Mark Millard Cc: Konstantin Belousov , freebsd-arm , FreeBSD Current , bob prohaska Subject: Re: OOMA kill with vm.pfault_oom_attempts="-1" on RPi3 at r357147 (a vm_pfault_oom_attempts < 0 handling bug as of head -r357026) Message-ID: <20200128201152.GA15110@www.zefox.net> References: <20200127190709.GA11328@www.zefox.net> <20200128035317.GA12644@www.zefox.net> <18150258-6210-451E-A5B9-528129A05974@yahoo.com> <9BF68EF1-F83A-473B-9A7B-B3956D6A5EFD@yahoo.com> <20200128170518.GA14654@www.zefox.net> <5A3CE2DA-C5B8-4CC1-BEEA-8B9649A20B8B@yahoo.com> <20200128190210.GA14784@www.zefox.net> <94E68249-7751-4B27-AE95-E9C2776D730B@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <94E68249-7751-4B27-AE95-E9C2776D730B@yahoo.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-Rspamd-Queue-Id: 486d763cc6z4Tnd X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net X-Spamd-Result: default: False [3.69 / 15.00]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; IP_SCORE(0.06)[ip: (0.27), ipnet: 50.1.16.0/20(0.13), asn: 7065(-0.04), country: US(-0.05)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.75)[0.751,0]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_SPAM_LONG(0.98)[0.978,0]; R_SPF_NA(0.00)[]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; MID_RHS_WWW(0.50)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 28 Jan 2020 20:11:48 -0000 On Tue, Jan 28, 2020 at 11:28:14AM -0800, Mark Millard wrote: > > > On 2020-Jan-28, at 11:02, bob prohaska wrote: > > > On Tue, Jan 28, 2020 at 09:42:17AM -0800, Mark Millard wrote: > >> > >> > >> > > The (partly)modified kernel compiled and booted without > > obvious trouble. It's trying to finish buildworld now. > > Stopped already, with Jan 28 11:41:59 www kernel: pid 29909 (cc), jid 0, uid 0, was killed: fault's page allocation failed > >> If you are testing with vm.pfault_oom_attempts="-1" then > >> the vm_fault printf message should never happen anyway. > >> > > Would it not be interesting if the message appeared in that > > case? > > Thanks for the question: looking at the new code found a bug > causing oom where it used to be avoided in head -r357025 and > before. Glad to be of service, even if inadvertently 8-) > After vm_waitpfault(dset, vm_pfault_oom_wait * hz) > the -r357026 code does a vm_pageout_oom(VM_OOM_MEM_PF) no > matter what, even when vm_pfault_oom_attempts < 0 || > fs->oom < vm_pfault_oom_attempts : > > New code in head -r357026 > ( nothing to avoid the vm_pageout_oom(VM_OOM_MEM_PF) > for vm_pfault_oom_attempts < 0 || > fs->oom < vm_pfault_oom_attempts ): > > if (fs->m == NULL) { > unlock_and_deallocate(fs); > if (vm_pfault_oom_attempts < 0 || > fs->oom < vm_pfault_oom_attempts) { > fs->oom++; > vm_waitpfault(dset, vm_pfault_oom_wait * hz); > } > if (bootverbose) > printf( > "proc %d (%s) failed to alloc page on fault, starting OOM\n", > curproc->p_pid, curproc->p_comm); > vm_pageout_oom(VM_OOM_MEM_PF); > return (KERN_RESOURCE_SHORTAGE); > } > > Old code in head -r357025 > ( has the goto RetryFault_oom after vm_waitpfault(. . .), > thereby avoiding the vm_pageout_oom(VM_OOM_MEM_PF) for > vm_pfault_oom_attempts < 0 || fs->oom < vm_pfault_oom_attempts ) : > > if (fs.m == NULL) { > unlock_and_deallocate(&fs); > if (vm_pfault_oom_attempts < 0 || > oom < vm_pfault_oom_attempts) { > oom++; > vm_waitpfault(dset, > vm_pfault_oom_wait * hz); > goto RetryFault_oom; > } > if (bootverbose) > printf( > "proc %d (%s) failed to alloc page on fault, starting OOM\n", > curproc->p_pid, curproc->p_comm); > vm_pageout_oom(VM_OOM_MEM_PF); > goto RetryFault; > } > > I expect this is the source of the behavioral > difference folks have been seeing for OOM kills. > > > As for "gather evidence" messages . . . > > >> You may be able to just look and manually delete or > >> comment out the bootverbose line in the more modern > >> source that currently looks like: > >> > >> if (bootverbose) > >> printf( > >> "proc %d (%s) failed to alloc page on fault, starting OOM\n", > >> curproc->p_pid, curproc->p_comm); > >> vm_pageout_oom(VM_OOM_MEM_PF); > >> return (KERN_RESOURCE_SHORTAGE); > >> > > > > I can find those lines in /usr/src/sys/vm/vm_fault.c, but > > unclear on the motivation to comment the lines out. Perhaps > > to eliminate the return(...) ? Anyway, is it sufficient > > to insert /* before and */ after? > > The only line to delete or comment out in that > code block is: > > if (bootverbose) > > Disabling that line makes the following printf > always happen, even when a verbose boot was not > done. Oops, it's commented out now and the kernel is rebuilding. > > Based on the above reported code change, having > a message before vm_pageout_oom(VM_OOM_MEM_PF) is > important to getting a report of the kill being > via that code. > Thank you! bob prohaska From owner-freebsd-current@freebsd.org Tue Jan 28 20:14:54 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 431E623B5C1 for ; Tue, 28 Jan 2020 20:14:54 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-24.consmr.mail.gq1.yahoo.com (sonic311-24.consmr.mail.gq1.yahoo.com [98.137.65.205]) (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 486dBh63LGz4VDk for ; Tue, 28 Jan 2020 20:14:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: sF6k.LAVM1ngiPJ8orm_5eJ3f7Bnmk4p7kn3KokcCDN_YXAZuH6IAjkSS4shuH2 HU.c1huqhr2.hsBTKBypIKXmW0.HwmmmdKcfv4zsvyEHMC24mgnMJSN.lkYFu.mHm6jJ.mN2WmP8 72qjNaNwchmG0cg_hzRSMNKIZkUeempOm1bSlC.zdmvL1HZJZx37wvxXLSdUr1LjNk7O6PudQFwU 7lBrGrDNPzRa66VihwNXP.MaA0EIU5R7wUkgcpz6FUfkqVhs3gXJ20ewwWWQnt0rU_OnCnkEp9.q vg1105F9ORSHm8fR0Vp3MqZoXO7HjI_JMVHwLzLks6NG_APfaXV6aPbhddPe8nTEuaKeen7i8hAL 2pTWAJ_Ov7jTi0CvqImhtbKvzykZEhK5KIPJanI3FWdJ825GfsX2I_fM.2.canLRl3rRiIEg2Km8 FKRGoicUY4oNpaYKNIBt2o9iMz4xn2OAYdYxvOpHLblmNh9YMxOSqcibsHHoAbjZGznZbkl6Vm0z 59P897u_sC75g5878lrAJ6WNjD.hyo.w1JvRvLNgEcJ4BlSdNBpBRwMDuEMifHm9CCDGlNZtzPIM GlcwzMAy3jv0KhmwzvpA.m.hvG0IclydPsPiCPhpM9jQaJNoqgsymZPrrmOMDWgzfBzFoJsO0KQk nNV3VVCYZQSvIU0O07O45uHloYm4PNZcOZol3pU.VrBK1MWY.YzWrXOr9SDnaH4JIS7sbuDlOX.i uafbRYIm3ZzDIS0q.lGrNkoXa9tefX1ma.JrJGmDjAgKcqUjfwr6feh0a6_3hoBoFA.Q8Vg1kqCo uNLjxTJlcGhfXdR9T.JvL2ZW.rjnjljuH884_8bQCCnGrIGQ02XJUlrKey_gReLuBXE9usqi691t RtEoGJLQUoVQk9aNhPA1T61lTU4dcR.H5BuRJFnbLkjQCT5HYLfqxyoY0dn11Dkd1seAK42kl1ks qhcCHTJGe8QD_ye19_a0i2LrOhniVxYQxqn7vVTHuUhnqT3t6ygU2.q9qQj_oeexPXCdsKGqppxA U_vmZ.h5zPpFkjxD9GRQJMopdewFEKzvxXwQCTgR0AGWZMFeu2hH7v64q2k2JETdjy3ecHTysm6N VWozitF9.uCvSjueRKy8Y6uIcswvx1FY7WEgJQ2W.L70G_QztggnWchtiH4W8F2s4iPRIdpgWDbo 9AgUnr8nv.d8TdNMn2h1AOGhOkbZaxh3W6wXxqg.7h_FYwz.zVX7meZz9_LpJKb0UK4ARk74_U78 SHL45GB1pvrtiWcenjU93uxZ41k_MeMf1YT_kE3ot.vp0mPYo97hPvwiUfL1ns0vVBTfHWKiV5GJ dfoijWa690RE4fhThAod1vphxZP33Lshs7nUts3Y2A2CtXl9E7oM4iGeGNfQRRZBlhI4uymyu2Rk 4B4oEYZEfsn8in554JistC.hu2yT51B6SQ10cEx3UYwUpNtIBJfZnH_swSPRUjo1tFOwsxOrhJug HTCs- Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Tue, 28 Jan 2020 20:14:51 +0000 Received: by smtp404.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 2bb6fff760f1ff9db0f0f961a01aee27; Tue, 28 Jan 2020 20:14:50 +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 13.0 \(3608.40.2.2.4\)) Subject: Re: btxld not found Message-Id: <71165653-E6AA-46F7-B7F6-B5293ADC9779@yahoo.com> Date: Tue, 28 Jan 2020 12:14:48 -0800 To: zarychtam@plan-b.pwste.edu.pl, FreeBSD Current , Dimitry Andric X-Mailer: Apple Mail (2.3608.40.2.2.4) References: <71165653-E6AA-46F7-B7F6-B5293ADC9779.ref@yahoo.com> X-Rspamd-Queue-Id: 486dBh63LGz4VDk X-Spamd-Bar: / X-Spamd-Result: default: False [-0.43 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.30)[-0.302,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_GOOD(-0.10)[text/plain]; MV_CASE(0.50)[]; TO_DN_SOME(0.00)[]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[205.65.137.98.list.dnswl.org : 127.0.5.0]; NEURAL_SPAM_LONG(0.37)[0.368,0]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.00)[ip: (4.85), ipnet: 98.137.64.0/21(0.84), asn: 36647(0.67), country: US(-0.05)]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 28 Jan 2020 20:14:54 -0000 Marek Zarychta zarychtam at plan-b.pwste.edu.pl wrote on Tue Jan 28 19:33:45 UTC 2020 : > W dniu 28.01.2020 o 19:11, Dimitry Andric pisze: > > On 28 Jan 2020, at 12:36, Nick Hibma = wrote: > >> > >> Could anyone explain to me what I am doing wrong? make installworld = fails each time with the following error > >> > >> =3D=3D=3D> stand/i386/libi386 (install) > >> =3D=3D=3D> stand/i386/loader_4th (install) > >> strip -R .comment -R .note -o loader_4th.bin loader_4th.sym > >> btxld -v -f aout -e 0x200000 -o loader_4th -l = /usr/obj/usr/src/i386.i386/stand/i386/btx/btxldr/btxldr -b = /usr/obj/usr/src/i386.i386/stand/i386/btx/btx/btx loader_4th.bin > >> make[6]: exec(btxld) failed (No such file or directory) > >> *** Error code 1 > >> > >> This is with source of last week. I had this problem before (from = old sources) and fixed it by specifying the full path to btxld in the = stand/i386/*/Makefile. > >=20 > > Yes, this is most likely your clock(s) being off. At installworld = time, > > it should *not* start rebuilding your loader. > >=20 > > Usually this happens if you build on one machine, and install on > > another, while the install machine's time is behind the build = machine's > > time. But it can also happens on one machine, for instance if you > > start in single user mode, and the clock is not yet synchronized. > >=20 > > -Dimitry > >=20 >=20 > I build and install on the same machine, WITH_META_MODE=3Dyes . . . Same here on a ThreadRipper 1950X: a self hosted build and install gets the issue at install time. WITH_META_MODE in use. Never started in single user mode. Also happens for targeting a local directory tree in the install, instead of updating the live system. (A directory tree used later with poudriere.) = https://lists.freebsd.org/pipermail/freebsd-toolchain/2019-December/005130= .html has some timestamps that I observed. btxld.full was about 27 seconds later in the file system than btxld.meta, btxld.debug, and such (until I rebuilt). Looks to me more like multiple parallel builds that stomp on each other. =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 Jan 28 21:28:46 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3F75C241370 for ; Tue, 28 Jan 2020 21:28:46 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 486fqy0tNFz4f3S; Tue, 28 Jan 2020 21:28:46 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qt1-f175.google.com (mail-qt1-f175.google.com [209.85.160.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 0AF2B1F690; Tue, 28 Jan 2020 21:28:46 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qt1-f175.google.com with SMTP id l19so5953646qtq.8; Tue, 28 Jan 2020 13:28:46 -0800 (PST) X-Gm-Message-State: APjAAAXVJSELF18rh3uKLhGQkqRrrGFafp2gSWN5qEkh6gPGou4mMJW6 rgbTMQreF4Lx87kMNg4cU/aY73GGoe0UkqgT2gc= X-Google-Smtp-Source: APXvYqxDegdOuFrTA19HpnSkhXX+h7cSeHQhBe3Bt3WFOUC0oZqHwtBNA1ZtDx3FTgWOqv1reeHCyphRaU0Bp8rSgVo= X-Received: by 2002:ac8:36ab:: with SMTP id a40mr23210825qtc.60.1580246925593; Tue, 28 Jan 2020 13:28:45 -0800 (PST) MIME-Version: 1.0 References: <71165653-E6AA-46F7-B7F6-B5293ADC9779.ref@yahoo.com> <71165653-E6AA-46F7-B7F6-B5293ADC9779@yahoo.com> In-Reply-To: <71165653-E6AA-46F7-B7F6-B5293ADC9779@yahoo.com> From: Kyle Evans Date: Tue, 28 Jan 2020 15:28:32 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: btxld not found To: Mark Millard Cc: zarychtam@plan-b.pwste.edu.pl, FreeBSD Current , Dimitry Andric Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 28 Jan 2020 21:28:46 -0000 On Tue, Jan 28, 2020 at 2:15 PM Mark Millard wrote: > > Marek Zarychta zarychtam at plan-b.pwste.edu.pl wrote on > Tue Jan 28 19:33:45 UTC 2020 : > > > W dniu 28.01.2020 o 19:11, Dimitry Andric pisze: > > > On 28 Jan 2020, at 12:36, Nick Hibma wrote: > > >> > > >> Could anyone explain to me what I am doing wrong? make installworld fails each time with the following error > > >> > > >> ===> stand/i386/libi386 (install) > > >> ===> stand/i386/loader_4th (install) > > >> strip -R .comment -R .note -o loader_4th.bin loader_4th.sym > > >> btxld -v -f aout -e 0x200000 -o loader_4th -l /usr/obj/usr/src/i386.i386/stand/i386/btx/btxldr/btxldr -b /usr/obj/usr/src/i386.i386/stand/i386/btx/btx/btx loader_4th.bin > > >> make[6]: exec(btxld) failed (No such file or directory) > > >> *** Error code 1 > > >> > > >> This is with source of last week. I had this problem before (from old sources) and fixed it by specifying the full path to btxld in the stand/i386/*/Makefile. > > > > > > Yes, this is most likely your clock(s) being off. At installworld time, > > > it should *not* start rebuilding your loader. > > > > > > Usually this happens if you build on one machine, and install on > > > another, while the install machine's time is behind the build machine's > > > time. But it can also happens on one machine, for instance if you > > > start in single user mode, and the clock is not yet synchronized. > > > > > > -Dimitry > > > > > > > I build and install on the same machine, WITH_META_MODE=yes > . . . > > Same here on a ThreadRipper 1950X: a self hosted build and > install gets the issue at install time. WITH_META_MODE in use. > > Never started in single user mode. Also happens for targeting a > local directory tree in the install, instead of updating the > live system. (A directory tree used later with poudriere.) > > https://lists.freebsd.org/pipermail/freebsd-toolchain/2019-December/005130.html > > has some timestamps that I observed. btxld.full was about 27 > seconds later in the file system than btxld.meta, btxld.debug, > and such (until I rebuilt). > > Looks to me more like multiple parallel builds that stomp on > each other. > I suspect y'all want something like the following: diff --git a/stand/i386/Makefile b/stand/i386/Makefile index a9d402acf60..5b4e34ce587 100644 --- a/stand/i386/Makefile +++ b/stand/i386/Makefile @@ -18,4 +18,9 @@ SUBDIR.yes+= pxeldr SUBDIR.${MK_LOADER_ZFS}+= zfsboot gptzfsboot +SUBDIR_DEPEND_pxeldr= btx +SUBDIR_DEPEND_loader_4th= btx +SUBDIR_DEPEND_loader_lua= btx +SUBDIR_DEPEND_loader_simp= btx + .include From owner-freebsd-current@freebsd.org Tue Jan 28 21:31:52 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 73F2C241727 for ; Tue, 28 Jan 2020 21:31:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-24.consmr.mail.gq1.yahoo.com (sonic311-24.consmr.mail.gq1.yahoo.com [98.137.65.205]) (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 486fvW5qSTz4fLm for ; Tue, 28 Jan 2020 21:31:51 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: cMEYhgMVM1k4a2sBl3NJvCsc7U0RIQz2j1SNItJqYGqJGwe0wyg7f55rdFEQXSV 6lEovtp79sj7A6PldZOm2anbXhC4lNotz_irA3ZSL.AF_9CYv0O72fx0CYbfEC5jAMa8M5fp3h9M qRVk.iBOcBPDi546L1RgynRZzCZdcT5.FtQXWs1SdW1Z5hrsNF.RiBXvqTkDNB_TBXKxFi5iadWK MBxC1tXUhZP3fZhl4ZR.KzV6.4aXE2OwmIYSUrSe7FCrIfdoSOsw81PtKa6wxmfi06LYMqJJiCGY RnmgE9M_1zKcYuk7o.7xDPdEuRVvqaCo01dt.zI3Ukricf4MAQ694MpeV8iG1OVdQ0Kms0kdrbp4 qZt__.jPKggtVzz4GmlfClNOiiy.31pqcn70DG3IsWOJUQ47jcS5sLo06yZ9vQdE9.bCxkDnGXr6 w56csYwBVmBE81wYjslIpcZVjjupnEZSw6TskgXS_s796Dp11nl40l61c3RbsWW7IO7msnzsDtZL KfxqNsFem5mfklyXv0dUP6Q7Ii_QPdizLtlWW8BLHitSqpawOOp0vAhXGdytxjPsxDiS0C4baws1 O_lGzjLNyf2waQKItFd_bgMAgV6oaDt91ZrBfiffNpzb7BmTepeD5VvwZD3YlxbMvT9vbRU0jj0i F9olaDyKZIA5cwlCfxWJq.kUzsX1UFKiGytVbdEXDci19sjH8DEQI1CD4N11uHrs.OoMr0PD_mrj .2u.mLNpZ8nlBUXtRbHSfhDIbu5DiccfcUZwn.OmizLtSPgayG3QItunhB2BjMl7DXAAXx8kKsZf .He0L.U501mbJMToWQEh0Pavll1a52.GXDX9XTviK5gptI7V9Y8QSSmOm_xCo3pqNX.6GciL6hvS YIHyi2kgTlA8Yiiu6u4H6Fhs3mS5Qd4R9aqFklY5hEheVnyWd8j6ALypg0b3moleiNVM3fcOCIR0 9gdJtLojURkqiktQ0HE4VQDVo2HR5V3VbhoMzi013O217fmQcy0mHOZUKq.SIsn7H__VaS_7TnKS CBDy08Fa_Tn7mFPzwMeOaP4bOr6JyKfQK2hZJ.mDKASPSjX1e2e47pIlFfMKM9.ARNg2FtOHmxDk l1GAnJX6AJsrlgeHnXnYqZfzpYwJQnSl5wkZ1_2LBxDF3FBUV_mpshi66HAcSyr1bFonoCEJPK7B pOLd5hd5IPmpzR0rv5JY99rLe2lqeTFf062r3_3Xn5HCA8KUJ1P_lGp.C.TZ23s0wyHpOLKKwtr_ dzNrWJslMc54bX.sTXOIHdYUJeDpVkZInLcjOjLwMYTAv9PwgoFVRVeus28PdfciGfg8mmYMnaAB x2mhiW3jOKMadhuHsr8cgysV0bYbGIfCguTvy9x1pv1eMqytrqxYQlnGcJhu22bx7L0QLNScJQRT 8jlYEsAbBC3eAXaBIL6WoFepMeVQNX7mVZ8JTl.d7m0_BHdXLFRhrdTV.xkM_55rrY44oPjKcY6n F00M- Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Tue, 28 Jan 2020 21:31:50 +0000 Received: by smtp407.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 7a4ef4d5a1f1533fea3df44137dd5973; Tue, 28 Jan 2020 21:31:46 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Subject: Re: OOMA kill with vm.pfault_oom_attempts="-1" on RPi3 at r357147 (a vm_pfault_oom_attempts < 0 handling bug as of head -r357026) From: Mark Millard In-Reply-To: <20200128201152.GA15110@www.zefox.net> Date: Tue, 28 Jan 2020 13:31:45 -0800 Cc: freebsd-arm , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <56B3107B-E515-428D-A837-8AF076BADE9B@yahoo.com> References: <20200127190709.GA11328@www.zefox.net> <20200128035317.GA12644@www.zefox.net> <18150258-6210-451E-A5B9-528129A05974@yahoo.com> <9BF68EF1-F83A-473B-9A7B-B3956D6A5EFD@yahoo.com> <20200128170518.GA14654@www.zefox.net> <5A3CE2DA-C5B8-4CC1-BEEA-8B9649A20B8B@yahoo.com> <20200128190210.GA14784@www.zefox.net> <94E68249-7751-4B27-AE95-E9C2776D730B@yahoo.com> <20200128201152.GA15110@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3608.40.2.2.4) X-Rspamd-Queue-Id: 486fvW5qSTz4fLm X-Spamd-Bar: / X-Spamd-Result: default: False [-0.73 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.41)[-0.409,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_GOOD(-0.10)[text/plain]; MV_CASE(0.50)[]; RCVD_COUNT_TWO(0.00)[2]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[205.65.137.98.list.dnswl.org : 127.0.5.0]; NEURAL_SPAM_LONG(0.18)[0.176,0]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.00)[ip: (4.56), ipnet: 98.137.64.0/21(0.84), asn: 36647(0.67), country: US(-0.05)]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 28 Jan 2020 21:31:52 -0000 [I recommend not sending kib our other exchanges: that he has been notified is enough. I also sent the material to 2 folks that I forgot at the time and replied to one more related message with the information. For most of these folks our general exchange is likely viewed as noise after then basic, important point for them. Note: kib was the reviewer, not the creator or submitter of -r357026 .] On 2020-Jan-28, at 12:11, bob prohaska wrote: > On Tue, Jan 28, 2020 at 11:28:14AM -0800, Mark Millard wrote: >>=20 >>=20 >> On 2020-Jan-28, at 11:02, bob prohaska wrote: >>=20 >>> On Tue, Jan 28, 2020 at 09:42:17AM -0800, Mark Millard wrote: >>>>=20 >>>>=20 >>>>=20 >>> The (partly)modified kernel compiled and booted without >>> obvious trouble. It's trying to finish buildworld now. >>>=20 > Stopped already, with=20 > Jan 28 11:41:59 www kernel: pid 29909 (cc), jid 0, uid 0, was killed: = fault's page allocation failed >=20 Yea, what I did in vm_pageout_oom for its messages does indictae when the vm_pageout_oom(VM_OOM_MEM_PF) happens of itself. So the printf before that call is not essential. With the bug that we have identified, this is the expected notification until things are fixed. >=20 >>>> If you are testing with vm.pfault_oom_attempts=3D"-1" then >>>> the vm_fault printf message should never happen anyway. >>>>=20 >>> Would it not be interesting if the message appeared in that >>> case?=20 >>=20 >> Thanks for the question: looking at the new code found a bug >> causing oom where it used to be avoided in head -r357025 and >> before. >=20 >=20 > Glad to be of service, even if inadvertently 8-) >=20 >=20 >> After vm_waitpfault(dset, vm_pfault_oom_wait * hz) >> the -r357026 code does a vm_pageout_oom(VM_OOM_MEM_PF) no >> matter what, even when vm_pfault_oom_attempts < 0 || >> fs->oom < vm_pfault_oom_attempts : >>=20 >> New code in head -r357026 >> ( nothing to avoid the vm_pageout_oom(VM_OOM_MEM_PF) >> for vm_pfault_oom_attempts < 0 || >> fs->oom < vm_pfault_oom_attempts ): >>=20 >> if (fs->m =3D=3D NULL) { >> unlock_and_deallocate(fs); >> if (vm_pfault_oom_attempts < 0 || >> fs->oom < vm_pfault_oom_attempts) { >> fs->oom++; >> vm_waitpfault(dset, vm_pfault_oom_wait * hz); >> } >> if (bootverbose) >> printf( >> "proc %d (%s) failed to alloc page on fault, starting OOM\n", >> curproc->p_pid, curproc->p_comm); >> vm_pageout_oom(VM_OOM_MEM_PF); >> return (KERN_RESOURCE_SHORTAGE); >> } >>=20 >> Old code in head -r357025 >> ( has the goto RetryFault_oom after vm_waitpfault(. . .), >> thereby avoiding the vm_pageout_oom(VM_OOM_MEM_PF) for >> vm_pfault_oom_attempts < 0 || fs->oom < vm_pfault_oom_attempts ) : >>=20 >> if (fs.m =3D=3D NULL) { >> unlock_and_deallocate(&fs); >> if (vm_pfault_oom_attempts < 0 || >> oom < vm_pfault_oom_attempts) { >> oom++; >> vm_waitpfault(dset, >> vm_pfault_oom_wait * hz); >> goto RetryFault_oom; >> } >> if (bootverbose) >> printf( >> "proc %d (%s) failed to alloc page on fault, starting OOM\n", >> curproc->p_pid, = curproc->p_comm); >> vm_pageout_oom(VM_OOM_MEM_PF); >> goto RetryFault; >> } >>=20 >> I expect this is the source of the behavioral >> difference folks have been seeing for OOM kills. >>=20 >>=20 >> As for "gather evidence" messages . . . >>=20 >>>> You may be able to just look and manually delete or >>>> comment out the bootverbose line in the more modern >>>> source that currently looks like: >>>>=20 >>>> if (bootverbose) >>>> printf( >>>> "proc %d (%s) failed to alloc page on fault, starting OOM\n", >>>> curproc->p_pid, curproc->p_comm); >>>> vm_pageout_oom(VM_OOM_MEM_PF); >>>> return (KERN_RESOURCE_SHORTAGE); >>>>=20 >>>=20 >>> I can find those lines in /usr/src/sys/vm/vm_fault.c, but >>> unclear on the motivation to comment the lines out. Perhaps=20 >>> to eliminate the return(...) ? Anyway, is it sufficient=20 >>> to insert /* before and */ after?=20 >>=20 >> The only line to delete or comment out in that >> code block is: >>=20 >> if (bootverbose) >>=20 >> Disabling that line makes the following printf >> always happen, even when a verbose boot was not >> done. > Oops, it's commented out now and the kernel is rebuilding. Not a big deal, given the "was killed: fault's page allocation failed" message that is separately generated. >>=20 >> Based on the above reported code change, having >> a message before vm_pageout_oom(VM_OOM_MEM_PF) is >> important to getting a report of the kill being >> via that code. >>=20 I did not think of what I'd done in vm_pageout_oom when I wrote that. My hope is that at least something like what I did in vm_pageout_oom for message content will be adopted so the notices are accurate to context and more traceable. =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 Jan 28 22:23:01 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 04C37243D86 for ; Tue, 28 Jan 2020 22:23:01 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 486h2X6S64z3Fl8; Tue, 28 Jan 2020 22:23:00 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qt1-f171.google.com (mail-qt1-f171.google.com [209.85.160.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id C74601FEE1; Tue, 28 Jan 2020 22:23:00 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qt1-f171.google.com with SMTP id c24so11640707qtp.5; Tue, 28 Jan 2020 14:23:00 -0800 (PST) X-Gm-Message-State: APjAAAWCuqVmjzV+hxU4RQpl/Q7lp15M7wyz+7bCrtfZOvMctdrlOln9 CcrRTmBbVWqCuFILYGtlz4fMfLPKGgHPcBHasJ0= X-Google-Smtp-Source: APXvYqw0PfF8r9Pyl2egwJgnquoifjgvcUDTXZU+dSF+h6FctUu89f80PtUEvm6TFHCpt4j6kqf2czMDnt8Tsp+KLsM= X-Received: by 2002:ac8:544f:: with SMTP id d15mr24100957qtq.53.1580250180299; Tue, 28 Jan 2020 14:23:00 -0800 (PST) MIME-Version: 1.0 References: <71165653-E6AA-46F7-B7F6-B5293ADC9779.ref@yahoo.com> <71165653-E6AA-46F7-B7F6-B5293ADC9779@yahoo.com> In-Reply-To: From: Kyle Evans Date: Tue, 28 Jan 2020 16:22:48 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: btxld not found To: Mark Millard Cc: zarychtam@plan-b.pwste.edu.pl, FreeBSD Current , Dimitry Andric Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 28 Jan 2020 22:23:01 -0000 On Tue, Jan 28, 2020 at 3:28 PM Kyle Evans wrote: > > On Tue, Jan 28, 2020 at 2:15 PM Mark Millard wrote: > > > > Marek Zarychta zarychtam at plan-b.pwste.edu.pl wrote on > > Tue Jan 28 19:33:45 UTC 2020 : > > > > > W dniu 28.01.2020 o 19:11, Dimitry Andric pisze: > > > > On 28 Jan 2020, at 12:36, Nick Hibma wrote: > > > >> > > > >> Could anyone explain to me what I am doing wrong? make installworld fails each time with the following error > > > >> > > > >> ===> stand/i386/libi386 (install) > > > >> ===> stand/i386/loader_4th (install) > > > >> strip -R .comment -R .note -o loader_4th.bin loader_4th.sym > > > >> btxld -v -f aout -e 0x200000 -o loader_4th -l /usr/obj/usr/src/i386.i386/stand/i386/btx/btxldr/btxldr -b /usr/obj/usr/src/i386.i386/stand/i386/btx/btx/btx loader_4th.bin > > > >> make[6]: exec(btxld) failed (No such file or directory) > > > >> *** Error code 1 > > > >> > > > >> This is with source of last week. I had this problem before (from old sources) and fixed it by specifying the full path to btxld in the stand/i386/*/Makefile. > > > > > > > > Yes, this is most likely your clock(s) being off. At installworld time, > > > > it should *not* start rebuilding your loader. > > > > > > > > Usually this happens if you build on one machine, and install on > > > > another, while the install machine's time is behind the build machine's > > > > time. But it can also happens on one machine, for instance if you > > > > start in single user mode, and the clock is not yet synchronized. > > > > > > > > -Dimitry > > > > > > > > > > I build and install on the same machine, WITH_META_MODE=yes > > . . . > > > > Same here on a ThreadRipper 1950X: a self hosted build and > > install gets the issue at install time. WITH_META_MODE in use. > > > > Never started in single user mode. Also happens for targeting a > > local directory tree in the install, instead of updating the > > live system. (A directory tree used later with poudriere.) > > > > https://lists.freebsd.org/pipermail/freebsd-toolchain/2019-December/005130.html > > > > has some timestamps that I observed. btxld.full was about 27 > > seconds later in the file system than btxld.meta, btxld.debug, > > and such (until I rebuilt). > > > > Looks to me more like multiple parallel builds that stomp on > > each other. > > > > I suspect y'all want something like the following: > Sorry, that patch is clearly wrong- here's take two. A lot of these have dependencies on btxldr that aren't formally described in the targets, so I missed... a lot. New version just builds btx first gated behind a .WAIT then parallel the rest. diff --git a/stand/i386/Makefile b/stand/i386/Makefile index a9d402acf60..24255eefabf 100644 --- a/stand/i386/Makefile +++ b/stand/i386/Makefile @@ -4,7 +4,10 @@ NO_OBJ=t .include -SUBDIR.yes= mbr pmbr boot0 boot0sio btx boot2 cdboot gptboot \ +# Almost everything else here relies on btxldr, so we must make sure it's built +# before everything else proceeds so we don't end up building against a stale +# btxldr and ending up with a build-during-install scenario. +SUBDIR.yes= btx .WAIT mbr pmbr boot0 boot0sio boot2 cdboot gptboot \ isoboot libi386 SUBDIR.${MK_LOADER_FIREWIRE}+= libfirewire From owner-freebsd-current@freebsd.org Tue Jan 28 22:43:59 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id CD1D32446A6 for ; Tue, 28 Jan 2020 22:43:59 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-22.consmr.mail.gq1.yahoo.com (sonic310-22.consmr.mail.gq1.yahoo.com [98.137.69.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 486hVk6LZ3z3GqB for ; Tue, 28 Jan 2020 22:43:58 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: bp89LusVM1kyjRWg1aaxob7tlt881hTkI_2PJhwaUjl2kPyo_BnZ47ubB1VBwyp Qz5gkx6P8i6FazV4jYI1uF0Gx96i_CZTXmlvT9_mTLCBSr5RNcBF.qnqjMmd4U33Vw_97Ldj1eDQ EpTNlbbdkUsr197wWI_GrT5UDPxq59lsekM4hd6LfYs8_X3haNKQF9vNcEAZw0ZIyPvSIilnjYcW .vPyRFvgkOHZvLks1MxmE3t.Xi9dOY2Vro5JHkl4ksT5.7AehhPTzOrxzfsmLOOW8lMsOajlXQui Zsg7tqIXCs_1RdRtiqx9MYwAdv1Nnl0J8Z7KBKfIZwAYjun6TP2MUpn.O_FBODSzqbsroFXkHt1W 7EfJJ6EwsGPegt_uuuKhhwxg5SobBFP50Ch8.zY3zcL1rdxYWYTYvLbA5TUx0V5RVrywghbHG_1P OrILDTaTl8mSL951ZR8CGeDqM1q1FpYf1iNQVm4naD97n7nF7Fw3.PWHYxwYx4PK8FwZNhAXwPwn BPvAkhcb4RLM44waPqS9tS0pbt5E9O69EXcD8NsTBU5mvR3eD_5xnNZFbDR80OXeFX5BdVtLwDJT qGA7YIq4d9JcUt3lxvxzbogM1sWHZAS2zX7F1AfuLcvlwp_0noCukyLYDHv19ZcmNn9xYjmQ6bcG Evgwe2IFg3DO6OWxnsE3S9JHWZw4PngywqOeitT9Ge2krdjrivBXwprthyDzwqyC8RuyZ4SNvdwI 3wJijn8GQUTIV3r42YhzkOUawAVzkLV7DNm8tBjdfhMS5E8Z2NCla.nrctvl9LTxBxaBHeRmSNjj TLUxzAzTX16Gjepca9A5oTnBS4U0zY3520LGrHiYpq8eOjkjDid6Tzc3gxoF35XSZkGZEc5yABTS Q4LrHuwRef9_CY4WH73FjXvk0xP_AjvMwQokFxVrcqLmbZhw3mcVZ2UDC8xkaBVUYgfToHaBgNC9 fZjN2Zs64XFyuMdT7c2bVUZLAW.wLkxjGSoeBYzz5GE9xJuc72khxT0kfP5MhGW9LDe0Fd7ByzEq 0uVw_vrd9WogqrbtSlpN.o.5CiCfZutA0pMYTWa.Rgw9m_5Mlyf8bua2TVDkiMKdRsN5839cSg03 FDIxAN.210MpQOx.21dLKGt6ukhIeDpOMWLofgy_3c5bPNwYMnuuN3WkSzZfRlEX8_5ZmKnvf36O JLS8uJIuYEWl2l34eViLOczj3jmbzAbCki9y.H8Rke7JSAj2WfEwAiabtuCMXgsoE3aGhhpMEFgH jX.5G9FZ9xbrpjj2h1M1oCTZFSjBf1JCdrxAyI7KW7CTKBIT7BKjc9lzzgRoJ4JReLnBx_h0Wi6p qCtsDNKRTMMll1KqfAkwAz677tDO9vx9Pf1eIfpE2GV5urM0b8ZQ5hqlCXJ_IvkNaJSL.tVidwx8 sKMrUgu_ItK.MSY7nu_KggkGffRkmPgkOsDE- Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Tue, 28 Jan 2020 22:43:56 +0000 Received: by smtp412.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 2384c023ba29d611218350bac0caa7a7; Tue, 28 Jan 2020 22:43:51 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Subject: Re: After update to r357104 build of poudriere jail fails with 'out of swap space' From: Mark Millard In-Reply-To: <4682F012-E3C5-4B49-8099-659EBCB7B585@cschubert.com> Date: Tue, 28 Jan 2020 14:43:51 -0800 Cc: "Rodney W. Grimes" , Steve Kargl , FreeBSD Current , yasu@utahime.org, "jeff@freebsd.org" Content-Transfer-Encoding: 7bit Message-Id: <66618B35-A58A-4493-82A2-91671BF4B9E4@yahoo.com> References: <202001261745.00QHjkuW044006@gndrsh.dnsmgr.net> <202001271309.00RD96nr005876@slippy.cwsent.com> <202001272048.00RKmiZs006726@slippy.cwsent.com> <4682F012-E3C5-4B49-8099-659EBCB7B585@cschubert.com> To: Cy Schubert X-Mailer: Apple Mail (2.3608.40.2.2.4) X-Rspamd-Queue-Id: 486hVk6LZ3z3GqB X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.49 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; RCPT_COUNT_FIVE(0.00)[6]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.995,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.99)[-0.994,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (-1.43), ipnet: 98.137.64.0/21(0.84), asn: 36647(0.67), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[148.69.137.98.list.dnswl.org : 127.0.5.0]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 28 Jan 2020 22:43:59 -0000 FYI: kib has a patch out for review to fix the head -r357026 change to OOM behavior in the vm_pageout_oom(VM_OOM_MEM_PF) context: https://reviews.freebsd.org/D23409 === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Tue Jan 28 23:01:35 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A7772244E6F for ; Tue, 28 Jan 2020 23:01:35 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670058.outbound.protection.outlook.com [40.107.67.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 486hv23Lkfz3Hk9; Tue, 28 Jan 2020 23:01:33 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=beL5VH7X6KKIryWEux1+8zV+AXrPD6kYRqdOcnw963iOQC6OnCdCvJNbbd3fV5lhT5BZvz/FQnNkDS5OWy1FCeJpxlbTp2z6LzShk3ghOC8QzzzcBVpTvZhM9AEwznDViK/4KHDxc34kIp3CvEx7xPIYbsA0NwIvEQpPZx+2uQXYrvRVGudOQ7NYFLCY/KtuhM+YamI2Tl59SEwe4g1uMal+p7eqAF5eWDS3d16iSKbcU1Qwh5KYaw/DDzz6EX/Kmoqr9M38DUrNchhHB3LuFC3hG3lSxiakEQBH+h9YlJ4wMv3PmNaB96tx6k/sUJAM2KMFR36IdW50+o2LMk5eZg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Aj4SZF5tNn3oS92r+zalkwYoenYOzNG1Qj1qJJXmJwA=; b=J0GzG29ga0YgII7emc33t/c2iWLMxRTWlCs+e6HleyLhLB3prXrMv3d+boW3gWdf2fzKQ3YtggJxMpUtT8oMIMPJ420eaRO6+esQ2pymT7HWVvPvc5xaWhJM8jPM6QAIN8niUeRmOLROv9SXRYPYwtMlv4oGiUVcVqtfhZHC9B1ASP7/ls3ZpVOmzIR2GsLJJaO052LyBkIyU1JEHyw5qoS1RmdEwyEHMMl2bWs8FCY8JJSpPTxQYcqdYa7fVwJHV9ASN2AQUr4AetPKJePX32oT4oAw3DYT8a8Kl1xSv/Ko1wqFO1YVE3O725h+r5svqUhhDKGAJs/yTPVlwWyAfA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none Received: from YQBPR0101MB1427.CANPRD01.PROD.OUTLOOK.COM (52.132.69.153) by YQBPR0101MB1363.CANPRD01.PROD.OUTLOOK.COM (52.132.70.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.23; Tue, 28 Jan 2020 23:01:32 +0000 Received: from YQBPR0101MB1427.CANPRD01.PROD.OUTLOOK.COM ([fe80::6588:45c3:4892:f98]) by YQBPR0101MB1427.CANPRD01.PROD.OUTLOOK.COM ([fe80::6588:45c3:4892:f98%7]) with mapi id 15.20.2665.026; Tue, 28 Jan 2020 23:01:32 +0000 From: Rick Macklem To: John Baldwin , "freebsd-current@FreeBSD.org" Subject: Re: how to use the ktls Thread-Topic: how to use the ktls Thread-Index: AQHVxa2HeRfmo36hWEyrGcMaBhE88KfhEeoAgBxnlpmAAOgvAIACbdpN Date: Tue, 28 Jan 2020 23:01:31 +0000 Message-ID: References: <5be57c87-90fe-fcbe-ea37-bdb1bcff2da8@FreeBSD.org> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9664ef9f-f2c7-44e7-1254-08d7a4460426 x-ms-traffictypediagnostic: YQBPR0101MB1363: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 029651C7A1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(376002)(396003)(366004)(136003)(199004)(189003)(2906002)(186003)(71200400001)(478600001)(26005)(7696005)(786003)(6506007)(110136005)(316002)(66556008)(66446008)(66476007)(64756008)(91956017)(76116006)(81166006)(81156014)(66946007)(5660300002)(450100002)(52536014)(86362001)(55016002)(9686003)(8936002)(33656002)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:YQBPR0101MB1363; H:YQBPR0101MB1427.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-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 23rxiow/4d61kEArog8608BoTgXnZg8rSr10F282xkQfK0x0oQvxdjY0QZV7bKCANkCL8SXaTpIlDBFWqY9KILu/P2OBRK08QfNx7ILGXKoOFg069jhGs3c6SCoJFECXAI37SSCXWAwdjTEdYUMn+IUuJ2fpWa5dumxIrSBYMHKAfIhtZhUr5fpJMAkwIjDOtROIeubIjPxG+ZqV4bXlkbP630n+Ny0sZVVYlnBMp10O0wOBIBaTMZa/3yllf2JwfqYq3hWk9p9+bQ4NY6vbNSRdH8Bl9pYwLOI5FBUS7HIOap0frRjLcxNzqZJcTVPSgyZUj9fVEgjAw3tXp9l/3WdSHQCbGIoP6XRdBc6Is8fkBb2yyzs+BLL0SEQenKop8yH7ahM0R0yLFCeEkGoto0LjUBzCC9QnkS2GTBnEx/SA8AoA37jnATYLXYjU5tms x-ms-exchange-antispam-messagedata: yrm+zLyjedIaFpSJs+jqwNiPtgqdmdn+vM0f08VsyZCiCAhSEU0BSFuc0lRGCdu+NWnInCKyIzhkK4COPEERgUz3IYdOwIlZE2EifNvKf+gJAt6QRKU/yDPI4z9itIXvi/sXFQ3fa99Q0TZXmTV3kA== x-ms-exchange-transport-forked: True 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: 9664ef9f-f2c7-44e7-1254-08d7a4460426 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jan 2020 23:01:31.8995 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: sBGvPMkBNiCVSjWOHKDP1bU63KcreMlBf3bnhTxNrwsitBZ7XLGS4oscHzX1AnSP6scnW67Hxa5Ad/Ydaj4V/w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQBPR0101MB1363 X-Rspamd-Queue-Id: 486hv23Lkfz3Hk9 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.67.58 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-4.69 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[uoguelph.ca]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[3]; IP_SCORE(-1.39)[ipnet: 40.64.0.0/10(-3.84), asn: 8075(-3.05), country: US(-0.05)]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[58.67.107.40.list.dnswl.org : 127.0.3.0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:8075, ipnet:40.64.0.0/10, country:US]; ARC_ALLOW(-1.00)[i=1] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 28 Jan 2020 23:01:35 -0000 John Baldwin wrote:=0A= [stuff snipped]=0A= >I don't know yet. :-/ With the TOE-based TLS I had been testing with, thi= s doesn't=0A= >happen because the NIC blocks the data until it gets the key and then it's= always=0A= >available via KTLS. With software-based KTLS for RX (which I'm going to s= tart=0A= >working on soon), this won't be the case and you will potentially have som= e data=0A= >already ready by OpenSSL that needs to be drained from OpenSSL before you = can=0A= >depend on KTLS. It's probably only the first few messsages, but I will ne= ed to figure=0A= >out a way that you can tell how much pending data in userland you need to = read via=0A= >SSL_read() and then pass back into the kernel before relying on KTLS (it w= ould just=0A= >be a single chunk of data after SSL_connect you would have to do this for)= .=0A= I think SSL_read() ends up calling ssl3_read_bytes(..APPLICATION..) and the= n it throws=0A= away non-application data records. (Not sure, ssl3_read_bytes() gets pretty= convoluted at=0A= a glance.;-)=0A= =0A= I've found another issue that should keep me amused for a while (this is be= coming an=0A= interesting little project;-).=0A= The KERN_TLS needs unmapped pages on the mbuf chain, but that isn't what NF= S=0A= generates.=0A= I think I'll have to implement some sort of copy function that creates mbuf= s with unmapped=0A= pages and then maps them into kernel space for long enough that the data ca= n be copied,=0A= called just before sosend(). Most NFS RPC messages will easily fit in one p= age.=0A= =0A= Someday, the biggies like server read reply may be able to do what sendfile= does and=0A= put the read data in unmapped page mbufs, avoiding the long list of mbuf cl= usters=0A= that VOP_READ() currently copies the data into.=0A= --> But that's longer term than getting this to work.;-)=0A= =0A= Thanks for all your help John, rick=0A= =0A= > I'm currently testing with a kernel that doesn't have options KERN_TLS an= d=0A= > (so long as I get rid of the 478 bytes), it then just does unencrypted RP= Cs.=0A= >=0A= > So, I guess the big question is.... can I get access to your WIP code for= KTLS=0A= > receive? (I have no idea if I can make progress on it, but I can't do a l= ot more=0A= > before I have that.)=0A= =0A= The WIP only works right now if you have a Chelsio T6 NIC as it uses the T6= 's TCP=0A= offload engine to do TLS. If you don't have that gear, ping me off-list. = It=0A= would also let you not worry about the SSL_read case for now for initial te= sting.=0A= =0A= --=0A= John Baldwin=0A= From owner-freebsd-current@freebsd.org Tue Jan 28 23:10:25 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id BC77E245204 for ; Tue, 28 Jan 2020 23:10:25 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 486j5D5dzRz3JLh; Tue, 28 Jan 2020 23:10:24 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id wZzvi8wpknCigwZzwihITJ; Tue, 28 Jan 2020 16:10:22 -0700 X-Authority-Analysis: v=2.3 cv=cZisUULM c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10 a=Jdjhy38mL1oA:10 a=CjxXgO3LAAAA:8 a=6I5d2MoRAAAA:8 a=YVOhz5M6AAAA:8 a=YxBL1-UpAAAA:8 a=iRn3CRUb-MGSXVv6vewA:9 a=QEXdDO2ut3YA:10 a=IjZwj45LgO3ly-622nXo:22 a=sbbTL3E6IKcx-RquDtO-:22 a=Ia-lj3WSrqcvXOmTRaiG:22 Received: from [IPv6:2605:8d80:401:570e:65af:2990:87df:6dc2] (unknown [72.143.221.231]) by spqr.komquats.com (Postfix) with ESMTPSA id 408ED25D; Tue, 28 Jan 2020 15:10:18 -0800 (PST) Date: Tue, 28 Jan 2020 15:09:52 -0800 User-Agent: K-9 Mail for Android In-Reply-To: <66618B35-A58A-4493-82A2-91671BF4B9E4@yahoo.com> References: <202001261745.00QHjkuW044006@gndrsh.dnsmgr.net> <202001271309.00RD96nr005876@slippy.cwsent.com> <202001272048.00RKmiZs006726@slippy.cwsent.com> <4682F012-E3C5-4B49-8099-659EBCB7B585@cschubert.com> <66618B35-A58A-4493-82A2-91671BF4B9E4@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: After update to r357104 build of poudriere jail fails with 'out of swap space' To: Mark Millard CC: "Rodney W. Grimes" , Steve Kargl , FreeBSD Current , yasu@utahime.org, "jeff@freebsd.org" From: Cy Schubert Message-ID: X-CMAE-Envelope: MS4wfBHWIgWj+0ggxM+AXvdYBEd3fCymmMHCIqEwug3VYwgR/HfsxbxcT7s9Xwh0Ik6f5VZy0TEVAYpx9hx9ZKdaKGZi5A2I5BWDZZcCnbQodVFmHVwv1Dim 2YA498vvbzo46pztCh4q7WIE1GahhEBWnJyWI48hS6pFuwKeWBy9N0uMeyOfseyywa31iKOZSMqBxIwYqg76KGez2hidf153uDvv2+e/O8AkHbhXYPvLRgjD bK9xiNb7oQ8HXMS+xETWE41AJLjYsjCdJ9EMHG/fQvVylJh9J4TfZOfMm7uCCXlOtlhiNcgM5EvKPcZtulGk/HyVVjXOHCMZ4TSFt/rfJL1xwUXWwaVxgJd6 R40D3BAs X-Rspamd-Queue-Id: 486j5D5dzRz3JLh X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 64.59.134.12) smtp.mailfrom=cy.schubert@cschubert.com X-Spamd-Result: default: False [-4.67 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[12.134.59.64.rep.mailspike.net : 127.0.0.18]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; RCPT_COUNT_FIVE(0.00)[6]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[17.125.67.70.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11,231.221.143.72.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; R_SPF_NA(0.00)[]; FREEMAIL_TO(0.00)[yahoo.com]; RCVD_IN_DNSWL_LOW(-0.10)[12.134.59.64.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(-2.47)[ip: (-6.61), ipnet: 64.59.128.0/20(-3.19), asn: 6327(-2.48), country: CA(-0.09)]; FROM_EQ_ENVFROM(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 28 Jan 2020 23:10:25 -0000 On January 28, 2020 2:43:51 PM PST, Mark Millard wrot= e: >FYI: kib has a patch out for review to fix the > head -r357026 change to OOM behavior in > the vm_pageout_oom(VM_OOM_MEM_PF) context: > >https://reviews=2Efreebsd=2Eorg/D23409 > >=3D=3D=3D >Mark Millard >marklmi at yahoo=2Ecom >( dsl-only=2Enet went >away in early 2018-Mar) Works here at $JOB=2E --=20 Pardon the typos and autocorrect, small keyboard in use=2E=20 Cy Schubert FreeBSD UNIX: Web: https://www=2EFreeBSD=2Eorg The need of the many outweighs the greed of the few=2E Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E From owner-freebsd-current@freebsd.org Tue Jan 28 23:42:36 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 43640245D25 for ; Tue, 28 Jan 2020 23:42:36 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [IPv6:2001:678:618::40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "plan-b.pwste.edu.pl", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 486jpL6fkvz3KqG for ; Tue, 28 Jan 2020 23:42:34 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from fomalhaut.potoki.eu ([IPv6:2001:470:71:d47:5a5:b77c:8c04:e45d]) (authenticated bits=0) by plan-b.pwste.edu.pl (8.15.2/8.15.2) with ESMTPSA id 00SNgUrw052826 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 29 Jan 2020 00:42:30 +0100 (CET) (envelope-from zarychtam@plan-b.pwste.edu.pl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plan-b.pwste.edu.pl; s=plan-b-mailer; t=1580254950; bh=aX18+HFKulk+cLmlq79KoVYRfm6SKOakbPqISye97LY=; h=To:References:From:Subject:Date:In-Reply-To; b=fAqyIKdRMrjcu0XY6tnRhQy4BaSfhQn5FHyhvDGhBMM3k+SBphg1r3pfG9mRdYupD uhOOW5Pys4QN4bgkeaSIcArJmhPawAOGdxQMPLq1SEeybA7I/JNpbWKvvRmcmClBFj ieStKiQarGzwbJqjknLwywJxxbyzlmnVOkQ1QgsAK0yEb7w4kuNC4MkhEzBnfiUYNz i3j821jeYjGrjl6Nooib/Y/fAegdPylSZ/Dw5cn6EFPbGbd8rTx0Iuptuh/UQAbEMw tkyu/1Br/K25XwcI9bBibxQof02XHqCJAfgNJ13I60V9hCQvv4GcikFTx3ShRVSwRp Kf0IoXOdHGFpw== X-Authentication-Warning: plan-b.pwste.edu.pl: Host [IPv6:2001:470:71:d47:5a5:b77c:8c04:e45d] claimed to be fomalhaut.potoki.eu To: freebsd-current@freebsd.org References: <71165653-E6AA-46F7-B7F6-B5293ADC9779.ref@yahoo.com> <71165653-E6AA-46F7-B7F6-B5293ADC9779@yahoo.com> From: Marek Zarychta Autocrypt: addr=zarychtam@plan-b.pwste.edu.pl; prefer-encrypt=mutual; keydata= mQENBFfi3cMBCADLecMTFXad4uDXqv3eRuB4qJJ8G9tzzFezeRnnwxOsPdytW5ES2z1ibSrR IsiImx6+PTqrAmXpTInxAi7yiZGdSiONRI4CCxKY9d1YFiNYT/2WyNXCekm9x29YeIU7x0JB Llbz0f/9HC+styBIu2H+PY/X98Clzm110CS+n/b9l1AtiGxTiVFj7/uavYAKxH6LNWnbkuc5 v8EVNc7NkEcl5h7Z9X5NEtzDxTOiBIFQ/kOT7LAtkYUPo1lqLeOM2DtWSXTXQgXl0zJI4iP1 OAu4qQYm2nXwq4b2AH9peknelvnt1mpfgDCGSKnhc26q6ibTfMwydp+tvUtQIQYpA6b9ABEB AAG0N01hcmVrIFphcnljaHRhIChQbGFuLWIpIDx6YXJ5Y2h0YW1AcGxhbi1iLnB3c3RlLmVk dS5wbD6JATcEEwEIACEFAlfi4LkCGwMFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQHZW8 vIFppoJXdgf8D9X3VRFSNaR9lthSx/+uqas17J3FJKBo1xMQsC2a+44vzNvYJSuPGLLJ+LW2 HPVazjP/BWZJbxOYpliY4zxNRU0YCp0BLIVLibc//yax+mE42FND/+NiIZhqJscl6MLPrSwo sIwXec4XYkldkyqW/xBbBYXoIkBqdKB9j5j42Npy1IV/RizOSdmvTWY27ir8e/yGMR1RLr4F 8P5K3OWTdlGy2H2F/3J8bIPBLG6FpaIyLQw4dHSx8V02PYqDxK1cNo2kAOnU8PnZL/AGuMOH iv3MN1VYL8ehcmpBBsrZGebQJxrjY2/5IaTSgp9xHYT70kshuU6Qb97vk1mOjNZxgbkBDQRX 4t3DAQgA10h6RCXuBLMHxq5B8X/ZIlj9sgLoeyfRdDZEc9rT2KUeUJVHDsbvOFf4/7F1ovWY hJbA6GK/LUZeHHTjnbZcH1uDYQeHly4UOLxeEvhGoz4JhS2C7JzN/uRnwbdOAUbJr8rUj/IY a7gk906rktsc/Ldrxrxh7O6WO0JCh2XO/p4pDfEwwB37g4xHprSab28ECYJ9JMbtA8Sy4M55 g3+GQ28FvSlGnx48OoGXU2BZdc1vZKSQmNOlikB+9/hDX8zdYWVfDaX1TLQ8Ib4+xTUmapza mV/bxIsaZRBw+jFjLQHhTbIMfPEU+4mxFDvTdbKPruKPqVf1ydgMnPZWngowdwARAQABiQEf BBgBCAAJBQJX4t3DAhsMAAoJEB2VvLyBaaaC6qkIAJs9sDPqrqW0bYoRfzY6XjDWQ59p9tJi v8aogxacQNCfAu+WkJ8PNVUtC1dlVcG5NnZ80gXzd1rc8ueIvXlvdanUt/jZd8jbb3gaDbK3 wh1yMCGBl/1fOJTyEGYv1CRojv97KK89KP5+r8x1P1iHcSrunlDNqGxTMydNCwBH23QcOM+m u4spKnJ/s0VRBkw3xoKBZfZza6fTQ4gTpAipjyk7ldOGBV+PvkKATdhK2yLwuWXhKbg/GRlD 1r5P0gxzSqfV4My+KJuc2EDcrqp1y0wOpE1m9iZqCcd0fup5f7HDsYlLWshr7NQl28f6+fQb sylq/j672BHXsdeqf/Ip9V65AQ0EV+OTdwEIAMxnGg7OO/ZAnSwiIiABA9lil1Lfa5BWTH3c l1rz4slz7Gw99G9J3bX3FiPA0vU89dgBZ2k0/UVk5cI5EsMAvwJN4bPwRsfBELQqjCKkVZr4 vUeGyvgQ2jnoK1fcEFOnCRdwFy4EJ6Y/fsZCTj4IfQpkM1W7C3KuSGPcjPDA9XCLDjjp8bbA Q9VgQ68MntAnYxMqK0S3CrHp5Pruvb0x4MfFLNwaKtWK+UnJGPT4umj8PMP6XLsFC3g+SGoP aWoYRDI297ZGx4IBWEaJq181oEC5iUQ6WREti9fNQ3TsAB3Q2CjNlkx1geSczIFJSyOHmyJZ RqAocw1sIuPopvhWtR0AEQEAAYkCRAQYAQgADwUCV+OTdwIbAgUJCWYBgAEpCRAdlby8gWmm gsBdIAQZAQgABgUCV+OTdwAKCRB1n+z//VKNLOETCAC3ggwAAQij4hkIxQFapnRuIVb5vq7D AwJ9+Ld5/zYHOj2Tfu+BPSNGzI2edqboz2w1t55UHEYzYDp2axxIfPrZrXsBV4DsjtGwzVV/ jZ9or5qTaYFDEStRkzL4mRpTyYhl/T7GgWpwOJWOih+cU7RWzjSOxiYMi4QSYlkpDUCcZew0 C3HfcxeFqpeL46zgysHC2ptjINXQ+xR2/F6dbed+l7OsvJAfkBqJoQ/48m+8ly1lbViKck7q gWw143ljaKn2qGIjZdb95zcI/CP4L45SXq8NOweACdx2NfUphLrIMbNCqLkMUJcrnruKfbnp C8OMjFJIqlu+PsW593NcZyOugEAH/0cBsDxlSauSVK4kp8ald26pcBI6igNnIMgjaxMiZBjn eoxBiKAOAO93sPnPr9/64CMMwv1T+0vU2lj8SMKOdHVrB9sW/ICGji5skE85xPEAtUkdAQN+ +c2clotujcaj9lBZKJdncKmSxY0SshEa66H+s76u+2Q3jGK6vOrdxakWYCvh2P0/l52Nd/t2 eazLFgwtk5rbo7O0MSC1GNXUsG07vtZ+zxJXFRx7PQ3ZIn0Y4HqwvXUvqgZ9EHiKy8F+ondz 9IS8/Fs81N5ieujHhSWqbaibapnpeDHvT/FWf8iXfJqWq+F7C8lGShSkmsS5AOhB4TNNH5/m ZzECJa1ql64= Subject: Re: btxld not found Message-ID: <75b79201-0282-2f26-5eac-a1944d1d94fa@plan-b.pwste.edu.pl> Date: Wed, 29 Jan 2020 00:42:20 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="1cNEyvINqeCh34C5omVuuP8TFoYXpvhRD" X-Rspamd-Queue-Id: 486jpL6fkvz3KqG X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=plan-b.pwste.edu.pl header.s=plan-b-mailer header.b=fAqyIKdR; dmarc=pass (policy=none) header.from=pwste.edu.pl; spf=none (mx1.freebsd.org: domain of zarychtam@plan-b.pwste.edu.pl has no SPF policy when checking 2001:678:618::40) smtp.mailfrom=zarychtam@plan-b.pwste.edu.pl X-Spamd-Result: default: False [-4.51 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[plan-b.pwste.edu.pl:s=plan-b-mailer]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[pwste.edu.pl.dwl.dnswl.org : 127.0.11.0]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; HAS_ATTACHMENT(0.00)[]; HAS_XAW(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[plan-b.pwste.edu.pl:+]; DMARC_POLICY_ALLOW(-0.50)[pwste.edu.pl,none]; R_SPF_NA(0.00)[]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; IP_SCORE(0.39)[asn: 206006(1.89), country: PL(0.07)]; ASN(0.00)[asn:206006, ipnet:2001:678:618::/48, country:PL]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 28 Jan 2020 23:42:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1cNEyvINqeCh34C5omVuuP8TFoYXpvhRD Content-Type: multipart/mixed; boundary="3Vv3wMrGf8VKL2EOHeMgHrNG8eCxaAKPh"; protected-headers="v1" From: Marek Zarychta To: freebsd-current@freebsd.org Message-ID: <75b79201-0282-2f26-5eac-a1944d1d94fa@plan-b.pwste.edu.pl> Subject: Re: btxld not found References: <71165653-E6AA-46F7-B7F6-B5293ADC9779.ref@yahoo.com> <71165653-E6AA-46F7-B7F6-B5293ADC9779@yahoo.com> In-Reply-To: --3Vv3wMrGf8VKL2EOHeMgHrNG8eCxaAKPh Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable W dniu 28.01.2020 o=C2=A022:28, Kyle Evans pisze: > On Tue, Jan 28, 2020 at 2:15 PM Mark Millard wrote:= >> >> Marek Zarychta zarychtam at plan-b.pwste.edu.pl wrote on >> Tue Jan 28 19:33:45 UTC 2020 : >> >>> W dniu 28.01.2020 o 19:11, Dimitry Andric pisze: >>>> On 28 Jan 2020, at 12:36, Nick Hibma wro= te: >>>>> >>>>> Could anyone explain to me what I am doing wrong? make installworld= fails each time with the following error >>>>> >>>>> =3D=3D=3D> stand/i386/libi386 (install) >>>>> =3D=3D=3D> stand/i386/loader_4th (install) >>>>> strip -R .comment -R .note -o loader_4th.bin loader_4th.sym >>>>> btxld -v -f aout -e 0x200000 -o loader_4th -l /usr/obj/usr/src/i386= =2Ei386/stand/i386/btx/btxldr/btxldr -b /usr/obj/usr/src/i386.i386/stand= /i386/btx/btx/btx loader_4th.bin >>>>> make[6]: exec(btxld) failed (No such file or directory) >>>>> *** Error code 1 >>>>> >>>>> This is with source of last week. I had this problem before (from o= ld sources) and fixed it by specifying the full path to btxld in the stan= d/i386/*/Makefile. >>>> >>>> Yes, this is most likely your clock(s) being off. At installworld t= ime, >>>> it should *not* start rebuilding your loader. >>>> >>>> Usually this happens if you build on one machine, and install on >>>> another, while the install machine's time is behind the build machin= e's >>>> time. But it can also happens on one machine, for instance if you >>>> start in single user mode, and the clock is not yet synchronized. >>>> >>>> -Dimitry >>>> >>> >>> I build and install on the same machine, WITH_META_MODE=3Dyes >> . . . >> >> Same here on a ThreadRipper 1950X: a self hosted build and >> install gets the issue at install time. WITH_META_MODE in use. >> >> Never started in single user mode. Also happens for targeting a >> local directory tree in the install, instead of updating the >> live system. (A directory tree used later with poudriere.) >> >> https://lists.freebsd.org/pipermail/freebsd-toolchain/2019-December/00= 5130.html >> >> has some timestamps that I observed. btxld.full was about 27 >> seconds later in the file system than btxld.meta, btxld.debug, >> and such (until I rebuilt). >> >> Looks to me more like multiple parallel builds that stomp on >> each other. >> >=20 > I suspect y'all want something like the following: >=20 > diff --git a/stand/i386/Makefile b/stand/i386/Makefile > index a9d402acf60..5b4e34ce587 100644 > --- a/stand/i386/Makefile > +++ b/stand/i386/Makefile > @@ -18,4 +18,9 @@ SUBDIR.yes+=3D pxeldr >=20 > SUBDIR.${MK_LOADER_ZFS}+=3D zfsboot gptzfsboot >=20 > +SUBDIR_DEPEND_pxeldr=3D btx > +SUBDIR_DEPEND_loader_4th=3D btx > +SUBDIR_DEPEND_loader_lua=3D btx > +SUBDIR_DEPEND_loader_simp=3D btx > + > .include Thank you for taking care of this. The patch above worked and I confirm it solves the issue for me. I was not able to build the world with the patch you have posted later, here is the link to build log --> https://bsd.to/jTpd --=20 Marek Zarychta --3Vv3wMrGf8VKL2EOHeMgHrNG8eCxaAKPh-- --1cNEyvINqeCh34C5omVuuP8TFoYXpvhRD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEMOqvKm6wKvS1/ZeCdZ/s//1SjSwFAl4wxuYACgkQdZ/s//1S jSygMAf/e4Hs4UU3ZyGqLxuI1WDpe61O4XSWMKbVwoMTXcDB3iVaxuu/3SlqXuYq l7VuZNbMVQKhalh2AI05FvC5w6DP1OcKc04vUdrSMW0drTkRB8Of0br5SJmAuoBy JKhVMpoOsWtzXS6mtr6oGP+mZRtKHGL1gsnbf09k5owK/kuIGf/yxzdPobeOQmKE HzX8nQjYHg+AjXkDIlI06q5wA+mQnvM+29hwrVcldO229CRnMOwWHyu0KnGeqfjx f7oouUcxcqcZBrZBQDnLSVSLEJJKe0mvCR1jm35of71qdX31d2Tt2JDsTvNVt4jS +GLFTB3Nf9ETngejF7krHgAQNL6jcg== =rtz8 -----END PGP SIGNATURE----- --1cNEyvINqeCh34C5omVuuP8TFoYXpvhRD-- From owner-freebsd-current@freebsd.org Wed Jan 29 00:20:13 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id F3DC1246D0F for ; Wed, 29 Jan 2020 00:20:13 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 486kdn6F8bz3MMR for ; Wed, 29 Jan 2020 00:20:13 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qt1-f182.google.com (mail-qt1-f182.google.com [209.85.160.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id C3F0AE80 for ; Wed, 29 Jan 2020 00:20:13 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qt1-f182.google.com with SMTP id j5so11831799qtq.9 for ; Tue, 28 Jan 2020 16:20:13 -0800 (PST) X-Gm-Message-State: APjAAAXCLb4j4WBNff0ZUhWte/PIe3kUjQHWLhOxi8nM7YuIsrfSGN3n XnXBDbMW4cmYhiFNEQ4lE98O4alXJKrxdvfrxIE= X-Google-Smtp-Source: APXvYqzdPwhHgolZq5QIqrzxE4v07zSve20kyNpMMSFz7HRJM9n4eXq1AENIaOUHDEgxHOkr/jAHwWR+yWLBxRFpaUI= X-Received: by 2002:ac8:4890:: with SMTP id i16mr23477906qtq.211.1580257213389; Tue, 28 Jan 2020 16:20:13 -0800 (PST) MIME-Version: 1.0 References: <71165653-E6AA-46F7-B7F6-B5293ADC9779.ref@yahoo.com> <71165653-E6AA-46F7-B7F6-B5293ADC9779@yahoo.com> <75b79201-0282-2f26-5eac-a1944d1d94fa@plan-b.pwste.edu.pl> In-Reply-To: <75b79201-0282-2f26-5eac-a1944d1d94fa@plan-b.pwste.edu.pl> From: Kyle Evans Date: Tue, 28 Jan 2020 18:20:02 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: btxld not found To: Marek Zarychta Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 29 Jan 2020 00:20:14 -0000 (Resend because I suck at e-mail; sorry Marek) On Tue, Jan 28, 2020 at 5:42 PM Marek Zarychta wrote: > > W dniu 28.01.2020 o 22:28, Kyle Evans pisze: > > On Tue, Jan 28, 2020 at 2:15 PM Mark Millard wrote: > >> > >> Marek Zarychta zarychtam at plan-b.pwste.edu.pl wrote on > >> Tue Jan 28 19:33:45 UTC 2020 : > >> > >>> W dniu 28.01.2020 o 19:11, Dimitry Andric pisze: > >>>> On 28 Jan 2020, at 12:36, Nick Hibma wrote: > >>>>> > >>>>> Could anyone explain to me what I am doing wrong? make installworld fails each time with the following error > >>>>> > >>>>> ===> stand/i386/libi386 (install) > >>>>> ===> stand/i386/loader_4th (install) > >>>>> strip -R .comment -R .note -o loader_4th.bin loader_4th.sym > >>>>> btxld -v -f aout -e 0x200000 -o loader_4th -l /usr/obj/usr/src/i386.i386/stand/i386/btx/btxldr/btxldr -b /usr/obj/usr/src/i386.i386/stand/i386/btx/btx/btx loader_4th.bin > >>>>> make[6]: exec(btxld) failed (No such file or directory) > >>>>> *** Error code 1 > >>>>> > >>>>> This is with source of last week. I had this problem before (from old sources) and fixed it by specifying the full path to btxld in the stand/i386/*/Makefile. > >>>> > >>>> Yes, this is most likely your clock(s) being off. At installworld time, > >>>> it should *not* start rebuilding your loader. > >>>> > >>>> Usually this happens if you build on one machine, and install on > >>>> another, while the install machine's time is behind the build machine's > >>>> time. But it can also happens on one machine, for instance if you > >>>> start in single user mode, and the clock is not yet synchronized. > >>>> > >>>> -Dimitry > >>>> > >>> > >>> I build and install on the same machine, WITH_META_MODE=yes > >> . . . > >> > >> Same here on a ThreadRipper 1950X: a self hosted build and > >> install gets the issue at install time. WITH_META_MODE in use. > >> > >> Never started in single user mode. Also happens for targeting a > >> local directory tree in the install, instead of updating the > >> live system. (A directory tree used later with poudriere.) > >> > >> https://lists.freebsd.org/pipermail/freebsd-toolchain/2019-December/005130.html > >> > >> has some timestamps that I observed. btxld.full was about 27 > >> seconds later in the file system than btxld.meta, btxld.debug, > >> and such (until I rebuilt). > >> > >> Looks to me more like multiple parallel builds that stomp on > >> each other. > >> > > > > I suspect y'all want something like the following: > > > > diff --git a/stand/i386/Makefile b/stand/i386/Makefile > > index a9d402acf60..5b4e34ce587 100644 > > --- a/stand/i386/Makefile > > +++ b/stand/i386/Makefile > > @@ -18,4 +18,9 @@ SUBDIR.yes+= pxeldr > > > > SUBDIR.${MK_LOADER_ZFS}+= zfsboot gptzfsboot > > > > +SUBDIR_DEPEND_pxeldr= btx > > +SUBDIR_DEPEND_loader_4th= btx > > +SUBDIR_DEPEND_loader_lua= btx > > +SUBDIR_DEPEND_loader_simp= btx > > + > > .include > > Thank you for taking care of this. The patch above worked and I confirm > it solves the issue for me. > That's good to hear! I was starting to doubt because we don't use SUBDIR_PARALLEL in the stand build, but on second glance we inherit it during buildworld I reckon. > I was not able to build the world with the patch you have posted later, > here is the link to build log --> https://bsd.to/jTpd > This looks like the patch may have misapplied and btx ended up in SUBDIR.yes twice -- the second instance should be removed, and only the first on the left-hand-side of .WAIT should remain. From owner-freebsd-current@freebsd.org Wed Jan 29 07:30:38 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C5DDC1C4600 for ; Wed, 29 Jan 2020 07:30:38 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [IPv6:2001:678:618::40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "plan-b.pwste.edu.pl", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 486wBN6w2Qz4FSF for ; Wed, 29 Jan 2020 07:30:36 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from fomalhaut.potoki.eu (static62133140050.ostnet.pl [62.133.140.50]) (authenticated bits=0) by plan-b.pwste.edu.pl (8.15.2/8.15.2) with ESMTPSA id 00T7UWcq035896 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 29 Jan 2020 08:30:32 +0100 (CET) (envelope-from zarychtam@plan-b.pwste.edu.pl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plan-b.pwste.edu.pl; s=plan-b-mailer; t=1580283032; bh=x25l+e5JVqKQhvtAao21oFOBsXQshVk83juZNR5F4R4=; h=Subject:To:References:From:Date:In-Reply-To; b=jG+I0zwCf5rlL8v+IWpKcfevwvVPaI8zR+1GuzEvhhFIzb8d2uTu+VCYCEpiIARHz vAHliZ/RvGcQHMj7/CeihWLJsJa4wbqC437LrNMVIFPAojGWzU0j/nN8iLuw4JTovC XS967U9yfAR2xxsBNdqf1EsRhJBcticsohp+4zNucjN3fJZ+nZk3vF2DHUaf40igmY m/yJmPT8JC5ZAOGZ6sEsKt0l32VTQI/nT2XEJXwGREosZzPPzfrSRer5oybPKAQnIR TWv6si3Cfy9dN78S3/N1fIx9VmUmCam2Qk+4V1BngMGMm33sbuczPRn8OXNIWjNCbO yAwsZSPirhhwQ== X-Authentication-Warning: plan-b.pwste.edu.pl: Host static62133140050.ostnet.pl [62.133.140.50] claimed to be fomalhaut.potoki.eu Subject: Re: btxld not found To: freebsd-current@freebsd.org References: <71165653-E6AA-46F7-B7F6-B5293ADC9779.ref@yahoo.com> <71165653-E6AA-46F7-B7F6-B5293ADC9779@yahoo.com> From: Marek Zarychta Autocrypt: addr=zarychtam@plan-b.pwste.edu.pl; prefer-encrypt=mutual; keydata= mQENBFfi3cMBCADLecMTFXad4uDXqv3eRuB4qJJ8G9tzzFezeRnnwxOsPdytW5ES2z1ibSrR IsiImx6+PTqrAmXpTInxAi7yiZGdSiONRI4CCxKY9d1YFiNYT/2WyNXCekm9x29YeIU7x0JB Llbz0f/9HC+styBIu2H+PY/X98Clzm110CS+n/b9l1AtiGxTiVFj7/uavYAKxH6LNWnbkuc5 v8EVNc7NkEcl5h7Z9X5NEtzDxTOiBIFQ/kOT7LAtkYUPo1lqLeOM2DtWSXTXQgXl0zJI4iP1 OAu4qQYm2nXwq4b2AH9peknelvnt1mpfgDCGSKnhc26q6ibTfMwydp+tvUtQIQYpA6b9ABEB AAG0N01hcmVrIFphcnljaHRhIChQbGFuLWIpIDx6YXJ5Y2h0YW1AcGxhbi1iLnB3c3RlLmVk dS5wbD6JATcEEwEIACEFAlfi4LkCGwMFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQHZW8 vIFppoJXdgf8D9X3VRFSNaR9lthSx/+uqas17J3FJKBo1xMQsC2a+44vzNvYJSuPGLLJ+LW2 HPVazjP/BWZJbxOYpliY4zxNRU0YCp0BLIVLibc//yax+mE42FND/+NiIZhqJscl6MLPrSwo sIwXec4XYkldkyqW/xBbBYXoIkBqdKB9j5j42Npy1IV/RizOSdmvTWY27ir8e/yGMR1RLr4F 8P5K3OWTdlGy2H2F/3J8bIPBLG6FpaIyLQw4dHSx8V02PYqDxK1cNo2kAOnU8PnZL/AGuMOH iv3MN1VYL8ehcmpBBsrZGebQJxrjY2/5IaTSgp9xHYT70kshuU6Qb97vk1mOjNZxgbkBDQRX 4t3DAQgA10h6RCXuBLMHxq5B8X/ZIlj9sgLoeyfRdDZEc9rT2KUeUJVHDsbvOFf4/7F1ovWY hJbA6GK/LUZeHHTjnbZcH1uDYQeHly4UOLxeEvhGoz4JhS2C7JzN/uRnwbdOAUbJr8rUj/IY a7gk906rktsc/Ldrxrxh7O6WO0JCh2XO/p4pDfEwwB37g4xHprSab28ECYJ9JMbtA8Sy4M55 g3+GQ28FvSlGnx48OoGXU2BZdc1vZKSQmNOlikB+9/hDX8zdYWVfDaX1TLQ8Ib4+xTUmapza mV/bxIsaZRBw+jFjLQHhTbIMfPEU+4mxFDvTdbKPruKPqVf1ydgMnPZWngowdwARAQABiQEf BBgBCAAJBQJX4t3DAhsMAAoJEB2VvLyBaaaC6qkIAJs9sDPqrqW0bYoRfzY6XjDWQ59p9tJi v8aogxacQNCfAu+WkJ8PNVUtC1dlVcG5NnZ80gXzd1rc8ueIvXlvdanUt/jZd8jbb3gaDbK3 wh1yMCGBl/1fOJTyEGYv1CRojv97KK89KP5+r8x1P1iHcSrunlDNqGxTMydNCwBH23QcOM+m u4spKnJ/s0VRBkw3xoKBZfZza6fTQ4gTpAipjyk7ldOGBV+PvkKATdhK2yLwuWXhKbg/GRlD 1r5P0gxzSqfV4My+KJuc2EDcrqp1y0wOpE1m9iZqCcd0fup5f7HDsYlLWshr7NQl28f6+fQb sylq/j672BHXsdeqf/Ip9V65AQ0EV+OTdwEIAMxnGg7OO/ZAnSwiIiABA9lil1Lfa5BWTH3c l1rz4slz7Gw99G9J3bX3FiPA0vU89dgBZ2k0/UVk5cI5EsMAvwJN4bPwRsfBELQqjCKkVZr4 vUeGyvgQ2jnoK1fcEFOnCRdwFy4EJ6Y/fsZCTj4IfQpkM1W7C3KuSGPcjPDA9XCLDjjp8bbA Q9VgQ68MntAnYxMqK0S3CrHp5Pruvb0x4MfFLNwaKtWK+UnJGPT4umj8PMP6XLsFC3g+SGoP aWoYRDI297ZGx4IBWEaJq181oEC5iUQ6WREti9fNQ3TsAB3Q2CjNlkx1geSczIFJSyOHmyJZ RqAocw1sIuPopvhWtR0AEQEAAYkCRAQYAQgADwUCV+OTdwIbAgUJCWYBgAEpCRAdlby8gWmm gsBdIAQZAQgABgUCV+OTdwAKCRB1n+z//VKNLOETCAC3ggwAAQij4hkIxQFapnRuIVb5vq7D AwJ9+Ld5/zYHOj2Tfu+BPSNGzI2edqboz2w1t55UHEYzYDp2axxIfPrZrXsBV4DsjtGwzVV/ jZ9or5qTaYFDEStRkzL4mRpTyYhl/T7GgWpwOJWOih+cU7RWzjSOxiYMi4QSYlkpDUCcZew0 C3HfcxeFqpeL46zgysHC2ptjINXQ+xR2/F6dbed+l7OsvJAfkBqJoQ/48m+8ly1lbViKck7q gWw143ljaKn2qGIjZdb95zcI/CP4L45SXq8NOweACdx2NfUphLrIMbNCqLkMUJcrnruKfbnp C8OMjFJIqlu+PsW593NcZyOugEAH/0cBsDxlSauSVK4kp8ald26pcBI6igNnIMgjaxMiZBjn eoxBiKAOAO93sPnPr9/64CMMwv1T+0vU2lj8SMKOdHVrB9sW/ICGji5skE85xPEAtUkdAQN+ +c2clotujcaj9lBZKJdncKmSxY0SshEa66H+s76u+2Q3jGK6vOrdxakWYCvh2P0/l52Nd/t2 eazLFgwtk5rbo7O0MSC1GNXUsG07vtZ+zxJXFRx7PQ3ZIn0Y4HqwvXUvqgZ9EHiKy8F+ondz 9IS8/Fs81N5ieujHhSWqbaibapnpeDHvT/FWf8iXfJqWq+F7C8lGShSkmsS5AOhB4TNNH5/m ZzECJa1ql64= Message-ID: <9079b2c2-d055-f304-0744-215e2573e291@plan-b.pwste.edu.pl> Date: Wed, 29 Jan 2020 08:30:28 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="o2Acsl9JZohj43FuWj66sel8DVnStjgjR" X-Rspamd-Queue-Id: 486wBN6w2Qz4FSF X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=plan-b.pwste.edu.pl header.s=plan-b-mailer header.b=jG+I0zwC; dmarc=pass (policy=none) header.from=pwste.edu.pl; spf=none (mx1.freebsd.org: domain of zarychtam@plan-b.pwste.edu.pl has no SPF policy when checking 2001:678:618::40) smtp.mailfrom=zarychtam@plan-b.pwste.edu.pl X-Spamd-Result: default: False [-4.53 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[plan-b.pwste.edu.pl:s=plan-b-mailer]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[pwste.edu.pl.dwl.dnswl.org : 127.0.11.0]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; HAS_ATTACHMENT(0.00)[]; HAS_XAW(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[plan-b.pwste.edu.pl:+]; DMARC_POLICY_ALLOW(-0.50)[pwste.edu.pl,none]; R_SPF_NA(0.00)[]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; IP_SCORE(0.37)[asn: 206006(1.79), country: PL(0.07)]; ASN(0.00)[asn:206006, ipnet:2001:678:618::/48, country:PL]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 29 Jan 2020 07:30:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --o2Acsl9JZohj43FuWj66sel8DVnStjgjR Content-Type: multipart/mixed; boundary="f0brc4kUcl1dHV9Puoe0NCqmkXd8EMEmK"; protected-headers="v1" From: Marek Zarychta To: freebsd-current@freebsd.org Message-ID: <9079b2c2-d055-f304-0744-215e2573e291@plan-b.pwste.edu.pl> Subject: Re: btxld not found References: <71165653-E6AA-46F7-B7F6-B5293ADC9779.ref@yahoo.com> <71165653-E6AA-46F7-B7F6-B5293ADC9779@yahoo.com> In-Reply-To: --f0brc4kUcl1dHV9Puoe0NCqmkXd8EMEmK Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable W dniu 28.01.2020 o=C2=A023:22, Kyle Evans pisze: > On Tue, Jan 28, 2020 at 3:28 PM Kyle Evans wrote: >> >> On Tue, Jan 28, 2020 at 2:15 PM Mark Millard wrote= : >>> >>> Marek Zarychta zarychtam at plan-b.pwste.edu.pl wrote on >>> Tue Jan 28 19:33:45 UTC 2020 : >>> >>>> W dniu 28.01.2020 o 19:11, Dimitry Andric pisze: >>>>> On 28 Jan 2020, at 12:36, Nick Hibma wr= ote: >>>>>> >>>>>> Could anyone explain to me what I am doing wrong? make installworl= d fails each time with the following error >>>>>> >>>>>> =3D=3D=3D> stand/i386/libi386 (install) >>>>>> =3D=3D=3D> stand/i386/loader_4th (install) >>>>>> strip -R .comment -R .note -o loader_4th.bin loader_4th.sym >>>>>> btxld -v -f aout -e 0x200000 -o loader_4th -l /usr/obj/usr/src/i38= 6.i386/stand/i386/btx/btxldr/btxldr -b /usr/obj/usr/src/i386.i386/stand/= i386/btx/btx/btx loader_4th.bin >>>>>> make[6]: exec(btxld) failed (No such file or directory) >>>>>> *** Error code 1 >>>>>> >>>>>> This is with source of last week. I had this problem before (from = old sources) and fixed it by specifying the full path to btxld in the sta= nd/i386/*/Makefile. >>>>> >>>>> Yes, this is most likely your clock(s) being off. At installworld = time, >>>>> it should *not* start rebuilding your loader. >>>>> >>>>> Usually this happens if you build on one machine, and install on >>>>> another, while the install machine's time is behind the build machi= ne's >>>>> time. But it can also happens on one machine, for instance if you >>>>> start in single user mode, and the clock is not yet synchronized. >>>>> >>>>> -Dimitry >>>>> >>>> >>>> I build and install on the same machine, WITH_META_MODE=3Dyes >>> . . . >>> >>> Same here on a ThreadRipper 1950X: a self hosted build and >>> install gets the issue at install time. WITH_META_MODE in use. >>> >>> Never started in single user mode. Also happens for targeting a >>> local directory tree in the install, instead of updating the >>> live system. (A directory tree used later with poudriere.) >>> >>> https://lists.freebsd.org/pipermail/freebsd-toolchain/2019-December/0= 05130.html >>> >>> has some timestamps that I observed. btxld.full was about 27 >>> seconds later in the file system than btxld.meta, btxld.debug, >>> and such (until I rebuilt). >>> >>> Looks to me more like multiple parallel builds that stomp on >>> each other. >>> >> >> I suspect y'all want something like the following: >> >=20 > Sorry, that patch is clearly wrong- here's take two. A lot of these > have dependencies on btxldr that aren't formally described in the > targets, so I missed... a lot. New version just builds btx first gated > behind a .WAIT then parallel the rest. >=20 > diff --git a/stand/i386/Makefile b/stand/i386/Makefile > index a9d402acf60..24255eefabf 100644 > --- a/stand/i386/Makefile > +++ b/stand/i386/Makefile > @@ -4,7 +4,10 @@ NO_OBJ=3Dt >=20 > .include >=20 > -SUBDIR.yes=3D mbr pmbr boot0 boot0sio btx boot2 cdboot gptboot \ > +# Almost everything else here relies on btxldr, so we must make sure i= t's built > +# before everything else proceeds so we don't end up building against = a stale > +# btxldr and ending up with a build-during-install scenario. > +SUBDIR.yes=3D btx .WAIT mbr pmbr boot0 boot0sio boot2 cdboot gptboo= t \ > isoboot libi386 >=20 > SUBDIR.${MK_LOADER_FIREWIRE}+=3D libfirewire > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" >=20 I have not correctly applied the patch. I am sorry for the confusion. The world builds fine with this second patch. I am not able to reproduce the original error anymore (buildworld and installworld after that, both go fine even with unpatched stand/i386/Makefile b/stand/i386/Makefile). --=20 Marek Zarychta --f0brc4kUcl1dHV9Puoe0NCqmkXd8EMEmK-- --o2Acsl9JZohj43FuWj66sel8DVnStjgjR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEMOqvKm6wKvS1/ZeCdZ/s//1SjSwFAl4xNJcACgkQdZ/s//1S jSywBgf/UU9TnFMDdQ+FY5GG7G8QKHssnwDW2YUON1HGYVj68cYnIVCbWkV+e63G SY1ABu9AH9pFZsIAzuapNnPL30Hp83KqdKbiIOug3gopm8TI4MZXoGW01zNooenZ MbVP0Gww8vpzQ00o6LN3Qxo8YqCLChkFtjoR+oA6cAe0GJNVnUpYqhh7VJxtNTgV ALV/y+9QxF3oG0bCxIqMSEjLDPs/zGgUvjM4g8ja353HmUWKvbEXJD268SIz8cbJ LTMZ9JLJQmL8ht6vuIRVLSzIKbCI7oVv/j/HyQR+sQLs44OTnB8CxQZ+G4FpdeO2 JzwKcC1o4GBQfDem7AQk8teV4fcG+w== =W6x+ -----END PGP SIGNATURE----- --o2Acsl9JZohj43FuWj66sel8DVnStjgjR-- From owner-freebsd-current@freebsd.org Wed Jan 29 09:23:52 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id AF7481D081A for ; Wed, 29 Jan 2020 09:23:52 +0000 (UTC) (envelope-from nick@van-laarhoven.org) Received: from violet.van-laarhoven.org (violet.van-laarhoven.org [195.201.116.25]) by mx1.freebsd.org (Postfix) with ESMTP id 486yj44GFYz4LlM; Wed, 29 Jan 2020 09:23:52 +0000 (UTC) (envelope-from nick@van-laarhoven.org) Received: from [192.168.178.139] (D4B295F2.static.ziggozakelijk.nl [212.178.149.242]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by violet.van-laarhoven.org (Postfix) with ESMTPSA id 365CF9CF6D; Wed, 29 Jan 2020 10:23:45 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Subject: Re: btxld not found From: Nick Hibma In-Reply-To: <42284B22-BACD-47E7-A9E0-75B7AC5B6C9C@FreeBSD.org> Date: Wed, 29 Jan 2020 10:23:44 +0100 Cc: FreeBSD Current Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: References: <8B42F93A-7B9E-4F99-9D77-43DA3BB7F045@van-laarhoven.org> <42284B22-BACD-47E7-A9E0-75B7AC5B6C9C@FreeBSD.org> To: Dimitry Andric X-Mailer: Apple Mail (2.3608.40.2.2.4) X-Rspamd-Queue-Id: 486yj44GFYz4LlM X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 29 Jan 2020 09:23:52 -0000 >> Could anyone explain to me what I am doing wrong? make installworld = fails each time with the following error >>=20 >> =3D=3D=3D> stand/i386/libi386 (install) >> =3D=3D=3D> stand/i386/loader_4th (install) >> strip -R .comment -R .note -o loader_4th.bin loader_4th.sym >> btxld -v -f aout -e 0x200000 -o loader_4th -l = /usr/obj/usr/src/i386.i386/stand/i386/btx/btxldr/btxldr -b = /usr/obj/usr/src/i386.i386/stand/i386/btx/btx/btx loader_4th.bin >> make[6]: exec(btxld) failed (No such file or directory) >> *** Error code 1 >>=20 >> This is with source of last week. I had this problem before (from old = sources) and fixed it by specifying the full path to btxld in the = stand/i386/*/Makefile. >=20 > Yes, this is most likely your clock(s) being off. At installworld = time, > it should *not* start rebuilding your loader. >=20 > Usually this happens if you build on one machine, and install on > another, while the install machine's time is behind the build = machine's > time. But it can also happens on one machine, for instance if you > start in single user mode, and the clock is not yet synchronized. >=20 > -Dimitry >=20 Dimitry,=20 My VirtualBox VMs do have a tendency to lag when I am not using them for = a while. I've adjusted time and started ntpd. In the past that would not = fix the time lag permanently. I'll do a fresh buildworld and see whether that completes. Nick= From owner-freebsd-current@freebsd.org Wed Jan 29 13:43:51 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D95751F0E8F for ; Wed, 29 Jan 2020 13:43:51 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4874T35TnDz4c6D; Wed, 29 Jan 2020 13:43:51 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qk1-f177.google.com (mail-qk1-f177.google.com [209.85.222.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id A78CF7040; Wed, 29 Jan 2020 13:43:51 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qk1-f177.google.com with SMTP id v195so16963755qkb.11; Wed, 29 Jan 2020 05:43:51 -0800 (PST) X-Gm-Message-State: APjAAAWqw1aVHtnQNmLyqjCK5Hy67MaI7AXG8gIBF8fE1ChK+dXNjOjX OoBnZyLWjovoKh2p896sPtoHrHF+i+7f4QjXpwA= X-Google-Smtp-Source: APXvYqx/h61dV9xaSAScuVJkpqMWW9H3oxnVNNpTfOuQtZaiHyH17BsPBwTiJdEkkqNbI29brRDjCoX1ubXEYVtdOMg= X-Received: by 2002:ae9:e10e:: with SMTP id g14mr28948910qkm.430.1580305431007; Wed, 29 Jan 2020 05:43:51 -0800 (PST) MIME-Version: 1.0 References: <8B42F93A-7B9E-4F99-9D77-43DA3BB7F045@van-laarhoven.org> <42284B22-BACD-47E7-A9E0-75B7AC5B6C9C@FreeBSD.org> In-Reply-To: From: Kyle Evans Date: Wed, 29 Jan 2020 07:43:39 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: btxld not found To: Nick Hibma Cc: Dimitry Andric , FreeBSD Current Mailing List Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 29 Jan 2020 13:43:51 -0000 On Wed, Jan 29, 2020 at 3:24 AM Nick Hibma wrote: > > >> Could anyone explain to me what I am doing wrong? make installworld fails each time with the following error > >> > >> ===> stand/i386/libi386 (install) > >> ===> stand/i386/loader_4th (install) > >> strip -R .comment -R .note -o loader_4th.bin loader_4th.sym > >> btxld -v -f aout -e 0x200000 -o loader_4th -l /usr/obj/usr/src/i386.i386/stand/i386/btx/btxldr/btxldr -b /usr/obj/usr/src/i386.i386/stand/i386/btx/btx/btx loader_4th.bin > >> make[6]: exec(btxld) failed (No such file or directory) > >> *** Error code 1 > >> > >> This is with source of last week. I had this problem before (from old sources) and fixed it by specifying the full path to btxld in the stand/i386/*/Makefile. > > > > Yes, this is most likely your clock(s) being off. At installworld time, > > it should *not* start rebuilding your loader. > > > > Usually this happens if you build on one machine, and install on > > another, while the install machine's time is behind the build machine's > > time. But it can also happens on one machine, for instance if you > > start in single user mode, and the clock is not yet synchronized. > > > > -Dimitry > > > Dimitry, > > My VirtualBox VMs do have a tendency to lag when I am not using them for a while. I've adjusted time and started ntpd. In the past that would not fix the time lag permanently. > > I'll do a fresh buildworld and see whether that completes. > I mentioned this elsewhere, but I've opened a review in the past ~12 hours that should make sure that stand/ dependencies are properly ordered: https://reviews.freebsd.org/D23411 -> this should also alleviate the condition if we're building this stuff in parallel. Thanks, Kyle Evans From owner-freebsd-current@freebsd.org Wed Jan 29 15:32:31 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B1C8E1F351C for ; Wed, 29 Jan 2020 15:32:31 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4876tR3Jjpz3DbH for ; Wed, 29 Jan 2020 15:32:31 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mailman.nyi.freebsd.org (Postfix) id 719831F351B; Wed, 29 Jan 2020 15:32:31 +0000 (UTC) Delivered-To: current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7158D1F351A for ; Wed, 29 Jan 2020 15:32:31 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4876tQ49Mjz3Db9 for ; Wed, 29 Jan 2020 15:32:30 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wm1-x334.google.com with SMTP id c84so198637wme.4 for ; Wed, 29 Jan 2020 07:32:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:subject:message-id:reply-to:mime-version :content-transfer-encoding; bh=vd8YBp0Pssg3hzwk1miiSRglZqRMlK2u/1uI2RtzZ+k=; b=X14+IBGJ2UFe2d7KFZrcprzNchJhTRw5NJzpAMd3LgwcIAcOPr//H6FXgo53T3p4ZB 1UZRC1xMdjueSGV4jmLtk411PpRAPS9gnqQrT8j8skCDUdKse0jBwdoia3dLgBXbNTtW 6NRrezv8Hmb+HcezC94/hPRzr1hYhijrqeX3DKL0BflXVIU4rlVplhSS4hMPYMmry3ti DeCyRhpOBtaqMZ+RZIMlkUSziYzNEVNA321YPjo+mXiU4qmPhyOzKw/L73omwHVvGrLe f/eWoyq3/EvOA15MOnkXlZg5lvkFTotoGe7q8ZbfzfX3Yye102a5djaJQkmjhQuYvb9U Tb/w== 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:subject:message-id:reply-to :mime-version:content-transfer-encoding; bh=vd8YBp0Pssg3hzwk1miiSRglZqRMlK2u/1uI2RtzZ+k=; b=QR3J5KkPR9/G/tOtTM4SZNHOONZgyZK/hfhLXW/WQYy5kV2mQPjMS+ITmYXEQ6CtK9 /lhifPtSA8sQF2KvqIRGsngThF4lY+/To7RT/CC+t40R5yWtRmn3fw8RHsFbmcWSMoGK INykPoVwbyr9Ae3LlDcHUmUkj7kuwMulladppz4a/p5F7qyHvMz5p1abpAS4p/ircktf vxmYgrzTLqCVOMgXOPP0DC9OdmOqaDDG1cYrvyyEF/pkpAfafPWiRleOw+88SjTz/WDV zzvLIRNCRiGjM4+Dxy6/Y0oXNDDn4PkAlSAruJsoeUYbvsda9mR4rGsgqpMvcnySPgzl JHtA== X-Gm-Message-State: APjAAAVHHnx08CkmkdeBSaGW0RPFlZvqnoDkhepxLmy6EdibuZ5hEBXt ZD53btbIf5cOMGcXVfVZ1KsD0stl X-Google-Smtp-Source: APXvYqztuY0prUlq2xp5MExUhm6o73+y5RbMSZwhGbiL7T9TmwzbxwqR/VBFa1QHNYkNuJB2RbpzjA== X-Received: by 2002:a1c:541b:: with SMTP id i27mr13048447wmb.137.1580311948979; Wed, 29 Jan 2020 07:32:28 -0800 (PST) Received: from ernst.home (p5B02394F.dip0.t-ipconnect.de. [91.2.57.79]) by smtp.gmail.com with ESMTPSA id g18sm2558822wmh.48.2020.01.29.07.32.28 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Jan 2020 07:32:28 -0800 (PST) Date: Wed, 29 Jan 2020 16:32:27 +0100 From: Gary Jennejohn To: current@freebsd.org Subject: error installing openssl cat5/cat7 man pages Message-ID: <20200129163227.73857d73@ernst.home> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; amd64-portbld-freebsd13.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4876tQ49Mjz3Db9 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=X14+IBGJ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of gljennjohn@gmail.com designates 2a00:1450:4864:20::334 as permitted sender) smtp.mailfrom=gljennjohn@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[gljennjohn@gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RECEIVED_SPAMHAUS_PBL(0.00)[79.57.2.91.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; FREEMAIL_REPLYTO(0.00)[gmail.com]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(0.00)[ip: (-8.73), ipnet: 2a00:1450::/32(-2.52), asn: 15169(-1.78), country: US(-0.05)]; RCVD_IN_DNSWL_NONE(0.00)[4.3.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 29 Jan 2020 15:32:31 -0000 My src tree is at r357254. I just did ``make buildworld'', rebooted and then did ``make installworld'' installworld failed while trying to install the openssl cat man pages. It first complained that it couldn't find /usr/share/openssl/man/cat5 and then (after I created cat5) that it couldn't find /usr/share/openssl/man/cat7. The installation succeeded once I had created the missing directories. I did not do a clean makeworld, but I don't see how that could affect the installation. Anyway, I don't know where these cat{5,7} directories are supposed to be created, but something seems to be missing (at least on my system). -- Gary Jennejohn From owner-freebsd-current@freebsd.org Wed Jan 29 15:35:34 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6D4891F3952 for ; Wed, 29 Jan 2020 15:35:34 +0000 (UTC) (envelope-from nick@van-laarhoven.org) Received: from violet.van-laarhoven.org (violet.van-laarhoven.org [IPv6:2a01:4f8:1c0c:72ba::3]) by mx1.freebsd.org (Postfix) with ESMTP id 4876xx3s4Zz3F0p; Wed, 29 Jan 2020 15:35:33 +0000 (UTC) (envelope-from nick@van-laarhoven.org) Received: from [192.168.178.139] (D4B295F2.static.ziggozakelijk.nl [212.178.149.242]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by violet.van-laarhoven.org (Postfix) with ESMTPSA id 90E639CD28; Wed, 29 Jan 2020 16:35:24 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Subject: Re: btxld not found From: Nick Hibma In-Reply-To: Date: Wed, 29 Jan 2020 16:35:23 +0100 Cc: FreeBSD Current Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: <4817FF98-E0C8-4A8F-8D56-CBD0BA5311C4@van-laarhoven.org> References: <8B42F93A-7B9E-4F99-9D77-43DA3BB7F045@van-laarhoven.org> <42284B22-BACD-47E7-A9E0-75B7AC5B6C9C@FreeBSD.org> To: Dimitry Andric X-Mailer: Apple Mail (2.3608.40.2.2.4) X-Rspamd-Queue-Id: 4876xx3s4Zz3F0p X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of nick@van-laarhoven.org designates 2a01:4f8:1c0c:72ba::3 as permitted sender) smtp.mailfrom=nick@van-laarhoven.org X-Spamd-Result: default: False [-2.52 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; MV_CASE(0.50)[]; DMARC_NA(0.00)[van-laarhoven.org]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; IP_SCORE(-0.82)[ipnet: 2a01:4f8::/29(-2.53), asn: 24940(-1.54), country: DE(-0.02)]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 29 Jan 2020 15:35:34 -0000 >=20 >>> Could anyone explain to me what I am doing wrong? make installworld = fails each time with the following error >>>=20 >>> =3D=3D=3D> stand/i386/libi386 (install) >>> =3D=3D=3D> stand/i386/loader_4th (install) >>> strip -R .comment -R .note -o loader_4th.bin loader_4th.sym >>> btxld -v -f aout -e 0x200000 -o loader_4th -l = /usr/obj/usr/src/i386.i386/stand/i386/btx/btxldr/btxldr -b = /usr/obj/usr/src/i386.i386/stand/i386/btx/btx/btx loader_4th.bin >>> make[6]: exec(btxld) failed (No such file or directory) >>> *** Error code 1 >>>=20 >>> This is with source of last week. I had this problem before (from = old sources) and fixed it by specifying the full path to btxld in the = stand/i386/*/Makefile. >>=20 >> Yes, this is most likely your clock(s) being off. At installworld = time, >> it should *not* start rebuilding your loader. >>=20 >> Usually this happens if you build on one machine, and install on >> another, while the install machine's time is behind the build = machine's >> time. But it can also happens on one machine, for instance if you >> start in single user mode, and the clock is not yet synchronized. >>=20 >> -Dimitry >>=20 > Dimitry,=20 >=20 > My VirtualBox VMs do have a tendency to lag when I am not using them = for a while. I've adjusted time and started ntpd. In the past that would = not fix the time lag permanently. >=20 > I'll do a fresh buildworld and see whether that completes. >=20 > Nick Nope, make buildworld && make installworld results in, so I guess the = job ordering suggestion is a better one (VM with 2 processors on a = variably loaded laptop, no -j option, time accurate): install -o root -g wheel -m 444 mbr /boot/mbr =3D=3D=3D> stand/i386/pmbr (install) install -o root -g wheel -m 444 pmbr /boot/pmbr =3D=3D=3D> stand/i386/boot0 (install) install -o root -g wheel -m 444 boot0 /boot/boot0 =3D=3D=3D> stand/i386/boot0sio (install) install -o root -g wheel -m 444 boot0 /boot/boot0sio =3D=3D=3D> stand/i386/btx (install) =3D=3D=3D> stand/i386/btx/btx (install) =3D=3D=3D> stand/i386/btx/btxldr (install) =3D=3D=3D> stand/i386/btx/lib (install) =3D=3D=3D> stand/i386/boot2 (install) objcopy -S -O binary boot1.out boot1 objcopy -S -O binary boot2.out boot2.bin btxld -v -E 0x2000 -f bin -b = /usr/obj/usr/src/i386.i386/stand/i386/btx/btx/btx -l boot2.ldr -o = boot2.ld -P 1 boot2.bin make[6]: exec(btxld) failed (No such file or directory) *** Error code 1 ... {e}nick@fimkjecurrent:/usr/src % sudo find / -name btxld -type f -ls 1908308 48 -r-xr-xr-x 1 root wheel = 22988 Jan 27 23:37 /usr/sbin/btxld 3441268 52 -rwxr-xr-x 1 root wheel = 25816 Jan 29 16:09 = /usr/obj/usr/src/i386.i386/usr.sbin/btxld/btxld {e}nick@fimkjecurrent:/usr/src % date Wed Jan 29 16:30:21 CET 2020 {e}nick@fimkjecurrent:/usr/src % make -dA ... Global:MFLAGS =3D -d A job_pipe -1 -1, maxjobs 1, tokens 1, compat 1 ...= From owner-freebsd-current@freebsd.org Thu Jan 30 23:23:06 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 83F9A22AFFA for ; Thu, 30 Jan 2020 23:23:06 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660062.outbound.protection.outlook.com [40.107.66.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 487xGw5y2Vz3KfB for ; Thu, 30 Jan 2020 23:23:04 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ECQNN+mF1i56mXOK87iwYdMJIK0wD6x85CyS04n2HetbnngsnZii26hGeC0rsRyEZdt1jY3VFGpiAnIswD1f1tS0xDJfMnOtx1LO+CLOr3MOQanYy3UwBPqj0dCBM5ePOSc7fpuYJ7jfPaFXuLZVI1J7Eb10QKT4cHXOnjZEjNX0lg7koGHNo2AbGhmJCcIIaCWqth0x4x6F6P+HSvEGiCNF81vnR9o5SPNPtjwm+VlYJyaXiqpxq+/5ZhfCk09/Cm6dkqTAYHO67X28bkFX6Ea/Wg6r3EgNjZXMu4IxdYqYMzrgiwyOgtjVhnGcxs0fmJgXvlbtc3/Hbg4UQlC+yA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FYAr5MYkhhPygcKseSdqMwHyi5O6ZH6N+4waQJBpvwU=; b=dDfCLXhJ+koXLA8zEd29cbN3mkaW/atLkBZECM8iwBLLFx7P4duhe2Bq2D2C9FhvtYAQ5OA/+P6mNOF891Em+ZWiD4emDbrARpmRaA2V6Ap9K/omz9AqjSo97rSGxWBqoCo1ATi216CbjefRSoOyqBGLqpAiDY74+AmY95b27IkyCPRamPRm7i3Y+AQzOfH9aRrz1P3mRxPhqn7gDsuDJPzLL0gDfTWLF8DaFwFPxTvgl38ktdqs7X0Lz4Od/Q0OFVMTFIxiae0slBzFPxZkSurFNQRE6LlSMWxwu4p3hf/giwqDRP3Df8XrBPLO9eKk06rXe4sgSR41yPU6lOYunA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none Received: from YTBPR01MB3374.CANPRD01.PROD.OUTLOOK.COM (10.255.46.82) by YTBPR01MB3565.CANPRD01.PROD.OUTLOOK.COM (10.255.46.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.22; Thu, 30 Jan 2020 23:23:02 +0000 Received: from YTBPR01MB3374.CANPRD01.PROD.OUTLOOK.COM ([fe80::410e:652b:6fbc:9aa4]) by YTBPR01MB3374.CANPRD01.PROD.OUTLOOK.COM ([fe80::410e:652b:6fbc:9aa4%3]) with mapi id 15.20.2686.025; Thu, 30 Jan 2020 23:23:02 +0000 From: Rick Macklem To: "freebsd-current@FreeBSD.org" Subject: easy way to work around a lack of a direct map on i386 Thread-Topic: easy way to work around a lack of a direct map on i386 Thread-Index: AQHV18KXJBNJQhyzKEGjuJj0X3dTjA== Date: Thu, 30 Jan 2020 23:23:02 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1d434aa0-035b-4674-db97-08d7a5db5a6d x-ms-traffictypediagnostic: YTBPR01MB3565: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 02981BE340 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(376002)(346002)(396003)(39860400002)(366004)(199004)(189003)(86362001)(7696005)(33656002)(8676002)(81156014)(81166006)(8936002)(91956017)(4744005)(64756008)(76116006)(66556008)(6506007)(66446008)(66476007)(186003)(66946007)(71200400001)(26005)(6916009)(478600001)(2906002)(55016002)(9686003)(52536014)(316002)(786003)(5660300002)(43043002); DIR:OUT; SFP:1101; SCL:1; SRVR:YTBPR01MB3565; H:YTBPR01MB3374.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-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ear9cipBbssSA5MJ6iUbI8+iv4z4ZN2c+xC54+bscy0rYObcvQ23jF+9TPZXdOXNVyBBvGMaBXX6RwyPFe2Ccqfl7Ig8kI4o3sar9OPpyqkkfdfsKjYsZuUkxLGL9zB2vQ6HPb8ocBiAMFrF4aiww93qOgvhnPV1dJNz74HJ7EyS1XBmct9RUinWhAwTFoxsPAH732leI57YodZrXamVs4I+5jKtAtXLzc2sv/oYLwAEz8h8tfpqyH1bvIc5j2vLc6/rMSXBmr/HJWVZR59/7G9wFakFxfQDv3KQc35fh7bVebGVaT+2OkH2YENe5XbVIJwf5D95pReymxZx3ahbHjpipEKzyhel/TtC1beWXtcpFdFD0iOa84yLVMa3em+SDP6lHbCaUUQqMzSivSkTEXjWSQ9LAtL0sMAUFq32uxoinZugN1g4YzPgqrze5588MOG+Vn7SCB4/p4X4CUnMvBOwO4++hDGE5SZYFkt+hMI= x-ms-exchange-antispam-messagedata: WIR6UaKM7w+Ih0CF6XNiGfKMjLuYZBso0L/La5/fTXjqbdGgua+GejbWVy1aW2t8F8qfMNdh6/y+gmMj1utIbVKEpKXpR7vWXKXXMqosvW4YmX0ZBr4QspyUDlQ0j9K94O+ncIq8dSVJ0ySG7NoTVA== x-ms-exchange-transport-forked: True 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: 1d434aa0-035b-4674-db97-08d7a5db5a6d X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jan 2020 23:23:02.8775 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: CQ3lJUJpTNkZEONk/EyU6qzNxHUHPfOuMj8N2rlAvKwJF/Mb3vyh/M0mVjDCv/XJSA0/uKlcEpBcf6SCUzHwOQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTBPR01MB3565 X-Rspamd-Queue-Id: 487xGw5y2Vz3KfB X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.66.62 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-4.69 / 15.00]; RCVD_TLS_LAST(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[uoguelph.ca]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; IP_SCORE(-1.39)[ipnet: 40.64.0.0/10(-3.85), asn: 8075(-3.06), country: US(-0.05)]; RCVD_IN_DNSWL_NONE(0.00)[62.66.107.40.list.dnswl.org : 127.0.3.0]; TO_DN_EQ_ADDR_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:8075, ipnet:40.64.0.0/10, country:US]; ARC_ALLOW(-1.00)[i=1] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 30 Jan 2020 23:23:06 -0000 Hi,=0A= =0A= The current code for KERN_TLS uses PHYS_TO_DMAP()=0A= to access unmapped external pages on m_ext.ext_pgs=0A= mbufs.=0A= I also need to do this to implement RPC-over-TLS.=0A= =0A= The problem is that some arches, like i386, don't=0A= support PHYS_TO_DMAP().=0A= =0A= Since it appears that there will be at most 4 pages on=0A= one of these mbufs, my thinking was...=0A= - Acquire four pages of kva from the kernel_map during=0A= booting.=0A= - Then just use pmap_qenter() to fill in the physical page=0A= mappings for long enough to copy the data.=0A= =0A= Does this sound reasonable?=0A= Is there a better way?=0A= =0A= Thanks for your comments, rick=0A= From owner-freebsd-current@freebsd.org Thu Jan 30 23:37:45 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 43DDD22BD07 for ; Thu, 30 Jan 2020 23:37:45 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 487xbr05pmz3LNl for ; Thu, 30 Jan 2020 23:37:43 +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 00UNbYst058255 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 31 Jan 2020 01:37:37 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 00UNbYst058255 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id 00UNbYb3058254; Fri, 31 Jan 2020 01:37:34 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 31 Jan 2020 01:37:34 +0200 From: Konstantin Belousov To: Rick Macklem Cc: "freebsd-current@FreeBSD.org" Subject: Re: easy way to work around a lack of a direct map on i386 Message-ID: <20200130233734.GV4808@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.3 X-Spam-Checker-Version: SpamAssassin 3.4.3 (2019-12-06) on tom.home X-Rspamd-Queue-Id: 487xbr05pmz3LNl X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_SPF_SOFTFAIL(0.00)[~all:c]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; IP_SCORE(0.00)[ip: (-3.16), ipnet: 2001:470::/32(-4.66), asn: 6939(-3.58), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 30 Jan 2020 23:37:45 -0000 On Thu, Jan 30, 2020 at 11:23:02PM +0000, Rick Macklem wrote: > Hi, > > The current code for KERN_TLS uses PHYS_TO_DMAP() > to access unmapped external pages on m_ext.ext_pgs > mbufs. > I also need to do this to implement RPC-over-TLS. > > The problem is that some arches, like i386, don't > support PHYS_TO_DMAP(). > > Since it appears that there will be at most 4 pages on > one of these mbufs, my thinking was... > - Acquire four pages of kva from the kernel_map during > booting. > - Then just use pmap_qenter() to fill in the physical page > mappings for long enough to copy the data. > > Does this sound reasonable? > Is there a better way? Use sfbufs, they should work on all arches. In essence, they provide MI interface to DMAP where possible. I do not remember did I bumped the limit for i386 after 4/4 went in. There is currently no limits for sfbufs use per subsystem, but I think it is not very likely to cause too much troubles. Main rule is to not sleep waiting for more sfbufs if you already own one.. From owner-freebsd-current@freebsd.org Fri Jan 31 04:18:49 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 579032320A1 for ; Fri, 31 Jan 2020 04:18:49 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4883r82Yrbz44b7; Fri, 31 Jan 2020 04:18:47 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00V4IhgO009874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 30 Jan 2020 23:18:46 -0500 Date: Thu, 30 Jan 2020 20:18:43 -0800 From: Benjamin Kaduk To: Rick Macklem Cc: John Baldwin , "freebsd-current@FreeBSD.org" Subject: Re: how to use the ktls Message-ID: <20200131041843.GC24@kduck.mit.edu> References: <5be57c87-90fe-fcbe-ea37-bdb1bcff2da8@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) X-Rspamd-Queue-Id: 4883r82Yrbz44b7 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of kaduk@mit.edu designates 18.9.28.11 as permitted sender) smtp.mailfrom=kaduk@mit.edu X-Spamd-Result: default: False [-5.39 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:18.9.28.0/24]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[mit.edu]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[11.28.9.18.list.dnswl.org : 127.0.11.2]; IP_SCORE(-2.89)[ip: (-9.60), ipnet: 18.9.0.0/16(-4.79), asn: 3(-0.03), country: US(-0.05)]; RWL_MAILSPIKE_POSSIBLE(0.00)[11.28.9.18.rep.mailspike.net : 127.0.0.17]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:3, ipnet:18.9.0.0/16, country:US]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 31 Jan 2020 04:18:49 -0000 On Tue, Jan 28, 2020 at 11:01:31PM +0000, Rick Macklem wrote: > John Baldwin wrote: > [stuff snipped] > >I don't know yet. :-/ With the TOE-based TLS I had been testing with, this doesn't > >happen because the NIC blocks the data until it gets the key and then it's always > >available via KTLS. With software-based KTLS for RX (which I'm going to start > >working on soon), this won't be the case and you will potentially have some data > >already ready by OpenSSL that needs to be drained from OpenSSL before you can > >depend on KTLS. It's probably only the first few messsages, but I will need to figure > >out a way that you can tell how much pending data in userland you need to read via > >SSL_read() and then pass back into the kernel before relying on KTLS (it would just > >be a single chunk of data after SSL_connect you would have to do this for). > I think SSL_read() ends up calling ssl3_read_bytes(..APPLICATION..) and then it throws > away non-application data records. (Not sure, ssl3_read_bytes() gets pretty convoluted at > a glance.;-) Yes, SSL_read() interprets the TLS record type and only passes application data records through to the application. It doesn't exactly "throw away" the other records, though -- they still get processed, just internally to libssl :) I expect based on heuristics that the 485 bytes are a NewSessionTicket message, but that actual length is very much not a protocol constant and is an implementation detail of the TLS server. (That said, an openssl server is going to be producing the same length every time, for a given version of openssl, unless you configure it otherwise.) -Ben From owner-freebsd-current@freebsd.org Fri Jan 31 06:34:52 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2FE75234ECB for ; Fri, 31 Jan 2020 06:34:52 +0000 (UTC) (envelope-from clay.daniels.jr@gmail.com) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4886s71NBpz4BFV for ; Fri, 31 Jan 2020 06:34:51 +0000 (UTC) (envelope-from clay.daniels.jr@gmail.com) Received: by mail-lf1-x12c.google.com with SMTP id f24so4067694lfh.3 for ; Thu, 30 Jan 2020 22:34:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=mYJ0G3n4RTNmzslFnvPdNGAyZVcQRKmhaeY8FR6zt1U=; b=TAyzSFecHVN+aUO87uYMgBx4dC2qkExZpachu6FT8MxdDihs1zTmCTkofRcyEsHb9U Y83000KDBxtqLM578K4jj3NqGuPRJSKLSmnu601jJB2ZTFOz4joPWXSTrSc9iEeItou1 Fl6uD3xY0I3oUGR9ghMr4ceDLlrbi21A2uQHwQpJfDUNVXqU3Kk0ABRtXsYErCa7ODaJ TcTz6fZsoave8TVKQ8YFP/yuWRLLVHVWRA6TZEtDxaVHUceNP4MBUh4jIwJRRkFArTwa zyVclJUUyI2DBsL2a9Na2ewar1sbtGjj2GdBkkrJwtcrGvERaWD2NX/KOMXMFBjvGQyd rv6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=mYJ0G3n4RTNmzslFnvPdNGAyZVcQRKmhaeY8FR6zt1U=; b=kVPpKfQlgx98fhSU1RkqdIjWpesf04N/nuDYODG9PNQvhZHBWgg9Cx7mCTlLUvFari VBrul4cnXmX9Hxvfm5V7rFQhjwfbfFz6ERBQCW2VR+T3BI73zTz8p9WSstOld1SmNIaB 21UOXJmXhkfazQ0mDMt6PF324m0yqSxo3ddeNnmC+ADZ0U9n4WARAYx9Jz6MvwiMHewd hViRotXOLQJY/DNI58yQ3K4xCbz1EnDry6krBbF26HM2bZsMTAkE1N6Dz3qaqLMFLxL6 l+eUinMYj/a63/jXHlTd7XXoJvdldXvDgnTbalWSOkihbl/iZxyGI6oaGz89QcDFzoDg NgaQ== X-Gm-Message-State: APjAAAWYgIf9RYBURZVmr8lHPhcj5eNW4XmDgzpX0t9GQqhFTM2PqJtE URc+7huNy6uMWAEkImTJbVpJWoUWflhC8tRjWRUvH+kf/Q== X-Google-Smtp-Source: APXvYqzJL3dUQrlJZc6IntvlEgEH5dGf/MfWsE/n8T9I9jV5IEQfyODcc/ra/KlA+V/h2OdJIa1HbFtSiiUPVIUDdgo= X-Received: by 2002:ac2:5282:: with SMTP id q2mr4590502lfm.17.1580452488331; Thu, 30 Jan 2020 22:34:48 -0800 (PST) MIME-Version: 1.0 From: Clay Daniels Date: Fri, 31 Jan 2020 00:34:37 -0600 Message-ID: Subject: kyua test To: "freebsd-current@freebsd.org" X-Rspamd-Queue-Id: 4886s71NBpz4BFV X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=TAyzSFec; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of claydanielsjr@gmail.com designates 2a00:1450:4864:20::12c as permitted sender) smtp.mailfrom=claydanielsjr@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_TWO(0.00)[2]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE_FREEMAIL(0.00)[]; IP_SCORE(0.00)[ip: (-9.38), ipnet: 2a00:1450::/32(-2.52), asn: 15169(-1.77), country: US(-0.05)]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[c.2.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; TO_DN_EQ_ADDR_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 31 Jan 2020 06:34:52 -0000 I've started running kyua test when I load the weekly current snapshot, and I'm a little confused about if I should run kyua test as user or root. In order to make the /usr/ports/devel/kyua port you need to be root and I have just been doing the test as root, but I notice in the instructions I'm using in the test(7) manpage it says: $ kyua test -k /usr/tests/Kyuafile Which suggested to me run as user with the $ (not #) Of course, when I run it as user as I'm doing right now, it skips some tests that are only for root. I guess I could use a little advice. Clay From owner-freebsd-current@freebsd.org Fri Jan 31 09:14:08 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B92BA2394BF for ; Fri, 31 Jan 2020 09:14:08 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 488BNv3L3mz4Kpf for ; Fri, 31 Jan 2020 09:14:06 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2020.home.selasky.org (unknown [62.141.129.235]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 1AB3026003E; Fri, 31 Jan 2020 10:14:03 +0100 (CET) Subject: Re: easy way to work around a lack of a direct map on i386 To: Konstantin Belousov , Rick Macklem Cc: "freebsd-current@FreeBSD.org" References: <20200130233734.GV4808@kib.kiev.ua> From: Hans Petter Selasky Message-ID: Date: Fri, 31 Jan 2020 10:13:58 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1 MIME-Version: 1.0 In-Reply-To: <20200130233734.GV4808@kib.kiev.ua> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 488BNv3L3mz4Kpf X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-5.42 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(-3.12)[ip: (-9.34), ipnet: 88.99.0.0/16(-4.71), asn: 24940(-1.55), country: DE(-0.02)]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 31 Jan 2020 09:14:08 -0000 On 2020-01-31 00:37, Konstantin Belousov wrote: > On Thu, Jan 30, 2020 at 11:23:02PM +0000, Rick Macklem wrote: >> Hi, >> >> The current code for KERN_TLS uses PHYS_TO_DMAP() >> to access unmapped external pages on m_ext.ext_pgs >> mbufs. >> I also need to do this to implement RPC-over-TLS. >> >> The problem is that some arches, like i386, don't >> support PHYS_TO_DMAP(). >> >> Since it appears that there will be at most 4 pages on >> one of these mbufs, my thinking was... >> - Acquire four pages of kva from the kernel_map during >> booting. >> - Then just use pmap_qenter() to fill in the physical page >> mappings for long enough to copy the data. >> >> Does this sound reasonable? >> Is there a better way? > > Use sfbufs, they should work on all arches. In essence, they provide MI > interface to DMAP where possible. I do not remember did I bumped the > limit for i386 after 4/4 went in. > > There is currently no limits for sfbufs use per subsystem, but I think it > is not very likely to cause too much troubles. Main rule is to not sleep > waiting for more sfbufs if you already own one.. In the DRM-KMS LinuxKPI we have: void * kmap(vm_page_t page) { #ifdef LINUXKPI_HAVE_DMAP vm_offset_t daddr; daddr = PHYS_TO_DMAP(VM_PAGE_TO_PHYS(page)); return ((void *)daddr); #else struct sf_buf *sf; sched_pin(); sf = sf_buf_alloc(page, SFB_NOWAIT | SFB_CPUPRIVATE); if (sf == NULL) { sched_unpin(); return (NULL); } return ((void *)sf_buf_kva(sf)); #endif } void kunmap(vm_page_t page) { #ifdef LINUXKPI_HAVE_DMAP /* NOP */ #else struct sf_buf *sf; /* lookup SF buffer in list */ sf = sf_buf_alloc(page, SFB_NOWAIT | SFB_CPUPRIVATE); /* double-free */ sf_buf_free(sf); sf_buf_free(sf); sched_unpin(); #endif } I think that is the fastest way to do this. --HPS From owner-freebsd-current@freebsd.org Fri Jan 31 12:25:01 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 225C723E8B3 for ; Fri, 31 Jan 2020 12:25:01 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 488Gd90B1Lz4XQT; Fri, 31 Jan 2020 12:25:01 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.codepro.be", Issuer "Let's Encrypt Authority X3" (verified OK)) (Authenticated sender: kp) by smtp.freebsd.org (Postfix) with ESMTPSA id DBC6F1C087; Fri, 31 Jan 2020 12:25:00 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from [192.168.183.1] (unknown [5.255.146.89]) (Authenticated sender: kp) by venus.codepro.be (Postfix) with ESMTPSA id 803BE4AEF5; Fri, 31 Jan 2020 13:24:59 +0100 (CET) From: "Kristof Provost" To: "Clay Daniels" Cc: freebsd-current@freebsd.org Subject: Re: kyua test Date: Fri, 31 Jan 2020 13:24:58 +0100 X-Mailer: MailMate (1.13.1r5671) Message-ID: <4E17DC37-023F-429F-8208-47B5A386EBB0@FreeBSD.org> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 31 Jan 2020 12:25:01 -0000 On 31 Jan 2020, at 7:34, Clay Daniels wrote: > I've started running kyua test when I load the weekly current > snapshot, and > I'm a little confused about if I should run kyua test as user or root. > In > order to make the /usr/ports/devel/kyua port you need to be root and I > have > just been doing the test as root, but I notice in the instructions I'm > using in the test(7) manpage it says: > > $ kyua test -k /usr/tests/Kyuafile > > Which suggested to me run as user with the $ (not #) > > Of course, when I run it as user as I'm doing right now, it skips some > tests that are only for root. I guess I could use a little advice. > Some tests require root, some do not. It depends on what you want to test. All tests that require root should announce this in their configuration, so running tests as a regular user should work, but you’ll end up with more skipped tests than if you run them as root. I personally mostly care about network (and specifically pf) tests, so I tend to always run them as root. If you care about (e.g.) grep tests they should just work as a regular user. Best regards, Kristof From owner-freebsd-current@freebsd.org Fri Jan 31 12:31:53 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D150923EE21 for ; Fri, 31 Jan 2020 12:31:53 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 488Gn5063hz4Y6y for ; Fri, 31 Jan 2020 12:31:52 +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 00VCVjAr081790 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 31 Jan 2020 14:31:48 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 00VCVjAr081790 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id 00VCViQv081789; Fri, 31 Jan 2020 14:31:44 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 31 Jan 2020 14:31:44 +0200 From: Konstantin Belousov To: Hans Petter Selasky Cc: Rick Macklem , "freebsd-current@FreeBSD.org" Subject: Re: easy way to work around a lack of a direct map on i386 Message-ID: <20200131123144.GW4808@kib.kiev.ua> References: <20200130233734.GV4808@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.3 X-Spam-Checker-Version: SpamAssassin 3.4.3 (2019-12-06) on tom.home X-Rspamd-Queue-Id: 488Gn5063hz4Y6y X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_SPF_SOFTFAIL(0.00)[~all]; IP_SCORE_FREEMAIL(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(0.00)[ip: (-3.15), ipnet: 2001:470::/32(-4.66), asn: 6939(-3.58), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 31 Jan 2020 12:31:53 -0000 On Fri, Jan 31, 2020 at 10:13:58AM +0100, Hans Petter Selasky wrote: > On 2020-01-31 00:37, Konstantin Belousov wrote: > > On Thu, Jan 30, 2020 at 11:23:02PM +0000, Rick Macklem wrote: > > > Hi, > > > > > > The current code for KERN_TLS uses PHYS_TO_DMAP() > > > to access unmapped external pages on m_ext.ext_pgs > > > mbufs. > > > I also need to do this to implement RPC-over-TLS. > > > > > > The problem is that some arches, like i386, don't > > > support PHYS_TO_DMAP(). > > > > > > Since it appears that there will be at most 4 pages on > > > one of these mbufs, my thinking was... > > > - Acquire four pages of kva from the kernel_map during > > > booting. > > > - Then just use pmap_qenter() to fill in the physical page > > > mappings for long enough to copy the data. > > > > > > Does this sound reasonable? > > > Is there a better way? > > > > Use sfbufs, they should work on all arches. In essence, they provide MI > > interface to DMAP where possible. I do not remember did I bumped the > > limit for i386 after 4/4 went in. > > > > There is currently no limits for sfbufs use per subsystem, but I think it > > is not very likely to cause too much troubles. Main rule is to not sleep > > waiting for more sfbufs if you already own one.. > > In the DRM-KMS LinuxKPI we have: > > void * > kmap(vm_page_t page) > { > #ifdef LINUXKPI_HAVE_DMAP > vm_offset_t daddr; > > daddr = PHYS_TO_DMAP(VM_PAGE_TO_PHYS(page)); > > return ((void *)daddr); > #else > struct sf_buf *sf; > > sched_pin(); > sf = sf_buf_alloc(page, SFB_NOWAIT | SFB_CPUPRIVATE); > if (sf == NULL) { > sched_unpin(); > return (NULL); > } > return ((void *)sf_buf_kva(sf)); > #endif > } > > void > kunmap(vm_page_t page) > { > #ifdef LINUXKPI_HAVE_DMAP > /* NOP */ > #else > struct sf_buf *sf; > > /* lookup SF buffer in list */ > sf = sf_buf_alloc(page, SFB_NOWAIT | SFB_CPUPRIVATE); > > /* double-free */ > sf_buf_free(sf); > sf_buf_free(sf); > > sched_unpin(); > #endif > } > > I think that is the fastest way to do this. So the kmap address is only valid on the CPU that called the function ? This is strange, I was not able to find mention of it in references to kmap. From owner-freebsd-current@freebsd.org Fri Jan 31 15:13:16 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 61AFF2426ED for ; Fri, 31 Jan 2020 15:13:16 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward106o.mail.yandex.net (forward106o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::609]) (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 488LMG6sjLz3FNr for ; Fri, 31 Jan 2020 15:13:14 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from mxback24o.mail.yandex.net (mxback24o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::75]) by forward106o.mail.yandex.net (Yandex) with ESMTP id 78854506101C; Fri, 31 Jan 2020 18:13:11 +0300 (MSK) Received: from myt6-efff10c3476a.qloud-c.yandex.net (myt6-efff10c3476a.qloud-c.yandex.net [2a02:6b8:c12:13a3:0:640:efff:10c3]) by mxback24o.mail.yandex.net (mxback/Yandex) with ESMTP id KjS5WOQr7L-DBFO5jMh; Fri, 31 Jan 2020 18:13:11 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1580483591; bh=oBqT6+0YEyIQnMmJRoUzmoJJuQm3vW5AQI6yqqny990=; h=In-Reply-To:From:Date:References:To:Subject:Message-ID; b=WsMaiA5W8eJvrB6kEHhkFoNsc1V+WmftlsUgjVsLiyLf2LXQ17r2VIUDM+PY/0EUS 7ODbL/f2C5dqwNZyhrjLTqUjz+MZCLpBQsnoDjTo+8avO1JWtiXRCjvlpelU0rD/27 Nqfz8TOVea+jprgogHYtRrlCWGUc/eqzKNVdtOoE= Received: by myt6-efff10c3476a.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id rhY2X61xkb-DA1Sngm0; Fri, 31 Jan 2020 18:13:10 +0300 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client certificate not present) Subject: Re: hwpstate_intel hangs kernel To: Andreas Nilsson , Current FreeBSD References: From: "Andrey V. Elsukov" Openpgp: id=E6591E1B41DA1516F0C9BC0001C5EA0410C8A17A Autocrypt: addr=bu7cher@yandex.ru; prefer-encrypt=mutual; keydata= mQENBEwBF1kBCADB9sXFhBEUy8qQ4X63Y8eBatYMHGEFWN9ypS5lI3RE6qQW2EYbxNk7qUC5 21YIIS1mMFVBEfvR7J9uc7yaYgFCEb6Sce1RSO4ULN2mRKGHP3/Sl0ijZEjWHV91hY1YTHEF ZW/0GYinDf56sYpDDehaBF5wkWIo1+QK5nmj3vl0DIDCMNd7QEiWpyLVwECgLX2eOAXByT8B bCqVhJGcG6iFP7/B9Ll6uX5gb8thM9LM+ibwErDBVDGiOgvfxqidab7fdkh893IBCXa82H9N CNwnEtcgzh+BSKK5BgvPohFMgRwjti37TSxwLu63QejRGbZWSz3OK3jMOoF63tCgn7FvABEB AAG0JUFuZHJleSBWLiBFbHN1a292IDxidTdjaGVyQHlhbmRleC5ydT6JATgEEwECACIFAkwB F1kCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEAHF6gQQyKF6qmYIAI6ekfm1VA4T vqankI1ISE6ku4jV7UlpIQlEbE7/8n3Zd6teJ+pGOQhN5qk8QE7utdPdbktAzi+x7LIJVzUw 4TywZLXGrkP7VKYkfg6oyCGyzITghefQeJtr2TN4hYCkzPWpylkue8MtmqfZv/6royqwTbN+ +E09FQNvTgRUYJYTeQ1qOsxNRycwvw3dr2rOfuxShbzaHBB1pBIjGrMg8fC5pd65ACH5zuFV A0CoTNGMDrEZSfBkTW604UUHFFXeCoC3dwDZRKOWJ3GmMXns65Ai5YkA63BSHEE1Qle3VBhd cG1w0CB5FBV3pB27UVnf0jEbysrDqW4qN7XMRFSWNAy5AQ0ETAEXWQEIAJ2p6l9LBoqdH/0J PEFDY2t2gTvAuzz+8zs3R03dFuHcNbOwjvWCG0aOmVpAzkRa8egn5JB4sZaFUtKPYJEQ1Iu+ LUBwgvtXf4vWpzC67zs2dDuiW4LamH5p6xkTD61aHR7mCB3bg2TUjrDWn2Jt44cvoYxj3dz4 S49U1rc9ZPgD5axCNv45j72tggWlZvpefThP7xT1OlNTUqye2gAwQravXpZkl5JG4eOqJVIU X316iE3qso0iXRUtO7OseBf0PiVmk+wCahdreHOeOxK5jMhYkPKVn7z1sZiB7W2H2TojbmcK HZC22sz7Z/H36Lhg1+/RCnGzdEcjGc8oFHXHCxUAEQEAAYkBHwQYAQIACQUCTAEXWQIbDAAK CRABxeoEEMihegkYCAC3ivGYNe2taNm/4Nx5GPdzuaAJGKWksV+w9mo7dQvU+NmI2az5w8vw 98OmX7G0OV9snxMW+6cyNqBrVFTu33VVNzz9pnqNCHxGvj5dL5ltP160JV2zw2bUwJBYsgYQ WfyJJIM7l3gv5ZS3DGqaGIm9gOK1ANxfrR5PgPzvI9VxDhlr2juEVMZYAqPLEJe+SSxbwLoz BcFCNdDAyXcaAzXsx/E02YWm1hIWNRxanAe7Vlg7OL+gvLpdtrYCMg28PNqKNyrQ87LQ49O9 50IIZDOtNFeR0FGucjcLPdS9PiEqCoH7/waJxWp6ydJ+g4OYRBYNM0EmMgy1N85JJrV1mi5i Message-ID: Date: Fri, 31 Jan 2020 18:11:01 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="yWTOcJ7OvlZ7nYu9iF8TvVCpWQHIGoHML" X-Rspamd-Queue-Id: 488LMG6sjLz3FNr X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yandex.ru header.s=mail header.b=WsMaiA5W; dmarc=pass (policy=none) header.from=yandex.ru; spf=pass (mx1.freebsd.org: domain of bu7cher@yandex.ru designates 2a02:6b8:0:1a2d::609 as permitted sender) smtp.mailfrom=bu7cher@yandex.ru X-Spamd-Result: default: False [-5.10 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a02:6b8:0:1000::/52]; FREEMAIL_FROM(0.00)[yandex.ru]; HAS_ATTACHMENT(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yandex.ru:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yandex.ru,none]; SIGNED_PGP(-2.00)[]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(0.00)[ip: (-9.53), ipnet: 2a02:6b8::/32(-4.73), asn: 13238(-3.82), country: RU(0.01)]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; FREEMAIL_ENVFROM(0.00)[yandex.ru]; ASN(0.00)[asn:13238, ipnet:2a02:6b8::/32, country:RU]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yandex.ru.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[yandex.ru:s=mail]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[9.0.6.0.0.0.0.0.0.0.0.0.0.0.0.0.d.2.a.1.0.0.0.0.8.b.6.0.2.0.a.2.list.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 31 Jan 2020 15:13:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --yWTOcJ7OvlZ7nYu9iF8TvVCpWQHIGoHML Content-Type: multipart/mixed; boundary="yCly1SsSarouNySzFibVxj54Vc4tjO0Rt"; protected-headers="v1" From: "Andrey V. Elsukov" To: Andreas Nilsson , Current FreeBSD Message-ID: Subject: Re: hwpstate_intel hangs kernel References: In-Reply-To: --yCly1SsSarouNySzFibVxj54Vc4tjO0Rt Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 24.01.2020 19:52, Andreas Nilsson wrote: > It hangs during kernel boot and the last message printed on console is:= > hwpstate_intel0: on cpu0 Hi, Did you find the cause of this hang? I also tried to update today from r350816 to r357330. But my Lenovo X1 Carbon 4th hangs on the same message. --=20 WBR, Andrey V. Elsukov --yCly1SsSarouNySzFibVxj54Vc4tjO0Rt-- --yWTOcJ7OvlZ7nYu9iF8TvVCpWQHIGoHML Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQEzBAEBCAAdFiEE5lkeG0HaFRbwybwAAcXqBBDIoXoFAl40Q4kACgkQAcXqBBDI oXpjWQf/aj8LnUyhnVk1Q3Bx3rvkPuzQp3H9dA62sCdv9AZMCMpoSc3TqXjRLepp pY7yg4yLXoaiiagBjOIxXAJuGy84Lia4/1eZmnbgmugdHbK39ahQ/So6TYfY7Nkf Y826Fb0owEs8fGEI10YPziZJCfWig/Qav5SLnbf+8mMpKc9fk3PkDCKEqIADCoCA 98tuPWYK9gFs78F4frvSiucU7pBXAM05TShcBe4zXnllwarQADs+687OIEyDLWTe zdoGR/olZqAaW3wxmsRoBc73J/7gkbZ+TAw2BO74VHVuYssxQZlmscy9MZYt81Oq PgrIikpfMY51xk6cGusqi3M8i5y1iA== =QZ4P -----END PGP SIGNATURE----- --yWTOcJ7OvlZ7nYu9iF8TvVCpWQHIGoHML-- From owner-freebsd-current@freebsd.org Fri Jan 31 15:41:44 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DCA482431BE for ; Fri, 31 Jan 2020 15:41:44 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 488M080kt4z3HKR for ; Fri, 31 Jan 2020 15:41:43 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2020.home.selasky.org (unknown [62.141.129.235]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 3CAD0260189 for ; Fri, 31 Jan 2020 16:41:42 +0100 (CET) Subject: Re: [HEADS UP] EPOCH breakage in [USB/PCI] network drivers after r357004 From: Hans Petter Selasky To: FreeBSD Current References: Message-ID: <2daf56df-1e01-4869-17d1-72768cae789a@selasky.org> Date: Fri, 31 Jan 2020 16:40:25 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 488M080kt4z3HKR X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-5.42 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.997,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[selasky.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE(-3.12)[ip: (-9.34), ipnet: 88.99.0.0/16(-4.71), asn: 24940(-1.55), country: DE(-0.02)]; TO_DN_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 31 Jan 2020 15:41:44 -0000 Hi, The USB WLAN drivers are now fixed, but there are some more to go, and Gleb has put up a patch for review: https://reviews.freebsd.org/D23408 After those drivers have been resolved I will rebase: https://reviews.freebsd.org/D23348 Which then will contain a list of remaining network driver EPOCH issues. --HPS From owner-freebsd-current@freebsd.org Fri Jan 31 22:47:12 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 14B921EF5D2 for ; Fri, 31 Jan 2020 22:47:12 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670082.outbound.protection.outlook.com [40.107.67.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 488XR30dsYz4KpG for ; Fri, 31 Jan 2020 22:47:10 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gXb6WDOJDWIg/L1k2nKpu8fwOO6G4tDdkWrz01slz4Wo84oMcZeU3zvgqJCadiQK2Xogc5iLa0osMv+qmmcBFFsQcMb4W+q16uxvHoPpnfvUJk03eBQ6pElnYAycvP0ggkwVVhUjZW2P8li94n8hPSONINQV/GxcxA4tZcvfTogM1sF0oQuF0/2aUIHZrNg5nrEHIKsMPAl48zJlDMLFVfE13wGed4KieAOQJIuMx0o6+9rEhgRVfTr4Xp2Egrpce2RfS76vRMNJkFtLkKPjpm65wpZ/KaKMnRVz5tJA2+cChACxiRK/oMe5pyArXZEUWFXoV/ukXnJAWrectXhnZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8sHHcegAjqjXwSg0HtKXj/pasUpF9nW7ekDoJKrMRaM=; b=eFZYt+vClxwQdSXmFyrdw9YN6/air9KtN7uVeDJhL0GzxuuTs4lnio2QbgRECEQJp10qjcn6tArhHJLwl/TBTR4b0xG6nxIwhNl0n2rjnzYhh8998mymL/imwtmUPlnoKoQDc750+uPKOApEpRZPhyPUDZp92Ua3/dWq+0vhHTedRNITfy1z7yvCJp4Da/EWNGiIPjfOfMTpBGTgCtzJKKUmVIqc5iFm8BTa8LieXNoeNXBQsvnkdqGj0766ub6saCvFuQa3+uwz4g52QY1IVG8zSbBgJkBVXoolxkBW48CL+u/Od/4gyJWQF3AONxIyMTOjS5Ytei2FUP7nIZB09A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none Received: from YTBPR01MB3374.CANPRD01.PROD.OUTLOOK.COM (10.255.46.82) by YTBPR01MB3503.CANPRD01.PROD.OUTLOOK.COM (10.255.12.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.28; Fri, 31 Jan 2020 22:47:09 +0000 Received: from YTBPR01MB3374.CANPRD01.PROD.OUTLOOK.COM ([fe80::410e:652b:6fbc:9aa4]) by YTBPR01MB3374.CANPRD01.PROD.OUTLOOK.COM ([fe80::410e:652b:6fbc:9aa4%3]) with mapi id 15.20.2686.028; Fri, 31 Jan 2020 22:47:09 +0000 From: Rick Macklem To: Konstantin Belousov , Hans Petter Selasky CC: "freebsd-current@FreeBSD.org" Subject: Re: easy way to work around a lack of a direct map on i386 Thread-Topic: easy way to work around a lack of a direct map on i386 Thread-Index: AQHV18KXJBNJQhyzKEGjuJj0X3dTjKgD3PkAgAChCwCAADdBAIAAq2nW Date: Fri, 31 Jan 2020 22:47:09 +0000 Message-ID: References: <20200130233734.GV4808@kib.kiev.ua> , <20200131123144.GW4808@kib.kiev.ua> In-Reply-To: <20200131123144.GW4808@kib.kiev.ua> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f39e91f2-0c24-48d8-c9d4-08d7a69f8153 x-ms-traffictypediagnostic: YTBPR01MB3503: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 029976C540 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(136003)(366004)(346002)(376002)(39860400002)(199004)(189003)(4326008)(33656002)(91956017)(9686003)(55016002)(66476007)(66946007)(76116006)(26005)(2906002)(64756008)(66446008)(66556008)(8936002)(71200400001)(86362001)(186003)(81156014)(8676002)(81166006)(966005)(52536014)(5660300002)(6506007)(53546011)(110136005)(786003)(7696005)(316002)(478600001)(43043002); DIR:OUT; SFP:1101; SCL:1; SRVR:YTBPR01MB3503; H:YTBPR01MB3374.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-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: cMmmLEEdqZIWB1xDsI8trP3VAuqOVg/lxzCTqCP5re9s9eiYkeyPthmhh69U30d7WtsRkk8NVLARb2LK/LRKJuuOOgiR9bugSpR3bJCUNyKo1J9cz9f+qGVdwQMRC82+QjGDlhWR3EuIU28Ks/OQytJQBkx/BhRVodGilttI08ZhzpS4TKN/n8pw1ss5G99g2JodTD2nj77nAgkM3VMUDABexeH0hNl1Nd01a+X439GudRVQWweLSpQ5UFow3dwBqzJLYpKmdqxqYnBlJ58eJPbNpTlEoCNbtTChKYBU3D+oT0MxCTJtHzTGwBJc7ZbIPnfVldL+K5WXClnF9tTqTSdkgVETPECirWd9/a4DLB5XtnWGiAz3JKKfKOCvT+2Y8WrAxKxWFiiKJMCgTsf5dQ8EYhrDLK4W69nmokXh18T/qPq7wadNaegkgziINoakapm/wnKcomgpiKNFPvhcwnybCpZOtrVAbZ+K+vssWGxORgKJwNt6a2qAKWKcJ9LpmzW2H/q5XCa8ooNiXqp0RZkjySuKEOUpSoGjK9w9KydjSKLBdcInAGkzHGv0joAL x-ms-exchange-antispam-messagedata: 6UQNjwenYU6FIpxFJ6p+feyRmyZmyJmee7vOhqobaRNLdnfwGt2HCEHW2AbfAUoPOJrSUZ2mXlY4unurPp5+8Z+eVferpX2cFWqW/luDpDvZdoXVYDgIergvzk47HUTYinX09k/y/XNK9kxe8nHcvg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-Network-Message-Id: f39e91f2-0c24-48d8-c9d4-08d7a69f8153 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jan 2020 22:47:09.5587 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: thrmAmesrsLLgd9VgcpVdOVXl0XHGV4tycV7ei3ZBrAYjF5yNshTykZJaekPXZBnuHeCt8i0ojhpVK6WMCejFg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTBPR01MB3503 X-Rspamd-Queue-Id: 488XR30dsYz4KpG X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.67.82 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-4.69 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[uoguelph.ca]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[82.67.107.40.list.dnswl.org : 127.0.3.0]; IP_SCORE(-1.39)[ipnet: 40.64.0.0/10(-3.86), asn: 8075(-3.06), country: US(-0.05)]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:8075, ipnet:40.64.0.0/10, country:US]; ARC_ALLOW(-1.00)[i=1] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 31 Jan 2020 22:47:12 -0000 Thanks everyone. I should have waited a day, since jhb@ responded w.r.t. using sf_bufs as well. For now, we are sticking with a 64bit only solution, since work on the receive side of KERN_TLS is more critical to getting this going. rick ________________________________________ From: owner-freebsd-current@freebsd.org = on behalf of Konstantin Belousov Sent: Friday, January 31, 2020 7:31 AM To: Hans Petter Selasky Cc: Rick Macklem; freebsd-current@FreeBSD.org Subject: Re: easy way to work around a lack of a direct map on i386 On Fri, Jan 31, 2020 at 10:13:58AM +0100, Hans Petter Selasky wrote: > On 2020-01-31 00:37, Konstantin Belousov wrote: > > On Thu, Jan 30, 2020 at 11:23:02PM +0000, Rick Macklem wrote: > > > Hi, > > > > > > The current code for KERN_TLS uses PHYS_TO_DMAP() > > > to access unmapped external pages on m_ext.ext_pgs > > > mbufs. > > > I also need to do this to implement RPC-over-TLS. > > > > > > The problem is that some arches, like i386, don't > > > support PHYS_TO_DMAP(). > > > > > > Since it appears that there will be at most 4 pages on > > > one of these mbufs, my thinking was... > > > - Acquire four pages of kva from the kernel_map during > > > booting. > > > - Then just use pmap_qenter() to fill in the physical page > > > mappings for long enough to copy the data. > > > > > > Does this sound reasonable? > > > Is there a better way? > > > > Use sfbufs, they should work on all arches. In essence, they provide M= I > > interface to DMAP where possible. I do not remember did I bumped the > > limit for i386 after 4/4 went in. > > > > There is currently no limits for sfbufs use per subsystem, but I think = it > > is not very likely to cause too much troubles. Main rule is to not sle= ep > > waiting for more sfbufs if you already own one.. > > In the DRM-KMS LinuxKPI we have: > > void * > kmap(vm_page_t page) > { > #ifdef LINUXKPI_HAVE_DMAP > vm_offset_t daddr; > > daddr =3D PHYS_TO_DMAP(VM_PAGE_TO_PHYS(page)); > > return ((void *)daddr); > #else > struct sf_buf *sf; > > sched_pin(); > sf =3D sf_buf_alloc(page, SFB_NOWAIT | SFB_CPUPRIVATE); > if (sf =3D=3D NULL) { > sched_unpin(); > return (NULL); > } > return ((void *)sf_buf_kva(sf)); > #endif > } > > void > kunmap(vm_page_t page) > { > #ifdef LINUXKPI_HAVE_DMAP > /* NOP */ > #else > struct sf_buf *sf; > > /* lookup SF buffer in list */ > sf =3D sf_buf_alloc(page, SFB_NOWAIT | SFB_CPUPRIVATE); > > /* double-free */ > sf_buf_free(sf); > sf_buf_free(sf); > > sched_unpin(); > #endif > } > > I think that is the fastest way to do this. So the kmap address is only valid on the CPU that called the function ? This is strange, I was not able to find mention of it in references to kmap. _______________________________________________ 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 Sat Feb 1 12:57:05 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D482D24E37E for ; Sat, 1 Feb 2020 12:57:05 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 488vHj1rGYz4WVZ for ; Sat, 1 Feb 2020 12:57:04 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2020.home.selasky.org (unknown [62.141.129.235]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 65DBA2600FB; Sat, 1 Feb 2020 13:57:03 +0100 (CET) Subject: Re: easy way to work around a lack of a direct map on i386 To: Konstantin Belousov Cc: Rick Macklem , "freebsd-current@FreeBSD.org" References: <20200130233734.GV4808@kib.kiev.ua> <20200131123144.GW4808@kib.kiev.ua> From: Hans Petter Selasky Message-ID: Date: Sat, 1 Feb 2020 13:56:59 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1 MIME-Version: 1.0 In-Reply-To: <20200131123144.GW4808@kib.kiev.ua> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 488vHj1rGYz4WVZ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-4.96 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(-2.66)[ip: (-9.22), ipnet: 2a01:4f8::/29(-2.53), asn: 24940(-1.55), country: DE(-0.02)]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 01 Feb 2020 12:57:05 -0000 On 2020-01-31 13:31, Konstantin Belousov wrote: > On Fri, Jan 31, 2020 at 10:13:58AM +0100, Hans Petter Selasky wrote: >> On 2020-01-31 00:37, Konstantin Belousov wrote: >>> On Thu, Jan 30, 2020 at 11:23:02PM +0000, Rick Macklem wrote: >>>> Hi, >>>> >>>> The current code for KERN_TLS uses PHYS_TO_DMAP() >>>> to access unmapped external pages on m_ext.ext_pgs >>>> mbufs. >>>> I also need to do this to implement RPC-over-TLS. >>>> >>>> The problem is that some arches, like i386, don't >>>> support PHYS_TO_DMAP(). >>>> >>>> Since it appears that there will be at most 4 pages on >>>> one of these mbufs, my thinking was... >>>> - Acquire four pages of kva from the kernel_map during >>>> booting. >>>> - Then just use pmap_qenter() to fill in the physical page >>>> mappings for long enough to copy the data. >>>> >>>> Does this sound reasonable? >>>> Is there a better way? >>> >>> Use sfbufs, they should work on all arches. In essence, they provide MI >>> interface to DMAP where possible. I do not remember did I bumped the >>> limit for i386 after 4/4 went in. >>> >>> There is currently no limits for sfbufs use per subsystem, but I think it >>> is not very likely to cause too much troubles. Main rule is to not sleep >>> waiting for more sfbufs if you already own one.. >> >> In the DRM-KMS LinuxKPI we have: >> >> void * >> kmap(vm_page_t page) >> { >> #ifdef LINUXKPI_HAVE_DMAP >> vm_offset_t daddr; >> >> daddr = PHYS_TO_DMAP(VM_PAGE_TO_PHYS(page)); >> >> return ((void *)daddr); >> #else >> struct sf_buf *sf; >> >> sched_pin(); >> sf = sf_buf_alloc(page, SFB_NOWAIT | SFB_CPUPRIVATE); >> if (sf == NULL) { >> sched_unpin(); >> return (NULL); >> } >> return ((void *)sf_buf_kva(sf)); >> #endif >> } >> >> void >> kunmap(vm_page_t page) >> { >> #ifdef LINUXKPI_HAVE_DMAP >> /* NOP */ >> #else >> struct sf_buf *sf; >> >> /* lookup SF buffer in list */ >> sf = sf_buf_alloc(page, SFB_NOWAIT | SFB_CPUPRIVATE); >> >> /* double-free */ >> sf_buf_free(sf); >> sf_buf_free(sf); >> >> sched_unpin(); >> #endif >> } >> >> I think that is the fastest way to do this. > > So the kmap address is only valid on the CPU that called the function ? > This is strange, I was not able to find mention of it in references to > kmap. Yes, only on the current CPU. See the SFB_CPUPRIVATE flag. --HPS From owner-freebsd-current@freebsd.org Sat Feb 1 13:27:49 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5C95C24EEC8 for ; Sat, 1 Feb 2020 13:27:49 +0000 (UTC) (envelope-from yasu@utahime.org) Received: from gate.utahime.jp (gate.utahime.jp [183.180.29.210]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 488vz75YGZz4Xlv for ; Sat, 1 Feb 2020 13:27:47 +0000 (UTC) (envelope-from yasu@utahime.org) Received: from eastasia.home.utahime.org (eastasia.home.utahime.org [192.168.174.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by gate.utahime.jp (Postfix) with ESMTPS id 7BBE817F49 for ; Sat, 1 Feb 2020 22:27:37 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=utahime.org; s=maybe2019112701; t=1580563657; bh=/6eGQauleLDSues2Bsybld4zBt7wW1ietKY9xLaXpO0=; h=Date:To:Subject:From:In-Reply-To:References; b=NJzNoIFy44KePkgHrbYUVPOxOnRS24zRIfsDZPCKJFWQJ5PMz95VXW5ozUFyvMvyU LGCB03ZS1uT3x/rFH4bFqAPmMPfeq/BTKSdkLxrK1tgWMmFX9bW72jk4H//7v7i607 kZWTuMP0bDQgnczB04mzOCnh/6tXvPCelKijNh8yQeTtzwLM3VluELdxF924AkghSV N0oXLCgfOez6jcuZKwoyn4dni34HNJXXCLEPMpwdxklWZM1Q7Lq4V9MaqSVuMmvtmb mYjFJ3vy53ekgNdxoglVWCwH3uzeEXZGHuwq8CSJ+a5cjplKLRLTqr1m+lpikGt1A4 Ue/YYUPh1bhZw== Received: from localhost (rolling.home.utahime.org [192.168.174.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by eastasia.home.utahime.org (Postfix) with ESMTPSA id 7CA05F449; Sat, 1 Feb 2020 22:27:34 +0900 (JST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.102.1 at eastasia.home.utahime.org Date: Sat, 01 Feb 2020 22:27:25 +0900 (JST) Message-Id: <20200201.222725.920510194618963958.yasu@utahime.org> To: freebsd-current@freebsd.org Subject: Re: After update to r357104 build of poudriere jail fails with 'out of swap space' From: Yasuhiro KIMURA In-Reply-To: <20200125.234328.1043751263164767852.yasu@utahime.org> References: <20200125.234328.1043751263164767852.yasu@utahime.org> X-Mailer: Mew version 6.8 on Emacs 26.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 488vz75YGZz4Xlv X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=utahime.org header.s=maybe2019112701 header.b=NJzNoIFy; dmarc=none; spf=pass (mx1.freebsd.org: domain of yasu@utahime.org designates 183.180.29.210 as permitted sender) smtp.mailfrom=yasu@utahime.org X-Spamd-Result: default: False [0.54 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[utahime.org:s=maybe2019112701]; NEURAL_HAM_MEDIUM(-0.90)[-0.898,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+a:spf-authorized.utahime.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[utahime.org]; MV_CASE(0.50)[]; DKIM_TRACE(0.00)[utahime.org:+]; NEURAL_SPAM_LONG(0.07)[0.067,0]; MID_CONTAINS_FROM(1.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(0.37)[ip: (0.22), ipnet: 183.180.0.0/16(0.11), asn: 2519(1.47), country: JP(0.03)]; ASN(0.00)[asn:2519, ipnet:183.180.0.0/16, country:JP]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 01 Feb 2020 13:27:49 -0000 From: Yasuhiro KIMURA Subject: After update to r357104 build of poudriere jail fails with 'out of swap space' Date: Sat, 25 Jan 2020 23:43:28 +0900 (JST) > I use VirtualBox to run 13-CURRENT. Host is 64bit Windows 10 1909 and > spec of VM is as following. > > * 4 CPU > * 8GB memory > * 100GB disk > - 92GB ZFS pool (zroot) > - 8GB swap > > Today I updated this VM to r357104. And after that I tried to update > poudriere jail with `poudriere jail -u -j jailname -b`. But it failed > at install stage. After the failure I found following message is > written to syslog. > > Jan 25 19:18:25 rolling-vm-freebsd1 kernel: pid 7963 (strip), jid 0, uid 0, was killed: out of swap space > > To make sure I shutdown both VM and host, restarted them and tried > update of jail again. Then the problem was reproduced. > > Does anybody else experience it? Thank you everyone for explanation, suggestion, advice and investigation about this problem, and sorry for late response. I couldn't handle this problem this week because H/W trouble happend to host machine last sunday. And while I waited for the host machine to finish repairing, the problem is fixed with r357253. So today I updated this VM to r357333 and confirmed update of poudriere jail succeed without error. But at the same time I faced a new kernel panic and am investigating which revision causes it. I will report this as a new matter. --- Yasuhiro KIMURA From owner-freebsd-current@freebsd.org Sat Feb 1 14:06:27 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8CED224FB67 for ; Sat, 1 Feb 2020 14:06:27 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward102p.mail.yandex.net (forward102p.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b7:102]) (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 488wqj6lL6z4Zb3; Sat, 1 Feb 2020 14:06:25 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from mxback24g.mail.yandex.net (mxback24g.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b7:324]) by forward102p.mail.yandex.net (Yandex) with ESMTP id 9D7561D41231; Sat, 1 Feb 2020 17:06:20 +0300 (MSK) Received: from sas1-e20a8b944cac.qloud-c.yandex.net (sas1-e20a8b944cac.qloud-c.yandex.net [2a02:6b8:c14:6696:0:640:e20a:8b94]) by mxback24g.mail.yandex.net (mxback/Yandex) with ESMTP id rzH30K2kcu-6K1WtQBt; Sat, 01 Feb 2020 17:06:20 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1580565980; bh=4l2xqNYgUTbQEtYLtp5Odtp+wyxisGhN7prPaVXY+64=; h=In-Reply-To:To:From:Subject:Date:References:Message-ID; b=AcMNk4qLyJVvUNXn4JSJ7ACJnzo3aT1flhRzA5HPIbwEks7Zs5fhyb6fi8mzuyyWg o9LN63d7amguoWKiN6FU+L4zet5+knsyczPJz+k92VDfvIRHU9fnXOsbc2OY30V4iL QTOgRBdhcKcI9PfxjwUgGDpIXTu7obBeH0RjbD4Q= Received: by sas1-e20a8b944cac.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id 6rddRqqJHz-6J1KcNgU; Sat, 01 Feb 2020 17:06:20 +0300 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client certificate not present) Subject: Re: hwpstate_intel hangs kernel From: "Andrey V. Elsukov" To: Andreas Nilsson , Current FreeBSD , cem@freebsd.org References: Autocrypt: addr=bu7cher@yandex.ru; prefer-encrypt=mutual; keydata= xsBNBEwBF1kBCADB9sXFhBEUy8qQ4X63Y8eBatYMHGEFWN9ypS5lI3RE6qQW2EYbxNk7qUC5 21YIIS1mMFVBEfvR7J9uc7yaYgFCEb6Sce1RSO4ULN2mRKGHP3/Sl0ijZEjWHV91hY1YTHEF ZW/0GYinDf56sYpDDehaBF5wkWIo1+QK5nmj3vl0DIDCMNd7QEiWpyLVwECgLX2eOAXByT8B bCqVhJGcG6iFP7/B9Ll6uX5gb8thM9LM+ibwErDBVDGiOgvfxqidab7fdkh893IBCXa82H9N CNwnEtcgzh+BSKK5BgvPohFMgRwjti37TSxwLu63QejRGbZWSz3OK3jMOoF63tCgn7FvABEB AAHNIkFuZHJleSBWLiBFbHN1a292IDxhZUBmcmVlYnNkLm9yZz7CwHsEEwECACUCGwMGCwkI BwMCBhUIAgkKCwQWAgMBAh4BAheABQJMB/ruAhkBAAoJEAHF6gQQyKF6MLwH/3Ri/TZl9uo0 SepYWXOnxL6EaDVXDA+dLb1eLKC4PRBBjX29ttQ0KaWapiE6y5/AfzOPmRtHLrHYHjd/aiHX GMLHcYRXD+5GvdkK8iMALrZ28X0JXyuuZa8rAxWIWmCbYHNSBy2unqWgTI04Erodk90IALgM 9JeHN9sFqTM6zalrMnTzlcmel4kcjT3lyYw3vOKgoYLtsLhKZSbJoVVVlvRlGBpHFJI5AoYJ SyfXoN0rcX6k9X7Isp2K50YjqxV4v78xluh1puhwZyC0p8IShPrmrp9Oy9JkMX90o6UAXdGU KfdExJuGJfUZOFBTtNIMNIAKfMTjhpRhxONIr0emxxDOwE0ETAEXWQEIAJ2p6l9LBoqdH/0J PEFDY2t2gTvAuzz+8zs3R03dFuHcNbOwjvWCG0aOmVpAzkRa8egn5JB4sZaFUtKPYJEQ1Iu+ LUBwgvtXf4vWpzC67zs2dDuiW4LamH5p6xkTD61aHR7mCB3bg2TUjrDWn2Jt44cvoYxj3dz4 S49U1rc9ZPgD5axCNv45j72tggWlZvpefThP7xT1OlNTUqye2gAwQravXpZkl5JG4eOqJVIU X316iE3qso0iXRUtO7OseBf0PiVmk+wCahdreHOeOxK5jMhYkPKVn7z1sZiB7W2H2TojbmcK HZC22sz7Z/H36Lhg1+/RCnGzdEcjGc8oFHXHCxUAEQEAAcLAXwQYAQIACQUCTAEXWQIbDAAK CRABxeoEEMihegkYCAC3ivGYNe2taNm/4Nx5GPdzuaAJGKWksV+w9mo7dQvU+NmI2az5w8vw 98OmX7G0OV9snxMW+6cyNqBrVFTu33VVNzz9pnqNCHxGvj5dL5ltP160JV2zw2bUwJBYsgYQ WfyJJIM7l3gv5ZS3DGqaGIm9gOK1ANxfrR5PgPzvI9VxDhlr2juEVMZYAqPLEJe+SSxbwLoz BcFCNdDAyXcaAzXsx/E02YWm1hIWNRxanAe7Vlg7OL+gvLpdtrYCMg28PNqKNyrQ87LQ49O9 50IIZDOtNFeR0FGucjcLPdS9PiEqCoH7/waJxWp6ydJ+g4OYRBYNM0EmMgy1N85JJrV1mi5i Message-ID: Date: Sat, 1 Feb 2020 17:06:14 +0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="hnbx9nROAWjcDXyGUSjw8RoUc68zVOHdT" X-Rspamd-Queue-Id: 488wqj6lL6z4Zb3 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yandex.ru header.s=mail header.b=AcMNk4qL; dmarc=pass (policy=none) header.from=yandex.ru; spf=pass (mx1.freebsd.org: domain of bu7cher@yandex.ru designates 2a02:6b8:0:1472:2741:0:8b7:102 as permitted sender) smtp.mailfrom=bu7cher@yandex.ru X-Spamd-Result: default: False [-5.10 / 15.00]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a02:6b8:0:1000::/52]; FREEMAIL_FROM(0.00)[yandex.ru]; HAS_ATTACHMENT(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[yandex.ru:+]; DMARC_POLICY_ALLOW(-0.50)[yandex.ru,none]; SIGNED_PGP(-2.00)[]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(0.00)[ip: (-9.21), ipnet: 2a02:6b8::/32(-4.73), asn: 13238(-3.82), country: RU(0.01)]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; FREEMAIL_ENVFROM(0.00)[yandex.ru]; ASN(0.00)[asn:13238, ipnet:2a02:6b8::/32, country:RU]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yandex.ru.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[yandex.ru:s=mail]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; RCVD_TLS_LAST(0.00)[]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2.0.1.0.7.b.8.0.0.0.0.0.1.4.7.2.2.7.4.1.0.0.0.0.8.b.6.0.2.0.a.2.list.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 01 Feb 2020 14:06:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hnbx9nROAWjcDXyGUSjw8RoUc68zVOHdT Content-Type: multipart/mixed; boundary="JLaKxCz6aiIE1rI0e3gQNZdtfuqtO6JDl" --JLaKxCz6aiIE1rI0e3gQNZdtfuqtO6JDl Content-Type: text/plain; charset=utf-8 Content-Language: ru Content-Transfer-Encoding: quoted-printable 31.01.2020 18:11, Andrey V. Elsukov =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > On 24.01.2020 19:52, Andreas Nilsson wrote: >> It hangs during kernel boot and the last message printed on console is= : >> hwpstate_intel0: on cpu0 >=20 > Hi, >=20 > Did you find the cause of this hang? > I also tried to update today from r350816 to r357330. But my Lenovo X1 > Carbon 4th hangs on the same message. >=20 Hi, I have bisected the bad commit, it is r357002. --=20 WBR, Andrey V. Elsukov --JLaKxCz6aiIE1rI0e3gQNZdtfuqtO6JDl-- --hnbx9nROAWjcDXyGUSjw8RoUc68zVOHdT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEE5lkeG0HaFRbwybwAAcXqBBDIoXoFAl41hdsACgkQAcXqBBDI oXp/kAgAt0434dm8iv9zmiK5t2xUbMiTxqSMfUV8LolC3Noajg0VBcA8wgAL7hvm qMLL/NTXKYl2KoRn/nLRSJJ9LCSyE+wjuUBeM/GdUfcxs03jtm5VMCOJvn0NybbK uNL6JHwa21plT39Q1XT+N9rln+A4rvztmjMkr5DDkRD9L/49XV4LL2QGuiHrxjlK SOZMGP78ky6FS0WyOTJGVdmyYoCwWGrkAzBSy6KdXKwKolppPSpBr95tG+rBb9wH 9G05MYOUt9poLh6+Vx4yFF+2eyBYki58i6UCwxE/cBPW1K/5Sb4SHTJHkND9OI0y t5x4WoLrrAKEmfNGQ5BXQku3eykkuA== =O3vN -----END PGP SIGNATURE----- --hnbx9nROAWjcDXyGUSjw8RoUc68zVOHdT-- From owner-freebsd-current@freebsd.org Sat Feb 1 14:55:52 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5A8441F8DD3 for ; Sat, 1 Feb 2020 14:55:52 +0000 (UTC) (envelope-from gsnb.gn@gmail.com) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 488xwl4tCZz4cyF for ; Sat, 1 Feb 2020 14:55:51 +0000 (UTC) (envelope-from gsnb.gn@gmail.com) Received: by mail-io1-xd2f.google.com with SMTP id c16so11677556ioh.6 for ; Sat, 01 Feb 2020 06:55:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=42ywrTxZXNkGj4Kvwj+qOtb2BJRFhPAFSemSr8wpx3c=; b=M58pC9eMdhlnHMrlPkuomZxfpFJ1bDIob71kM0lpaucpvW0KbLq+J/EZETaLMJWgaI jZvkfF6hXNIkE6D6ei1Egc4ws4OhXigB/nrZyKFaPHNyiO6/ofyn0nzzIre/2JoBT3KI mY8KRBo6ZPEvnbM+kNXOUB6ELOdKSu2n3qzlP+XZfpVkvW0jMlhrhEe01fXSHSPr6ObH JqZIwn7HisinMqgvJFPyg9/78XNy+JGkNTStGzP3y2+lTxn/trshXy6a1DzaWYbK2FeU k6E4z7TtN1kNmyPVVJ6u7rZ9rIiYLE+GX9QSXaNqUwy4WVVklIrdpZvGl6ZAlGt/4yz8 DTkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=42ywrTxZXNkGj4Kvwj+qOtb2BJRFhPAFSemSr8wpx3c=; b=LVbDK0eZ6944D3f07xixzryemZ2rk5o3s4kO+yUjkSQrTKD1vXPM51c2W9aUH+ZcPo I3fb2AsOn/VYPl+G3vnoXvRPZm+CRxsuovNJ3C36YRXykDz/ae/mT1Xou1x2ZkGgozuz bYlxqxeZB2nmEoaBoS2UO1cGwfQVdE3gyel9ItRUhPYfCFKt1sqVF4+P5+30D1KFNg/x g/505ZajcyYZCSe4zlBTTHM7c8c/szYi958ITr2g7zg4nWl2lXpDAZi0/ya5bH+hMGkn du6JmyjSrckBpyXma1naK8XbL5+s0laoPvRYcRW/kC4pY1udPI1fwK0jr93oD4JpWbFn LpZQ== X-Gm-Message-State: APjAAAUldOmjWHrOzppITpMJeqpEwnqjI3z7HwG8laJQfpiJV/rHLDDe ca8gp1/mC0Wxq9+vlm3AIqw+ZmxARdpOxWNYiNPZBQwn X-Google-Smtp-Source: APXvYqzvFslPhSnVRkrLgteI2+Jmxs9ro0Byw/wn5QykSGIN99GTqOXGwJRSZJ4Q9o9dQDNhA4KYveC0urgQog1UR1M= X-Received: by 2002:a02:cf2e:: with SMTP id s14mr12192767jar.124.1580568949757; Sat, 01 Feb 2020 06:55:49 -0800 (PST) MIME-Version: 1.0 From: Niteesh Date: Sat, 1 Feb 2020 20:25:38 +0530 Message-ID: Subject: OFWBUS: How does autoconfiguration work? To: freebsd-current@freebsd.org X-Rspamd-Queue-Id: 488xwl4tCZz4cyF X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=M58pC9eM; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of gsnbgn@gmail.com designates 2607:f8b0:4864:20::d2f as permitted sender) smtp.mailfrom=gsnbgn@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(0.00)[ip: (-6.47), ipnet: 2607:f8b0::/32(-2.00), asn: 15169(-1.76), country: US(-0.05)]; RCVD_IN_DNSWL_NONE(0.00)[f.2.d.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 01 Feb 2020 14:55:52 -0000 I am interested in adding autoconfiguration to one of my projects. The current drivers use lazy initialization, for example, the UART drivers initialize the hardware only during their first invocation. I would like to add a subsystem, that will read the DTB and call the appropriate drivers. I want to know how it is implemented in FreeBSD, I took a look at the code, but I am still couldn't figure out, when does FreeBSD start to parse the DTB, how does it fill up the device struct and few more. Can someone please explain how all this works with reference to code or point me to some documentation? Thanks, Niteesh From owner-freebsd-current@freebsd.org Sat Feb 1 17:18:20 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B223A1FCFE7 for ; Sat, 1 Feb 2020 17:18:20 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-ot1-f65.google.com (mail-ot1-f65.google.com [209.85.210.65]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4891575Fggz3JY5 for ; Sat, 1 Feb 2020 17:18:19 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-ot1-f65.google.com with SMTP id a15so9716344otf.1 for ; Sat, 01 Feb 2020 09:18:19 -0800 (PST) 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:reply-to :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=HuZKOr9qy6atv+JH8QdZTMfna/fVFdl2lHozfHNzAZc=; b=r8kARdq4zAXKLbKyM0Kv/xqmKUIftmYKGDGLxIMcFS4LBMmtIL5Rv3A2GL2dgx3Vtm 2a9EKGwhvvASg8pEJVFgGGmEpdLB1TYQ9vA9Jw0lg0TeA/T/w2cFMj3/D5a4ZpWUcVaL VM6nzmyE8ytBDLV0o0TvdMtYGVVorasKxcBux6RkCGMexIrVAKnrGoxxq4iqywdbNdWO acOHjCg9MAX9dWOpm4tG9l7jLEIFjKzLMoKRNHwPz40Qx929a0tXrcWd4w1zsf7ui9g8 9pqrspX6Qi+DjQXvzJGXXyXMu4EJPLK+bXpl8ASbOOQHMacyLafC9Rgyz/yYoBVVqA0R 4ejw== X-Gm-Message-State: APjAAAUZG5X8y0sDc4xAXP1cnlYwz/ZOOZN39sw4AgvIRXxcv0h/lYK8 B5hwgcoXwenFW8U14MCxsp1rV5D3 X-Google-Smtp-Source: APXvYqz3oKL16NnMbOB0KFacMZ4TrqWsx9YXUuuDWbyhv+eQ430AthEAO3gqDUfho/Ilf+wCQe3VYQ== X-Received: by 2002:a9d:6e05:: with SMTP id e5mr11946398otr.46.1580577498411; Sat, 01 Feb 2020 09:18:18 -0800 (PST) Received: from mail-oi1-f180.google.com (mail-oi1-f180.google.com. [209.85.167.180]) by smtp.gmail.com with ESMTPSA id s26sm4350385otk.43.2020.02.01.09.18.17 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 01 Feb 2020 09:18:18 -0800 (PST) Received: by mail-oi1-f180.google.com with SMTP id l9so6771405oii.5 for ; Sat, 01 Feb 2020 09:18:17 -0800 (PST) X-Received: by 2002:aca:3017:: with SMTP id w23mr9453458oiw.152.1580577497688; Sat, 01 Feb 2020 09:18:17 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Reply-To: cem@freebsd.org From: Conrad Meyer Date: Sat, 1 Feb 2020 09:18:06 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: hwpstate_intel hangs kernel To: "Andrey V. Elsukov" Cc: Andreas Nilsson , Current FreeBSD Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4891575Fggz3JY5 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of csecem@gmail.com designates 209.85.210.65 as permitted sender) smtp.mailfrom=csecem@gmail.com X-Spamd-Result: default: False [-3.04 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[cem@freebsd.org]; RWL_MAILSPIKE_GOOD(0.00)[65.210.85.209.rep.mailspike.net : 127.0.0.18]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_ALL(0.00)[]; FORGED_SENDER(0.30)[cem@freebsd.org,csecem@gmail.com]; FREEMAIL_TO(0.00)[yandex.ru]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; TAGGED_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_NEQ_ENVFROM(0.00)[cem@freebsd.org,csecem@gmail.com]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[65.210.85.209.list.dnswl.org : 127.0.5.0]; IP_SCORE(-1.04)[ip: (-0.34), ipnet: 209.85.128.0/17(-3.04), asn: 15169(-1.76), country: US(-0.05)]; FREEMAIL_CC(0.00)[gmail.com]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 01 Feb 2020 17:18:20 -0000 Hi Andrey, Please try 'hint.hwpstate_intel.0.disabled=3D"1"' as a workaround for now. I think I have identified at least one problematic piece of code, although I don't know if it's the root cause. I will go ahead and fix that, which may not fix the hang, and also add some debug printfs that can be enabled to help identify the real issue. Thanks for the report and bisect. Best, Conrad On Sat, Feb 1, 2020 at 6:06 AM Andrey V. Elsukov wrote: > > 31.01.2020 18:11, Andrey V. Elsukov =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > On 24.01.2020 19:52, Andreas Nilsson wrote: > >> It hangs during kernel boot and the last message printed on console is= : > >> hwpstate_intel0: on cpu0 > > > > Hi, > > > > Did you find the cause of this hang? > > I also tried to update today from r350816 to r357330. But my Lenovo X1 > > Carbon 4th hangs on the same message. > > > > Hi, > > I have bisected the bad commit, it is r357002. > > -- > WBR, Andrey V. Elsukov > From owner-freebsd-current@freebsd.org Sat Feb 1 18:54:11 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9CEDD1FFBAD for ; Sat, 1 Feb 2020 18:54:11 +0000 (UTC) (envelope-from clay.daniels.jr@gmail.com) Received: from mail-lf1-x144.google.com (mail-lf1-x144.google.com [IPv6:2a00:1450:4864:20::144]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4893Ck5nZCz3Pfb for ; Sat, 1 Feb 2020 18:54:10 +0000 (UTC) (envelope-from clay.daniels.jr@gmail.com) Received: by mail-lf1-x144.google.com with SMTP id l18so7075581lfc.1 for ; Sat, 01 Feb 2020 10:54:10 -0800 (PST) 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=2EuZCMKDV5o1h/iuK7YlYLFFzSJ9qhipfLPGvyY8J0Q=; b=O1vPiFRGpsZvjTkF3C8lZ1fqTc4uqroyoHWDYQe6n/RVyLbJcUZrqGT/unZ91DjkGP HwQBKPbMUe0LUWHrqkbZE3b6DTsJbswvZ0GcchliajcVDjXHg03tX9B1CaJnCYJI9Q9K mwskoh2hMVi+ZrIz+QTyaz3pmitxyd5ESOSs818iXm8HGgbrICS6f6hUuqHqnJaQzf0+ vCk05c8VVhs8Wc69LhdMd0VHH/pzAK4BAUXqmaszNPpY73o6NiJTRsz1/cCqNsyd5Xtz nOhyl2RD0HO6oOCt+sPzVatoWIHljGRxITe0wCAbJLdrGoeST0hVaVZ+XsEozRJkYcJz g3jA== 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=2EuZCMKDV5o1h/iuK7YlYLFFzSJ9qhipfLPGvyY8J0Q=; b=hGJU+jDbNpiPoTlfBMceL4M1tBvFtgDk5Kd+K+8elYndYoe9lX+8E2EsM7x0kN0MNa lFwQ26+PJk7mxj+nXbf2ArSTQEsZecN0qfqN3IvMxZKKe8uvHY2M22Ks98SHUdsClHAo 4Woe8jFIfmm3GgaWs1HFqoFcVn7FfhHtg96RswsRdlQSDaA/bcRy9scMQcfMopBkH2Sz QXH8yI+jx5l6cwybYzftpiiELf35VKHhZf/gLTtDQwYoyOULBD4pKsy6kkDIyNKQZubb R4+LC4hArUiH1itzIPjgXH31dBaNjt5FE0t8AnTFwFZpmi/Sd9fCHoyRySRqANuqw9di qbsw== X-Gm-Message-State: APjAAAXZbGU/7/UrGPkYaENqHbKIvpueHDu5X1rlG7ivrSI7Xe0vyx3a 7TuxQDxWL9r5YmxKUO2sECoIQDau7TaNbFn03w== X-Google-Smtp-Source: APXvYqyox2QkhdWBI8/EdlVz3eoSQpB6WqLBc8yGl675hRbQ/RyQM/+uqq2UcawUfNQyLt9PMfWj2CuH4Q9i70tNBfQ= X-Received: by 2002:a19:5212:: with SMTP id m18mr8435720lfb.7.1580583248198; Sat, 01 Feb 2020 10:54:08 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Clay Daniels Date: Sat, 1 Feb 2020 12:53:56 -0600 Message-ID: Subject: Re: OFWBUS: How does autoconfiguration work? To: Niteesh Cc: "freebsd-current@freebsd.org" X-Rspamd-Queue-Id: 4893Ck5nZCz3Pfb X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=O1vPiFRG; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of claydanielsjr@gmail.com designates 2a00:1450:4864:20::144 as permitted sender) smtp.mailfrom=claydanielsjr@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TAGGED_RCPT(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[4.4.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; IP_SCORE(0.00)[ip: (2.59), ipnet: 2a00:1450::/32(-2.50), asn: 15169(-1.76), country: US(-0.05)]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 01 Feb 2020 18:54:11 -0000 Take a look at the Porter's Handbook: https://docs.freebsd.org/doc/7.4-RELEASE/usr/share/doc/en/books/porters-handbook/using-autotools.html On Sat, Feb 1, 2020 at 8:56 AM Niteesh wrote: > I am interested in adding autoconfiguration to one of my projects. > The current drivers use lazy initialization, for example, the UART > drivers initialize the hardware only during their first invocation. > > I would like to add a subsystem, that will read the DTB and call > the appropriate drivers. > > I want to know how it is implemented in FreeBSD, I took a look at the > code, but I am still couldn't figure out, when does FreeBSD start to > parse the DTB, how does it fill up the device struct and few more. > > Can someone please explain how all this works with reference to code > or point me to some documentation? > > Thanks, > Niteesh > _______________________________________________ > 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 Sat Feb 1 19:23:26 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C0856228E57 for ; Sat, 1 Feb 2020 19:23:26 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4893sT2Ct8z3wcf for ; Sat, 1 Feb 2020 19:23:24 +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 011JNALf048538 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 1 Feb 2020 21:23:14 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 011JNALf048538 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id 011JNA4W048537; Sat, 1 Feb 2020 21:23:10 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 1 Feb 2020 21:23:09 +0200 From: Konstantin Belousov To: Hans Petter Selasky Cc: Rick Macklem , "freebsd-current@FreeBSD.org" Subject: Re: easy way to work around a lack of a direct map on i386 Message-ID: <20200201192309.GX4808@kib.kiev.ua> References: <20200130233734.GV4808@kib.kiev.ua> <20200131123144.GW4808@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on tom.home X-Rspamd-Queue-Id: 4893sT2Ct8z3wcf X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_SPF_SOFTFAIL(0.00)[~all:c]; IP_SCORE_FREEMAIL(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(0.00)[ip: (-3.14), ipnet: 2001:470::/32(-4.66), asn: 6939(-3.58), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 01 Feb 2020 19:23:26 -0000 On Sat, Feb 01, 2020 at 01:56:59PM +0100, Hans Petter Selasky wrote: > On 2020-01-31 13:31, Konstantin Belousov wrote: > > On Fri, Jan 31, 2020 at 10:13:58AM +0100, Hans Petter Selasky wrote: > > > On 2020-01-31 00:37, Konstantin Belousov wrote: > > > > On Thu, Jan 30, 2020 at 11:23:02PM +0000, Rick Macklem wrote: > > > > > Hi, > > > > > > > > > > The current code for KERN_TLS uses PHYS_TO_DMAP() > > > > > to access unmapped external pages on m_ext.ext_pgs > > > > > mbufs. > > > > > I also need to do this to implement RPC-over-TLS. > > > > > > > > > > The problem is that some arches, like i386, don't > > > > > support PHYS_TO_DMAP(). > > > > > > > > > > Since it appears that there will be at most 4 pages on > > > > > one of these mbufs, my thinking was... > > > > > - Acquire four pages of kva from the kernel_map during > > > > > booting. > > > > > - Then just use pmap_qenter() to fill in the physical page > > > > > mappings for long enough to copy the data. > > > > > > > > > > Does this sound reasonable? > > > > > Is there a better way? > > > > > > > > Use sfbufs, they should work on all arches. In essence, they provide MI > > > > interface to DMAP where possible. I do not remember did I bumped the > > > > limit for i386 after 4/4 went in. > > > > > > > > There is currently no limits for sfbufs use per subsystem, but I think it > > > > is not very likely to cause too much troubles. Main rule is to not sleep > > > > waiting for more sfbufs if you already own one.. > > > > > > In the DRM-KMS LinuxKPI we have: > > > > > > void * > > > kmap(vm_page_t page) > > > { > > > #ifdef LINUXKPI_HAVE_DMAP > > > vm_offset_t daddr; > > > > > > daddr = PHYS_TO_DMAP(VM_PAGE_TO_PHYS(page)); > > > > > > return ((void *)daddr); > > > #else > > > struct sf_buf *sf; > > > > > > sched_pin(); > > > sf = sf_buf_alloc(page, SFB_NOWAIT | SFB_CPUPRIVATE); > > > if (sf == NULL) { > > > sched_unpin(); > > > return (NULL); > > > } > > > return ((void *)sf_buf_kva(sf)); > > > #endif > > > } > > > > > > void > > > kunmap(vm_page_t page) > > > { > > > #ifdef LINUXKPI_HAVE_DMAP > > > /* NOP */ > > > #else > > > struct sf_buf *sf; > > > > > > /* lookup SF buffer in list */ > > > sf = sf_buf_alloc(page, SFB_NOWAIT | SFB_CPUPRIVATE); > > > > > > /* double-free */ > > > sf_buf_free(sf); > > > sf_buf_free(sf); > > > > > > sched_unpin(); > > > #endif > > > } > > > > > > I think that is the fastest way to do this. > > > > So the kmap address is only valid on the CPU that called the function ? > > This is strange, I was not able to find mention of it in references to > > kmap. > > Yes, only on the current CPU. See the SFB_CPUPRIVATE flag. I can read the FreeBSD code. But I did not found a mention that Linux kmap() only invalidates TLB on the core that called it. From owner-freebsd-current@freebsd.org Sat Feb 1 22:26:28 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9F3E022E8B4 for ; Sat, 1 Feb 2020 22:26:28 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4897wh3kB9z48q5; Sat, 1 Feb 2020 22:26:28 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: by mail-lj1-x235.google.com with SMTP id a13so10790248ljm.10; Sat, 01 Feb 2020 14:26:28 -0800 (PST) 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=mNsKzrA2he6Nx6ukPdZ1vrXU+puwU9dFYkWXYYsP4d8=; b=jTc78Mu4DK6Xyhp3JIcgEISAqDG+z56RR2HpdAEYzOw2lJABK4IF8SsAtoyYLaZ4yr OFY4vbvmeYGP53C4eQnlmN92tyeSI3D/mMUbBGXHwpBCcPI0fta6hxvHpL2Pv+MJecWn KzOMU7u0seQ2iB5NB6+QMT5rpKB5HtAKKzyo1kyj7CQKYSbZSXTgdVxUF2t2xqVrsIBJ wzowKpWUHlXI4wL1K70R8jhBNfQeFUM0ThnVE29oi3QT4d7vMqZ9qoOgKXWnF+XyUxpA IJLNpcCAtGB2Ghw0QAdaT5epV8IepW/lCfuUgrpoo6O2UYB/zGmSQdTyCVHO3IUGqYJB Tk/A== 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=mNsKzrA2he6Nx6ukPdZ1vrXU+puwU9dFYkWXYYsP4d8=; b=f2v72DOgGhgVOk8qBjiopokzEEpXF+JIa6lHqycJ2usxYlNYHjM4grrM/23fSiYN9Y 4bEYIq6cmteluE4R0eiCkuf6/gjJBiKJOn5R2g4XuNcavcIQv/1APE5tOcCqmI0uO/0A PgQeJ7WG2knv0olo+7LdO99/tJWzuohKhjYGIRswluxp+8jOaIrFJo8oecePXRZ+fFRv P3Y/iu94WqaAZMMcJueOxuqKgRiqWw0hkXPwQ18VOBJUXnlYHF6vTJU8Y4Pdc5mxb7to g6B/OiYMoiE4qmfKu0b3lIjZwAzeF/h/Ch3NpyvX9WMDnYnfOA7aTl3MHsu1GscqDsCV dpXw== X-Gm-Message-State: APjAAAWMkIQ5gWRTATtc/IJd5/72ZvaEEKrOVQyCgnnGneRTWxUC70d5 U34/AK70PNW818n8791+v3oaDV/JiFIFC+noHeAUTA== X-Google-Smtp-Source: APXvYqzXz9+oZ0dcPJ7cqQRVZM95bmS0wHgi/n+vFrtvtj7Tvg5cXnCdEZYguWIpIS1y0oGrLCjHCCCoKYiy9WTg67A= X-Received: by 2002:a05:651c:1072:: with SMTP id y18mr10017976ljm.243.1580595986492; Sat, 01 Feb 2020 14:26:26 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Andreas Nilsson Date: Sat, 1 Feb 2020 23:26:15 +0100 Message-ID: Subject: Re: hwpstate_intel hangs kernel To: cem@freebsd.org Cc: "Andrey V. Elsukov" , Current FreeBSD X-Rspamd-Queue-Id: 4897wh3kB9z48q5 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: 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, 01 Feb 2020 22:26:28 -0000 Hello Conrad, thank you Andrey for bisecting! I'll try with that hint and see how it works for me. Best regards Andreas On Sat, Feb 1, 2020, 18:18 Conrad Meyer wrote: > Hi Andrey, > > Please try 'hint.hwpstate_intel.0.disabled=3D"1"' as a workaround for now= . > > I think I have identified at least one problematic piece of code, > although I don't know if it's the root cause. I will go ahead and fix > that, which may not fix the hang, and also add some debug printfs that > can be enabled to help identify the real issue. > > Thanks for the report and bisect. > > Best, > Conrad > > On Sat, Feb 1, 2020 at 6:06 AM Andrey V. Elsukov > wrote: > > > > 31.01.2020 18:11, Andrey V. Elsukov =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > > On 24.01.2020 19:52, Andreas Nilsson wrote: > > >> It hangs during kernel boot and the last message printed on console > is: > > >> hwpstate_intel0: on cpu0 > > > > > > Hi, > > > > > > Did you find the cause of this hang? > > > I also tried to update today from r350816 to r357330. But my Lenovo X= 1 > > > Carbon 4th hangs on the same message. > > > > > > > Hi, > > > > I have bisected the bad commit, it is r357002. > > > > -- > > WBR, Andrey V. Elsukov > > >