From owner-freebsd-current@freebsd.org Sun Sep 20 00:10: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 4ADC93F39BA; Sun, 20 Sep 2020 00:10:01 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Bv7HX4ZHZz3SWc; Sun, 20 Sep 2020 00:10:00 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 08K09wYb047845 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 19 Sep 2020 17:09:58 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 08K09wC9047844; Sat, 19 Sep 2020 17:09:58 -0700 (PDT) (envelope-from sgk) Date: Sat, 19 Sep 2020 17:09:58 -0700 From: Steve Kargl To: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: [PATCH] libm -- fix expl kernels Message-ID: <20200920000958.GA47838@troutmask.apl.washington.edu> References: <20200919235849.GA47701@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200919235849.GA47701@troutmask.apl.washington.edu> X-Rspamd-Queue-Id: 4Bv7HX4ZHZz3SWc X-Spamd-Bar: - X-Spamd-Result: default: False [-1.45 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM,none]; NEURAL_HAM_MEDIUM(-0.55)[-0.552]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.35)[-0.350]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_SHORT(-0.55)[-0.549]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers,freebsd-current]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 20 Sep 2020 00:10:01 -0000 On Sat, Sep 19, 2020 at 04:58:49PM -0700, Steve Kargl wrote: > The following patch fixes the ld80 and ld128 kernels for expl(x). Subj: is slightly wrong. This fixes the cexpl(z) kernels. > I can't test ld128, so that patch is untested. > > . Micro-optimization: use sincosl(x) instead of a call to cosl(x) and > a call to sinl(x). Argument reduction is done once not twice. This part also fixes a cos(x) that should be cosl(x). > . Use a long double constant instead of an invalid double constant. > . Spell scale2 correctly -- Steve From owner-freebsd-current@freebsd.org Sun Sep 20 00:25:09 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 19C6B3F446C; Sun, 20 Sep 2020 00:25:09 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Bv7d014F3z3TQ7; Sun, 20 Sep 2020 00:25:07 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 08K0P6sW047957 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 19 Sep 2020 17:25:06 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 08K0P68C047956; Sat, 19 Sep 2020 17:25:06 -0700 (PDT) (envelope-from sgk) Date: Sat, 19 Sep 2020 17:25:06 -0700 From: Steve Kargl To: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: [PATCH] libm -- optimize __ldexp_cexp[f] Message-ID: <20200920002506.GA47948@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Queue-Id: 4Bv7d014F3z3TQ7 X-Spamd-Bar: - X-Spamd-Result: default: False [-1.48 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.37)[-0.371]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_MEDIUM(-0.56)[-0.561]; NEURAL_HAM_SHORT(-0.55)[-0.552]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-hackers,freebsd-current]; DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM, none] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 20 Sep 2020 00:25:09 -0000 The following patch is an opimization for he kernels used by cexp(x) and cexpf(x). . Use sincos[f] instead of a call to cos[f] and a call to sin[f]. . While here, alphabetize declaration. --- /usr/src/lib/msun/src/k_exp.c 2019-02-23 07:45:03.879997000 -0800 +++ src/k_exp.c 2019-12-26 08:15:30.109189000 -0800 @@ -88,7 +88,7 @@ double complex __ldexp_cexp(double complex z, int expt) { - double x, y, exp_x, scale1, scale2; + double c, exp_x, s, scale1, scale2, x, y; int ex_expt, half_expt; x = creal(z); @@ -105,6 +105,7 @@ half_expt = expt - half_expt; INSERT_WORDS(scale2, (0x3ff + half_expt) << 20, 0); - return (CMPLX(cos(y) * exp_x * scale1 * scale2, - sin(y) * exp_x * scale1 * scale2)); + sincos(y, &s, &c); + return (CMPLX(c * exp_x * scale1 * scale2, + s * exp_x * scale1 * scale2)); } --- /usr/src/lib/msun/src/k_expf.c 2019-02-23 07:45:03.881215000 -0800 +++ src/k_expf.c 2019-12-26 08:15:30.109818000 -0800 @@ -71,7 +71,7 @@ float complex __ldexp_cexpf(float complex z, int expt) { - float x, y, exp_x, scale1, scale2; + float c, exp_x, s, scale1, scale2, x, y; int ex_expt, half_expt; x = crealf(z); @@ -84,6 +84,7 @@ half_expt = expt - half_expt; SET_FLOAT_WORD(scale2, (0x7f + half_expt) << 23); - return (CMPLXF(cosf(y) * exp_x * scale1 * scale2, - sinf(y) * exp_x * scale1 * scale2)); + sincosf(y, &s, &c); + return (CMPLXF(c * exp_x * scale1 * scale2, + s * exp_x * scale1 * scale2)); } -- Steve From owner-freebsd-current@freebsd.org Sun Sep 20 06:04: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 518FE3FD1DB for ; Sun, 20 Sep 2020 06:04:50 +0000 (UTC) (envelope-from monochrome@twcny.rr.com) Received: from p-impout007.msg.pkvw.co.charter.net (p-impout007aa.msg.pkvw.co.charter.net [47.43.26.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 4BvH8x2tPQz46KY for ; Sun, 20 Sep 2020 06:04:48 +0000 (UTC) (envelope-from monochrome@twcny.rr.com) Received: from [192.168.13.11] ([45.47.33.158]) by cmsmtp with ESMTP id JsSmkvc2yqjkdJsSnkkcwx; Sun, 20 Sep 2020 06:04:41 +0000 X-Authority-Analysis: v=2.3 cv=SZ2JicZu c=1 sm=1 tr=0 a=VvwePSPmDFBOGFNvGtd2Cw==:117 a=VvwePSPmDFBOGFNvGtd2Cw==:17 a=IkcTkHD0fZMA:10 a=ayC55rCoAAAA:8 a=6I5d2MoRAAAA:8 a=Si1dHKV7pZUPO2TtzEEA:9 a=6hCoL-fdDz8rA61w:21 a=xAVJ3MhGMA2rUQB7:21 a=QEXdDO2ut3YA:10 a=B_RyunTPg8udlmYm5Cu2:22 a=IjZwj45LgO3ly-622nXo:22 Subject: Re: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X To: Rainer Hurling References: <69ff9432-fc8f-b0ab-8ad2-8e3daa77f8e1@twcny.rr.com> <1a88773b-d2fa-a790-c7e2-868d3884ba8b@twcny.rr.com> <865D6BF0-9F1E-4125-81D3-FB9A369FED8D@gwdg.de> Cc: freebsd-current@freebsd.org From: monochrome Message-ID: <88af31d4-9ed9-172a-d48f-1780f19841e3@twcny.rr.com> Date: Sun, 20 Sep 2020 02:04:40 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.2.2 MIME-Version: 1.0 In-Reply-To: <865D6BF0-9F1E-4125-81D3-FB9A369FED8D@gwdg.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfJuSF6Orb9vT2fSzHI+cEIp047eTeQyD32xWgpmkT1QTuhS1hzH0ynMqTAE3VED9Ae226gc4BsmKoDKVoK7Ra++iZIedIQaRgvazwvcUkNE8TZAzasYt 0OR8gg94Rzlsw8HTN5j0xHUbzMYXXYYAxlwJ42r4jzCNOCcasfe3YHA4RvsZLRYhGQryxr2YLoifomL9Fg+GjH7RzrYO1DGchl0= X-Rspamd-Queue-Id: 4BvH8x2tPQz46KY X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.68 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[45.47.33.158:received]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:47.43.26.0/24]; NEURAL_HAM_LONG(-1.02)[-1.016]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[rr.com]; NEURAL_HAM_MEDIUM(-1.02)[-1.024]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.34)[-0.337]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:40294, ipnet:47.43.24.0/21, country:US]; MIME_TRACE(0.00)[0:+]; MAILMAN_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 20 Sep 2020 06:04:50 -0000 I have confirmed that r365487 is the last kernel that will boot on my 2400G. These are the files changed between r365487 and r365488: U sys/vm/phys_pager.c U sys/vm/vm_object.c U sys/vm/vm_object.h U sys/vm/vm_pager.h On 9/18/20 8:57 AM, Rainer Hurling wrote: > Hi, > I am AFK until Sunday, so can't investigate ATM. > And no, I haven't solved it until now. Thanks for your report. > Rainer > > Am 18. September 2020 00:38:31 MESZ schrieb monochrome : >> >> forgot you >> >> -------- Forwarded Message -------- >> Subject: Re: r365488 page faults on AMD Ryzen 9 3950X >> Date: Thu, 17 Sep 2020 17:03:49 -0400 >> From: monochrome >> To: freebsd-current@freebsd.org >> >> I am also having this problem. Have you resolved it? Mine is a Ryzen 5 2400G >> >> On 9/12/20 5:22 AM, Rainer Hurling wrote: >>> Since r365488 (and above until recent) my box breaks with the following >>> error when starting: >>> >>> Fatal trap 12: page fault while in kernel mode >>> cpuid = 31; apic id = 1f >>> fault virtual address = 0x0 >>> fault code = supervisor read data, page not present >>> instruction pointer = 0x20:0xffffffff808f452b >>> stack pointer = 0x28:0xffffffff81711800 >>> frame pointer = 0x28:0xffffffff81711800 >>> code segment = base 0x0, limit 0xfffff, type 0x1b >>> = DPL 0, pres 1, long 1, def32 0, gran 1 >>> processor eflags = interrupt enabled, resume, IOPL = 0 >>> current process = 0 (swapper) >>> trap number = 12 >>> panic: page fault >>> cpuid = 31 >>> time = 1 >>> >>> >>> >>> Some infos about the system, the page fault occurs: >>> >>> CPU: AMD Ryzen 9 3950X 16-Core Processor (3493.50-MHz >>> K8-class CPU) >>> Origin="AuthenticAMD" Id=0x870f10 Family=0x17 Model=0x71 Stepping=0 >>> Features=0x178bfbff >>> Features2=0x7ed8320b >>> AMD Features=0x2e500800 >>> AMD >>> Features2=0x75c237ff >>> Structured Extended >>> Features=0x219c91a9 >>> Structured Extended Features2=0x400004 >>> XSAVE Features=0xf >>> AMD Extended Feature Extensions ID >>> EBX=0x108b657 >>> SVM: (disabled in BIOS) NP,NRIP,VClean,AFlush,DAssist,NAsids=32768 >>> TSC: P-state invariant, performance statistics >>> real memory = 68717379584 (65534 MB) >>> avail memory = 66756149248 (63663 MB) >>> Event timer "LAPIC" quality 600 >>> >>> >>> #cat /etc/sysctl.conf >>> security.bsd.map_at_zero=1 >>> kern.module_path=/boot/kernel;/boot/modules;/usr/local/modules >>> kern.evdev.rcpt_mask=6 >>> kern.maxfiles=49312 >>> kern.ipc.shm_allow_removed=1 >>> kern.ipc.maxsockbuf=16777216 >>> vfs.usermount=1 >>> net.inet.tcp.rfc1323=1 >>> net.inet.tcp.sack.enable=1 >>> net.inet.tcp.sendbuf_auto=1 >>> net.inet.tcp.recvbuf_auto=1 >>> net.inet.tcp.sendbuf_max=16777216 >>> net.inet.tcp.recvbuf_max=16777216 >>> net.inet6.ip6.use_tempaddr=1 >>> net.inet6.ip6.prefer_tempaddr=1 >>> net.local.stream.recvspace=65536 >>> net.local.stream.sendspace=65536 >>> >>> >>> Please let me know, if I should provide more info or test something. >>> Thanks in advance, >>> Rainer >>> _______________________________________________ >>> 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" >>> >> _______________________________________________ >> 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 Sep 20 07:56:56 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 C60093FF33D for ; Sun, 20 Sep 2020 07:56:56 +0000 (UTC) (envelope-from xxjack12xx@gmail.com) Received: from mail-qk1-x741.google.com (mail-qk1-x741.google.com [IPv6:2607:f8b0:4864:20::741]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4BvKfJ05rnz4D7t for ; Sun, 20 Sep 2020 07:56:55 +0000 (UTC) (envelope-from xxjack12xx@gmail.com) Received: by mail-qk1-x741.google.com with SMTP id o16so11718738qkj.10 for ; Sun, 20 Sep 2020 00:56:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6cCxRUwqMK3neqQtbXHR0U+Mt2x/5hgbS8/neFoB3EY=; b=rfQDXdddVs/Bb0z2Nmwjn8GaLINBTy/28rFkgI++9O+T+mDuWM34LhpmbJC0hG0Cl1 1gFkV/f1ipJAHtFnevNeaAoE3DKXYPs6TXPnbq7CpWAFwdAQyfUZWZsAjzgjkQI8d9xj fH9qmdkW6kAz/h72vsQ4JvGuM4iSHYh2YwAGJ5xropONbrbsuaQrm5sQczpJY5yu4nDM MU/Fa8CstCGAY+m9oPS8nIEzlKO7y/y8ZdWs04tol9ZVLUcJAhiJm+zxYzqFGUYymNIJ 6XZnLRI5TpZLIL/GhlxD5TY2Z9kdEbIAWn08dyahd1DQWO5YMHGG5LEM8C2Pbcjjs/4w hXQw== X-Gm-Message-State: AOAM530CeNzpiZZXXQJaqEUCAtnaa3f8gIbiRndTNnFHgzRIIRNicBmU WrvikVV7q+HsLK7H3NSswU9TCmaYmTiBX2dLows= X-Google-Smtp-Source: ABdhPJzTI1Awn+sQcq50JAf67w6FiGfvHici0t52D7hgYt/84fAX9EbXeH5dRWgsvfNBdWt138mbdcgjrrZXHWl1to0= X-Received: by 2002:ae9:e601:: with SMTP id z1mr38152838qkf.1.1600588614582; Sun, 20 Sep 2020 00:56:54 -0700 (PDT) MIME-Version: 1.0 References: <69ff9432-fc8f-b0ab-8ad2-8e3daa77f8e1@twcny.rr.com> <1a88773b-d2fa-a790-c7e2-868d3884ba8b@twcny.rr.com> <865D6BF0-9F1E-4125-81D3-FB9A369FED8D@gwdg.de> <88af31d4-9ed9-172a-d48f-1780f19841e3@twcny.rr.com> In-Reply-To: <88af31d4-9ed9-172a-d48f-1780f19841e3@twcny.rr.com> From: "Jack L." Date: Sun, 20 Sep 2020 00:56:18 -0700 Message-ID: Subject: Re: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X To: monochrome Cc: Rainer Hurling , freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4BvKfJ05rnz4D7t X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.13 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; NEURAL_HAM_MEDIUM(-1.01)[-1.011]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-1.04)[-1.041]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::741:from]; NEURAL_HAM_SHORT(-1.08)[-1.075]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-current]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 20 Sep 2020 07:56:56 -0000 I also have the exact same panic on a Dell motherboard with a Haswell processor. On Sat, Sep 19, 2020 at 11:05 PM monochrome wrote: > > I have confirmed that r365487 is the last kernel that will boot on my > 2400G. These are the files changed between r365487 and r365488: > > U sys/vm/phys_pager.c > U sys/vm/vm_object.c > U sys/vm/vm_object.h > U sys/vm/vm_pager.h > > > > On 9/18/20 8:57 AM, Rainer Hurling wrote: > > Hi, > > I am AFK until Sunday, so can't investigate ATM. > > And no, I haven't solved it until now. Thanks for your report. > > Rainer > > > > Am 18. September 2020 00:38:31 MESZ schrieb monochrome : > >> > >> forgot you > >> > >> -------- Forwarded Message -------- > >> Subject: Re: r365488 page faults on AMD Ryzen 9 3950X > >> Date: Thu, 17 Sep 2020 17:03:49 -0400 > >> From: monochrome > >> To: freebsd-current@freebsd.org > >> > >> I am also having this problem. Have you resolved it? Mine is a Ryzen 5 2400G > >> > >> On 9/12/20 5:22 AM, Rainer Hurling wrote: > >>> Since r365488 (and above until recent) my box breaks with the following > >>> error when starting: > >>> > >>> Fatal trap 12: page fault while in kernel mode > >>> cpuid = 31; apic id = 1f > >>> fault virtual address = 0x0 > >>> fault code = supervisor read data, page not present > >>> instruction pointer = 0x20:0xffffffff808f452b > >>> stack pointer = 0x28:0xffffffff81711800 > >>> frame pointer = 0x28:0xffffffff81711800 > >>> code segment = base 0x0, limit 0xfffff, type 0x1b > >>> = DPL 0, pres 1, long 1, def32 0, gran 1 > >>> processor eflags = interrupt enabled, resume, IOPL = 0 > >>> current process = 0 (swapper) > >>> trap number = 12 > >>> panic: page fault > >>> cpuid = 31 > >>> time = 1 > >>> > >>> > >>> > >>> Some infos about the system, the page fault occurs: > >>> > >>> CPU: AMD Ryzen 9 3950X 16-Core Processor (3493.50-MHz > >>> K8-class CPU) > >>> Origin="AuthenticAMD" Id=0x870f10 Family=0x17 Model=0x71 Stepping=0 > >>> Features=0x178bfbff > >>> Features2=0x7ed8320b > >>> AMD Features=0x2e500800 > >>> AMD > >>> Features2=0x75c237ff > >>> Structured Extended > >>> Features=0x219c91a9 > >>> Structured Extended Features2=0x400004 > >>> XSAVE Features=0xf > >>> AMD Extended Feature Extensions ID > >>> EBX=0x108b657 > >>> SVM: (disabled in BIOS) NP,NRIP,VClean,AFlush,DAssist,NAsids=32768 > >>> TSC: P-state invariant, performance statistics > >>> real memory = 68717379584 (65534 MB) > >>> avail memory = 66756149248 (63663 MB) > >>> Event timer "LAPIC" quality 600 > >>> > >>> > >>> #cat /etc/sysctl.conf > >>> security.bsd.map_at_zero=1 > >>> kern.module_path=/boot/kernel;/boot/modules;/usr/local/modules > >>> kern.evdev.rcpt_mask=6 > >>> kern.maxfiles=49312 > >>> kern.ipc.shm_allow_removed=1 > >>> kern.ipc.maxsockbuf=16777216 > >>> vfs.usermount=1 > >>> net.inet.tcp.rfc1323=1 > >>> net.inet.tcp.sack.enable=1 > >>> net.inet.tcp.sendbuf_auto=1 > >>> net.inet.tcp.recvbuf_auto=1 > >>> net.inet.tcp.sendbuf_max=16777216 > >>> net.inet.tcp.recvbuf_max=16777216 > >>> net.inet6.ip6.use_tempaddr=1 > >>> net.inet6.ip6.prefer_tempaddr=1 > >>> net.local.stream.recvspace=65536 > >>> net.local.stream.sendspace=65536 > >>> > >>> > >>> Please let me know, if I should provide more info or test something. > >>> Thanks in advance, > >>> Rainer > >>> _______________________________________________ > >>> 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" > >>> > >> _______________________________________________ > >> 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" > _______________________________________________ > 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 Sep 20 08:05: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 AF3213FF91A for ; Sun, 20 Sep 2020 08:05:44 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from gmailer.gwdg.de (gmailer.gwdg.de [134.76.11.17]) (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 4BvKrR53z9z4DTj; Sun, 20 Sep 2020 08:05:43 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from excmbx-03.um.gwdg.de ([134.76.9.218] helo=email.gwdg.de) by mailer.gwdg.de with esmtp (GWDG Mailer) (envelope-from ) id 1kJuLt-00031z-3J; Sun, 20 Sep 2020 10:05:41 +0200 Received: from krabat.raven.hur (10.250.9.199) by EXCMBX-03.um.gwdg.de (134.76.9.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2044.4; Sun, 20 Sep 2020 10:05:40 +0200 Subject: Re: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X To: monochrome , CC: References: <69ff9432-fc8f-b0ab-8ad2-8e3daa77f8e1@twcny.rr.com> <1a88773b-d2fa-a790-c7e2-868d3884ba8b@twcny.rr.com> <865D6BF0-9F1E-4125-81D3-FB9A369FED8D@gwdg.de> <88af31d4-9ed9-172a-d48f-1780f19841e3@twcny.rr.com> From: Rainer Hurling Message-ID: <11d27d41-029a-d7f5-eccc-0ba3a3fcfe97@gwdg.de> Date: Sun, 20 Sep 2020 10:05:35 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <88af31d4-9ed9-172a-d48f-1780f19841e3@twcny.rr.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [10.250.9.199] X-ClientProxiedBy: excmbx-14.um.gwdg.de (134.76.9.225) To EXCMBX-03.um.gwdg.de (134.76.9.218) X-Virus-Scanned: (clean) by clamav X-Rspamd-Queue-Id: 4BvKrR53z9z4DTj X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.45 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_VERYGOOD(0.00)[134.76.11.17:from]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEFALL_USER(0.00)[rhurlin]; R_SPF_ALLOW(-0.20)[+ip4:134.76.10.0/23]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[gwdg.de]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.03)[-1.030]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[134.76.11.17:from]; NEURAL_HAM_SHORT(-0.87)[-0.869]; NEURAL_HAM_MEDIUM(-1.05)[-1.046]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:680, ipnet:134.76.0.0/16, country:DE]; RCVD_TLS_LAST(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 20 Sep 2020 08:05:44 -0000 Hi monochrome, back to keyboard, it tried newest CURRENT (r365920) on my box and even with newest sources the error occurs. After looking around somewhat more, I found some hints about Virtualbox kernel module having problems with r365488. Unfortunately, I am not able to find the thread again :( What seems to help as a workaround is to disable the loading of VirtualBox in /boot/loader.conf #vboxdrv_load="YES" and in /etc/rc.conf #vboxnet_enable="YES" #vboxguest_enable="YES" So probably, this page fault is not restricted to AMD Ryzen? HTH, Rainer Am 20.09.20 um 08:04 schrieb monochrome: > I have confirmed that r365487 is the last kernel that will boot on my > 2400G. These are the files changed between r365487 and r365488: > > U    sys/vm/phys_pager.c > U    sys/vm/vm_object.c > U    sys/vm/vm_object.h > U    sys/vm/vm_pager.h > > > > On 9/18/20 8:57 AM, Rainer Hurling wrote: >> Hi, >> I am AFK until Sunday, so can't investigate ATM. >> And no, I haven't solved it until now. Thanks for your report. >> Rainer >> >> Am 18. September 2020 00:38:31 MESZ schrieb monochrome >> : >>> >>> forgot you >>> >>> -------- Forwarded Message -------- >>> Subject: Re: r365488 page faults on AMD Ryzen 9 3950X >>> Date: Thu, 17 Sep 2020 17:03:49 -0400 >>> From: monochrome >>> To: freebsd-current@freebsd.org >>> >>> I am also having this problem. Have you resolved it? Mine is a Ryzen >>> 5 2400G >>> >>> On 9/12/20 5:22 AM, Rainer Hurling wrote: >>>> Since r365488 (and above until recent) my box breaks with the following >>>> error when starting: >>>> >>>> Fatal trap 12: page fault while in kernel mode >>>> cpuid = 31; apic id = 1f >>>> fault virtual address   = 0x0 >>>> fault code              = supervisor read data, page not present >>>> instruction pointer     = 0x20:0xffffffff808f452b >>>> stack pointer           = 0x28:0xffffffff81711800 >>>> frame pointer           = 0x28:0xffffffff81711800 >>>> code segment            = base 0x0, limit 0xfffff, type 0x1b >>>>                           = DPL 0, pres 1, long 1, def32 0, gran 1 >>>> processor eflags        = interrupt enabled, resume, IOPL = 0 >>>> current process         = 0 (swapper) >>>> trap number             = 12 >>>> panic: page fault >>>> cpuid = 31 >>>> time = 1 >>>> >>>> >>>> >>>> Some infos about the system, the page fault occurs: >>>> >>>> CPU: AMD Ryzen 9 3950X 16-Core Processor             (3493.50-MHz >>>> K8-class CPU) >>>>     Origin="AuthenticAMD"  Id=0x870f10  Family=0x17  Model=0x71  >>>> Stepping=0 >>>> Features=0x178bfbff >>>> >>>> Features2=0x7ed8320b >>>> >>>>     AMD Features=0x2e500800 >>>>     AMD >>>> Features2=0x75c237ff >>>> >>>>     Structured Extended >>>> Features=0x219c91a9 >>>> >>>>     Structured Extended Features2=0x400004 >>>>     XSAVE Features=0xf >>>>     AMD Extended Feature Extensions ID >>>> EBX=0x108b657 >>>>     SVM: (disabled in BIOS) NP,NRIP,VClean,AFlush,DAssist,NAsids=32768 >>>>     TSC: P-state invariant, performance statistics >>>> real memory  = 68717379584 (65534 MB) >>>> avail memory = 66756149248 (63663 MB) >>>> Event timer "LAPIC" quality 600 >>>> >>>> >>>> #cat /etc/sysctl.conf >>>> security.bsd.map_at_zero=1 >>>> kern.module_path=/boot/kernel;/boot/modules;/usr/local/modules >>>> kern.evdev.rcpt_mask=6 >>>> kern.maxfiles=49312 >>>> kern.ipc.shm_allow_removed=1 >>>> kern.ipc.maxsockbuf=16777216 >>>> vfs.usermount=1 >>>> net.inet.tcp.rfc1323=1 >>>> net.inet.tcp.sack.enable=1 >>>> net.inet.tcp.sendbuf_auto=1 >>>> net.inet.tcp.recvbuf_auto=1 >>>> net.inet.tcp.sendbuf_max=16777216 >>>> net.inet.tcp.recvbuf_max=16777216 >>>> net.inet6.ip6.use_tempaddr=1 >>>> net.inet6.ip6.prefer_tempaddr=1 >>>> net.local.stream.recvspace=65536 >>>> net.local.stream.sendspace=65536 >>>> >>>> >>>> Please let me know, if I should provide more info or test something. >>>> Thanks in advance, >>>> Rainer >>>> _______________________________________________ >>>> 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" >>>> >>> _______________________________________________ >>> 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 Sep 20 08:20: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 673CB3FFB73 for ; Sun, 20 Sep 2020 08:20:53 +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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BvL9w4GVnz4FLw; Sun, 20 Sep 2020 08:20:52 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2020.home.selasky.org (unknown [178.17.145.105]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 629132601CA; Sun, 20 Sep 2020 10:20:49 +0200 (CEST) Subject: Re: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X To: Rainer Hurling , monochrome , rhurlin@FreeBSD.org Cc: freebsd-current@freebsd.org References: <69ff9432-fc8f-b0ab-8ad2-8e3daa77f8e1@twcny.rr.com> <1a88773b-d2fa-a790-c7e2-868d3884ba8b@twcny.rr.com> <865D6BF0-9F1E-4125-81D3-FB9A369FED8D@gwdg.de> <88af31d4-9ed9-172a-d48f-1780f19841e3@twcny.rr.com> <11d27d41-029a-d7f5-eccc-0ba3a3fcfe97@gwdg.de> From: Hans Petter Selasky Message-ID: Date: Sun, 20 Sep 2020 10:20:17 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <11d27d41-029a-d7f5-eccc-0ba3a3fcfe97@gwdg.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4BvL9w4GVnz4FLw X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.51 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; NEURAL_HAM_LONG(-1.05)[-1.054]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.13)[-0.128]; NEURAL_HAM_MEDIUM(-1.03)[-1.027]; 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]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 20 Sep 2020 08:20:53 -0000 On 2020-09-20 10:05, Rainer Hurling wrote: > Hi monochrome, > > back to keyboard, it tried newest CURRENT (r365920) on my box and even > with newest sources the error occurs. > > After looking around somewhat more, I found some hints about Virtualbox > kernel module having problems with r365488. Unfortunately, I am not able > to find the thread again :( > > What seems to help as a workaround is to disable the loading of > VirtualBox in /boot/loader.conf > > #vboxdrv_load="YES" > > and in /etc/rc.conf > > #vboxnet_enable="YES" > #vboxguest_enable="YES" > > > So probably, this page fault is not restricted to AMD Ryzen? > Possibly you need to rebuild that kernel module. Maybe the FreeBSD version was not bumped correctly. --HPS From owner-freebsd-current@freebsd.org Sun Sep 20 08:26:14 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 72B5D3D85B0 for ; Sun, 20 Sep 2020 08:26:14 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from gmailer.gwdg.de (gmailer.gwdg.de [134.76.11.17]) (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 4BvLJ56FgQz4Fnq for ; Sun, 20 Sep 2020 08:26:13 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from excmbx-03.um.gwdg.de ([134.76.9.218] helo=email.gwdg.de) by mailer.gwdg.de with esmtp (GWDG Mailer) (envelope-from ) id 1kJufk-0005MI-Cp; Sun, 20 Sep 2020 10:26:12 +0200 Received: from krabat.raven.hur (10.250.9.199) by EXCMBX-03.um.gwdg.de (134.76.9.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2044.4; Sun, 20 Sep 2020 10:26:11 +0200 Subject: Re: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X To: Hans Petter Selasky , monochrome CC: References: <69ff9432-fc8f-b0ab-8ad2-8e3daa77f8e1@twcny.rr.com> <1a88773b-d2fa-a790-c7e2-868d3884ba8b@twcny.rr.com> <865D6BF0-9F1E-4125-81D3-FB9A369FED8D@gwdg.de> <88af31d4-9ed9-172a-d48f-1780f19841e3@twcny.rr.com> <11d27d41-029a-d7f5-eccc-0ba3a3fcfe97@gwdg.de> Reply-To: From: Rainer Hurling Message-ID: <2bbfb4b3-92e9-b3ca-9c31-6c513cee2f2d@gwdg.de> Date: Sun, 20 Sep 2020 10:26:11 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.250.9.199] X-ClientProxiedBy: EXCMBX-23.um.gwdg.de (134.76.9.233) To EXCMBX-03.um.gwdg.de (134.76.9.218) X-Virus-Scanned: (clean) by clamav X-Rspamd-Queue-Id: 4BvLJ56FgQz4Fnq X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.40 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[rhurlin@FreeBSD.org]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:134.76.10.0/23:c]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; REPLYTO_DOM_NEQ_FROM_DOM(0.00)[]; RWL_MAILSPIKE_VERYGOOD(0.00)[134.76.11.17:from]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[gwdg.de]; FREEFALL_USER(0.00)[rhurlin]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[134.76.11.17:from]; NEURAL_HAM_SHORT(-0.82)[-0.824]; NEURAL_HAM_MEDIUM(-1.04)[-1.044]; NEURAL_HAM_LONG(-1.03)[-1.035]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:680, ipnet:134.76.0.0/16, country:DE]; RCVD_TLS_LAST(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 20 Sep 2020 08:26:14 -0000 Am 20.09.20 um 10:20 schrieb Hans Petter Selasky: > On 2020-09-20 10:05, Rainer Hurling wrote: >> Hi monochrome, >> >> back to keyboard, it tried newest CURRENT (r365920) on my box and even >> with newest sources the error occurs. >> >> After looking around somewhat more, I found some hints about Virtualbox >> kernel module having problems with r365488. Unfortunately, I am not able >> to find the thread again :( >> >> What seems to help as a workaround is to disable the loading of >> VirtualBox in /boot/loader.conf >> >> #vboxdrv_load="YES" >> >> and in /etc/rc.conf >> >> #vboxnet_enable="YES" >> #vboxguest_enable="YES" >> >> >> So probably, this page fault is not restricted to AMD Ryzen? >> > > Possibly you need to rebuild that kernel module. Maybe the FreeBSD > version was not bumped correctly. > > --HPS > Thanks for the hint. But I did rebuild all kernel modules before rebooting, in my case vbox*.ko, nvidia*.ko. Best wishes, Rainer From owner-freebsd-current@freebsd.org Sun Sep 20 09:38: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 2EAF93DA648 for ; Sun, 20 Sep 2020 09:38:24 +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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BvMvM0DR7z4KFR; Sun, 20 Sep 2020 09:38:22 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 08K9cFSZ049291 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 20 Sep 2020 12:38:18 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 08K9cFSZ049291 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 08K9cEox049290; Sun, 20 Sep 2020 12:38:14 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 20 Sep 2020 12:38:14 +0300 From: Konstantin Belousov To: rhurlin@freebsd.org Cc: Hans Petter Selasky , monochrome , freebsd-current@freebsd.org Subject: Re: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X Message-ID: <20200920093814.GD94807@kib.kiev.ua> References: <69ff9432-fc8f-b0ab-8ad2-8e3daa77f8e1@twcny.rr.com> <1a88773b-d2fa-a790-c7e2-868d3884ba8b@twcny.rr.com> <865D6BF0-9F1E-4125-81D3-FB9A369FED8D@gwdg.de> <88af31d4-9ed9-172a-d48f-1780f19841e3@twcny.rr.com> <11d27d41-029a-d7f5-eccc-0ba3a3fcfe97@gwdg.de> <2bbfb4b3-92e9-b3ca-9c31-6c513cee2f2d@gwdg.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2bbfb4b3-92e9-b3ca-9c31-6c513cee2f2d@gwdg.de> 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: 4BvMvM0DR7z4KFR X-Spamd-Bar: / X-Spamd-Result: default: False [-0.91 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none]; NEURAL_HAM_MEDIUM(-0.74)[-0.736]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_HAM_LONG(-0.21)[-0.212]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.03)[0.034]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MIME_TRACE(0.00)[0:+]; MAILMAN_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 20 Sep 2020 09:38:24 -0000 On Sun, Sep 20, 2020 at 10:26:11AM +0200, Rainer Hurling wrote: > Am 20.09.20 um 10:20 schrieb Hans Petter Selasky: > > On 2020-09-20 10:05, Rainer Hurling wrote: > >> Hi monochrome, > >> > >> back to keyboard, it tried newest CURRENT (r365920) on my box and even > >> with newest sources the error occurs. > >> > >> After looking around somewhat more, I found some hints about Virtualbox > >> kernel module having problems with r365488. Unfortunately, I am not able > >> to find the thread again :( > >> > >> What seems to help as a workaround is to disable the loading of > >> VirtualBox in /boot/loader.conf > >> > >> #vboxdrv_load="YES" > >> > >> and in /etc/rc.conf > >> > >> #vboxnet_enable="YES" > >> #vboxguest_enable="YES" > >> > >> > >> So probably, this page fault is not restricted to AMD Ryzen? > >> > > > > Possibly you need to rebuild that kernel module. Maybe the FreeBSD > > version was not bumped correctly. > > > > --HPS > > > > Thanks for the hint. But I did rebuild all kernel modules before > rebooting, in my case vbox*.ko, nvidia*.ko. Provide backtrace of the panic. From owner-freebsd-current@freebsd.org Sun Sep 20 12:53:03 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 CD4303E0116 for ; Sun, 20 Sep 2020 12:53:03 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from dec.sakura.ne.jp (dec.sakura.ne.jp [210.188.226.8]) (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 4BvSCy2lcVz4VLM for ; Sun, 20 Sep 2020 12:53:01 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from kalamity.joker.local (115-38-187-204.shizuoka1.commufa.jp [115.38.187.204]) (authenticated bits=0) by dec.sakura.ne.jp (8.15.2/8.15.2/[SAKURA-WEB]/20080708) with ESMTPA id 08KCqoY6042262; Sun, 20 Sep 2020 21:52:50 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Sun, 20 Sep 2020 21:52:50 +0900 From: Tomoaki AOKI To: freebsd-current@freebsd.org Cc: imp@bsdimp.com Subject: Re: Plans for git Message-Id: <20200920215250.7afe8c073e5a1a5b2a6d6aa4@dec.sakura.ne.jp> In-Reply-To: References: <20200902164706.GA49777@troutmask.apl.washington.edu> <5c89b4d27281f5dfffc3252a90013b0ac6c763d7.camel@freebsd.org> <5c832482-b2bc-47e4-8762-8f5a886d5f11@www.fastmail.com> <68585ca4-5ca4-40d3-b2f4-67ff3b35b6ae@www.fastmail.com> <0be2ae57d1c58e2091f4cc4484731df0@bsdforge.com> <967D73EA-880E-413D-B748-62A406C46524@FreeBSD.org> <9f89dc553e7d7b0884c2862329bdfeae@bsdforge.com> Reply-To: junchoon@dec.sakura.ne.jp Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4BvSCy2lcVz4VLM X-Spamd-Bar: / X-Spamd-Result: default: False [0.71 / 15.00]; HAS_REPLYTO(0.00)[junchoon@dec.sakura.ne.jp]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-0.50)[-0.504]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; REPLYTO_ADDR_EQ_FROM(0.00)[]; TO_DN_NONE(0.00)[]; AUTH_NA(1.00)[]; DMARC_NA(0.00)[sakura.ne.jp]; HAS_ORG_HEADER(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.53)[-0.534]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.35)[0.353]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:9370, ipnet:210.188.224.0/19, country:JP]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 20 Sep 2020 12:53:03 -0000 Hi! Thanks for clarification, Warner. Focusing on downsides, I feel the second is fundamental. Running (incremental) count is important especially for non-developers like me (or developers not having commit bit) to report problems via ML. It clarifies revision ranges in shorter and clearer form. And if specfying it to use back and forth revisions is possible, like `svnlite -r (any revision No.)`, bisecting should be much easier than using git hash, which is not incremental. For the third, merging acceptably-licensed tool, such as got, into base seems reasonable to me. IIUC, got uses git-compatible repository. So anyone who hesitates incompatible command line can use devel/git or anything else from ports. Regards. On Sat, 19 Sep 2020 09:57:38 -0600 Warner Losh wrote: > I've taken the time to clean up this email (which I wrote on my phone last > thing yesterday) and expand it a little. > > https://bsdimp.blogspot.com/2020/09/freebsd-subversion-to-git-migration.html > > is the result. I'm planning on doing a number of videos about this, as well > as blog posts, FreeBSD Journal articles and handbook updates. > > Hopefully that will help explain why we're headed that way, as well as > provide resources for what to do after the cut-over, what users can expect, > etc. > > Warner > > On Sat, Sep 19, 2020 at 12:21 AM Warner Losh wrote: > > > > > > > On Fri, Sep 18, 2020, 11:31 PM Zaphod Beeblebrox > > wrote: > > > >> Hrm. Maybe what I hear others saying, tho, and not entirely being > >> replied to is just a nice concise document of the why. What I hear you > >> saying is that GIT has momentum and that it's popular... (and I accept that > >> --- it is evidently true), but then I hear handwaving about features, but > >> no list of features that are a clear win/loose. > >> > > > > Apache has switched to git from subversion. They are the current > > caretakers of subversion so it's future is very much in doubt. > > > > Git have more support for newer CI tools than subversion. This will allow > > us, once things are fully phased in, to increase the quality of the code > > going into the tree, as well as greatly reduce build breakages and > > accidental regressions. > > > > Gits merging facilities are much better than subversion. You can more > > easily curate patches as well since git supports a rebase workflow. This > > allows cleaner patches that are logical bits for larger submissions. > > Subversion can't do this. > > > > Git can easily and robustly be mirrored. Subversion can be mirrored, but > > that mirroring is far from robust. One of the snags in the git migration is > > that different svn mirrors have different data than the main repo or each > > other. Git can cryptographically sign tags and commits. Subversion cannot. > > > > Mirroring also opens up more 3rd party plug ins. Gitlab can do some > > things, Github others, in terms of automated testing and continuous > > integration. Tests can be run when branches are pushed. Both these > > platforms have significant collaboration tools as well, which will support > > groups going off and creating new features for FreeBSD. While one can use > > these things to a limited degree, with subversion mirrored to github, the > > full power of these tools isn't fully realized without a conversion to git. > > > > All of this is before the skillset arguments are made about kids today > > just knowing git, but needing to learn subversion and how that has had > > increasing been a source of friction. This argument is the closest one to > > being handwavy since I've not voted the data showing the growing proportion > > of projects using git (iirc, it's 85% or 90%). > > > > These are the main ones. The three down sides are lack of $FreeBSD$ > > support and tags in general. Git has a weaker count of commits than > > subversion. And the BSDL git clients are less mature than the GPL'd ones. > > > > Certainly the only clear things a quick search turns up that seem relevant > >> is that GIT is GPL2.0 and SVN is Apache2.0. This was enough for LLVM vs > >> GCC and the repository is a core function, but I suppose not a necessary > >> function for forked projects that can't abide, so... > >> > > > > OPENBSD has got, which is being ported in earnest. It has an agreeable > > license. > > > > Anyways... some concise record of thoughts might calm the gnawing > >> sensation in my gut... > >> > > > > Yes. I've started doing a series of short videos explaining the change, > > why we are doing it and what to do in the new world order. I'll be doing > > blog entries as well as turning that material into handbook entries. I have > > some of those written. > > > > Does this help? > > > > Warner > > > > On Thu, Sep 3, 2020 at 4:19 PM Warner Losh wrote: > >> > >>> On Thu, Sep 3, 2020 at 1:32 PM Chris wrote: > >>> > >>> > On 2020-09-03 11:33, Kristof Provost wrote: > >>> > > On 3 Sep 2020, at 19:56, Chris wrote: > >>> > >> Why was the intention to switch NOT announced as such MUCH sooner? > >>> > >> > >>> > > There was discussion about a possible switch to git on the > >>> freebsd-git > >>> > > mailing > >>> > > list as early as February 2017: > >>> > > > >>> > > >>> https://lists.freebsd.org/pipermail/freebsd-git/2017-February/000092.html > >>> > > > >>> > > Ed gave a talk about FreeBSD and git back in 2018: > >>> > > https://www.youtube.com/watch?v=G8wQ88d85s4 > >>> > > > >>> > > The Git Transition Working group was mentioned in the quarterly > >>> status > >>> > > reports a > >>> > > year ago: > >>> > https://www.freebsd.org/news/status/report-2019-07-2019-09.html > >>> > > and > >>> > > https://www.freebsd.org/news/status/report-2019-04-2019-06.html > >>> > It appears to me that the references you make here all allude to > >>> > _investigation_ > >>> > of a _possibility_ as opposed to a _likelihood_, or an _inevitable_. > >>> > IMHO a change as significant as this, which will require tossing years > >>> of > >>> > tooling > >>> > out the window, and an untold amount of _re_tooling. Should have > >>> created an > >>> > announcement at _least_ as significant as a new release gets on the > >>> mailing > >>> > lists. > >>> > > >>> > >>> Yes. We've been working on this for years. We've been working on the > >>> retooling in earnest for the last 6 months. We didn't make an > >>> announcement > >>> because we wanted to have most of the pieces in place before we did that. > >>> We've been doing the multi-year process for multiple years now. I'll also > >>> point out that only the 'git' people showed. A number of other ideas were > >>> suggested, but nothing else was stood up in a serious way (hg came the > >>> closest to setting up an exporter). Since there was really no > >>> alternatives > >>> being proposed to git, the process was less visible than if we'd had to > >>> have had a hg vs git bake off. One step has lead to the next, with much > >>> status reporting done for years. > >>> > >>> Subversion, btw, is not viable in the long run. The Apache foundation has > >>> moved all its projects from svn to git. The velocity of features with svn > >>> has diminished, and the number of CI/CT/etc tool sets that supported svn > >>> well has been dropping over time. It's also been identified as a barrier > >>> to > >>> entry for the project. Sure, some people climb the learning curve to > >>> learn > >>> and understand it, but our survey data has shown that for every one that > >>> did take the time, many others did not and simply didn't contribute. > >>> > >>> All of these issues have been discussed at length at conferences for the > >>> last 5 years at least, with increasing levels of sophistication. Had > >>> there > >>> been a BSDcan this year, I'd hoped to do a talk / BOF on this to help > >>> socialize the ideas and to get people's feedback in real time (rather > >>> than > >>> the slow and difficult process of getting it just in email). > >>> > >>> We've also talked about this in the BSD office hours and core election > >>> forums over the past year. > >>> > >>> We've been rolling out the beta git repo now for 3 months. People have > >>> found issues and we've been correcting them. We've heard from people that > >>> their automated tooling needs a bit of transition time, so we'll be > >>> exporting the stable/11 and stable/12 branches back into subversion (and > >>> the release branches) after the conversion for the life of those > >>> branches, though we don't plan on doing it for the current nor stable/13 > >>> branches (due to the inefficiencies of git-svn, we need separate trees > >>> for > >>> each, and each tree takes over a day to setup). We know we need some > >>> better > >>> docs (we have some decent preliminary ones, but there's some missing bits > >>> in them, and they are too long for more casual users). We need to spell > >>> out > >>> different commit policies, how we're going to have to shift our "MFC" > >>> terminology because that's very CVS/SVN centric (in git a merge means a > >>> more specific thing than it does in svn. A cherry-pick in git is also > >>> called a merge in svn, for example). We need to document to the > >>> developers > >>> how to make the shift (this doc is mostly complete and was posted > >>> earlier, > >>> though it could use some TLC). We'd hoped to have the documents done, the > >>> policies written and vetted and have a good test system before making an > >>> announcement. The last thing I wanted was to make a big announcement, > >>> only > >>> to fail to deliver. And since each step of the process followed > >>> naturally, > >>> there wasn't a clear A/B decision point where an announcement could have > >>> been generated. We were getting close to publishing the final schedule > >>> when > >>> this thread popped up, though, since it is finally feeling like it will > >>> be > >>> real soon. I also had hoped to refine things so that existing developers > >>> and users would have only minor disruption at the cut over because things > >>> were well documented. > >>> > >>> And once we have all the basics of phase 1 (which is just going to be 'do > >>> FreeBSD's current workflow in git, making minimal changes initially), > >>> we'll > >>> start on the refinements to the workflow that will help improve the > >>> quality > >>> of code, make it easier to integrate changes, etc. There's quite the > >>> diversity of views and opinions in the larger open source world on what > >>> best practices are here, with different projects doing different things. > >>> It > >>> will take some time for the project to adopt these new tools, new work > >>> flows and realize that in some cases a diversity of tools can be an > >>> advantage rather than a liability. This may be especially true as the > >>> needs > >>> of the ports tree differ from the needs of the src tree and what's > >>> optimal > >>> for one may not work too well for the other. > >>> > >>> So a lot of my reaction in the past few days has been frustration that > >>> this > >>> came up about a week before we had all our ducks in a row to talk about > >>> it > >>> effectively and talk about the transition plans. I apologize for being so > >>> snarky about it. > >>> > >>> Warner > >>> _______________________________________________ > >>> 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" > >>> > >> > _______________________________________________ > 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" -- Tomoaki AOKI From owner-freebsd-current@freebsd.org Sun Sep 20 12:58: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 5B3B53DFFEF for ; Sun, 20 Sep 2020 12:58:19 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from dec.sakura.ne.jp (dec.sakura.ne.jp [210.188.226.8]) (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 4BvSL22Hysz4Vmj for ; Sun, 20 Sep 2020 12:58:17 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from kalamity.joker.local (115-38-187-204.shizuoka1.commufa.jp [115.38.187.204]) (authenticated bits=0) by dec.sakura.ne.jp (8.15.2/8.15.2/[SAKURA-WEB]/20080708) with ESMTPA id 08KCwBGN042351; Sun, 20 Sep 2020 21:58:11 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Sun, 20 Sep 2020 21:58:11 +0900 From: Tomoaki AOKI To: freebsd-current@freebsd.org Subject: Re: Deprecating ftpd in the FreeBSD base system? Message-Id: <20200920215811.090fb1979fbbef60904f3d35@dec.sakura.ne.jp> In-Reply-To: <202009171555.08HFtQlB010471@slippy.cwsent.com> References: <451538DE-9427-4584-987B-8E4AA26C2981@freebsd.org> <202009171555.08HFtQlB010471@slippy.cwsent.com> Reply-To: junchoon@dec.sakura.ne.jp Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.1) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4BvSL22Hysz4Vmj X-Spamd-Bar: ++ X-Spamd-Result: default: False [2.14 / 15.00]; HAS_REPLYTO(0.00)[junchoon@dec.sakura.ne.jp]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; HAS_ORG_HEADER(0.00)[]; NEURAL_HAM_SHORT(-0.55)[-0.546]; RCPT_COUNT_TWO(0.00)[2]; RECEIVED_SPAMHAUS_PBL(0.00)[115.38.187.204:received]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; FROM_EQ_ENVFROM(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:9370, ipnet:210.188.224.0/19, country:JP]; R_DKIM_NA(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.60)[-0.601]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sakura.ne.jp]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.88)[0.885]; RCVD_TLS_LAST(0.00)[]; R_SPF_NA(0.00)[no SPF record]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 20 Sep 2020 12:58:19 -0000 On Thu, 17 Sep 2020 08:55:26 -0700 Cy Schubert wrote: > In message <451538DE-9427-4584-987B-8E4AA26C2981@freebsd.org>, Daniel > Eischen w > rites: > > > > > > > On Sep 17, 2020, at 11:20 AM, Maxim Sobolev wrote: > > > > > > $B".".".(BRe: removing HTTP client please no!!! The current drive to "outlaw" HTTP > > > coming from companies who see all world via web browser. Totally ignoring > > > the fact that HTTP != HTTPS in particular in cases where reliability and > > > lower complexity of the system takes precedence over on-the-wire protocol > > > security. For example, many internal APIs of AWS EC2 are HTTP. > > > > Agree. And remember the mantra: tools, not policy. > > Since there are so many I'll pick this email to reply to. > > libfetch should be designed to call plugins. An https plugin, http plugin, > ftp plugin, sftp plugin, and so on. New protocols are added as needed, > preferably to ports before they are mainstream. Old protocols are removed > and moved to ports. People who still need to use old protocols can install > the port which plugs into libfetch. When a protocol becomes stale it's > forgotten, no longer maintained and simply disappears into the ether. Looks reasonable for me, if all plugin to fetch base distribution and pkgbase is guaranteed to be incorporated in base and install images. No objection about removing ftpd and ftp client from base, if drop-in (at least having enough compatibility with configuration files/envs) alternatives are in ports. Regards. > Given that pkgbase will become a reality at some point the line between > base and ports will blur. I expect at some point some of what we see in > base to simply become ports. As a developer of both base and ports, ports > are much easier to maintain than importing into base. > > That's my vision. > > > -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: https://FreeBSD.org > NTP: Web: https://nwtime.org > > The need of the many outweighs the greed of the few. > > > _______________________________________________ > 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" > -- Tomoaki AOKI From owner-freebsd-current@freebsd.org Sun Sep 20 13:06:55 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 E619B3E071F for ; Sun, 20 Sep 2020 13:06:55 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from dec.sakura.ne.jp (dec.sakura.ne.jp [210.188.226.8]) (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 4BvSWz16Qjz4WY0 for ; Sun, 20 Sep 2020 13:06:54 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from kalamity.joker.local (115-38-187-204.shizuoka1.commufa.jp [115.38.187.204]) (authenticated bits=0) by dec.sakura.ne.jp (8.15.2/8.15.2/[SAKURA-WEB]/20080708) with ESMTPA id 08KD6qCU042470 for ; Sun, 20 Sep 2020 22:06:52 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Sun, 20 Sep 2020 22:06:52 +0900 From: Tomoaki AOKI To: freebsd-current@freebsd.org Subject: Re: Fatal trap 18 on boot after OpenZFS import Message-Id: <20200920220652.34aa1ea0031c337e1790473b@dec.sakura.ne.jp> In-Reply-To: <20200906180240.e61a2869b1258f96c3e7d398@dec.sakura.ne.jp> References: <20200904220301.7fac6b4008f1bc7ad8d803c9@dec.sakura.ne.jp> <20200906180240.e61a2869b1258f96c3e7d398@dec.sakura.ne.jp> Reply-To: junchoon@dec.sakura.ne.jp Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4BvSWz16Qjz4WY0 X-Spamd-Bar: ++ X-Spamd-Result: default: False [2.32 / 15.00]; HAS_REPLYTO(0.00)[junchoon@dec.sakura.ne.jp]; RCVD_VIA_SMTP_AUTH(0.00)[]; MV_CASE(0.50)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; TO_DN_NONE(0.00)[]; HAS_ORG_HEADER(0.00)[]; NEURAL_HAM_SHORT(-0.56)[-0.561]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:9370, ipnet:210.188.224.0/19, country:JP]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[115.38.187.204:received]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.49)[0.486]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[sakura.ne.jp]; NEURAL_SPAM_LONG(0.99)[0.991]; MIME_TRACE(0.00)[0:+]; R_SPF_NA(0.00)[no SPF record]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 20 Sep 2020 13:06:56 -0000 Forgot to mention here. As I already mentioned on bugzilla, this problem is fixed at r365894. Thanks again, Ryan and Matthew! On Sun, 6 Sep 2020 18:02:40 +0900 Tomoaki AOKI wrote: > Filed PR. > Bug 249147 - [ZFS][Panic]Fatal trap 18 on boot after OpenZFS import > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=249147 > > > On Fri, 4 Sep 2020 22:03:01 +0900 > Tomoaki AOKI wrote: > > > Hi. > > > > Encountering boot failure with fatal trap 18 on boot, > > happening at (maybe) just before init() starts. Possibly on > > root remount by kernel or zpool import by rc.d script. > > The last revision tried is r365316 (r364788 is the last tried > > clean rebuild). > > > > The last health revision is r364744, just before actual switch > > to OpenZFS. amd64 on ThinkPad P52 (Core i7-8750H) w/descrete nvidia GPU. > > > > r364751 with diff of r364777 and r364788 (to successfully built > > Without unrelated-to-OpenZFS changes) fails. > > > > Any suggestions and fixes are appreciated. > > > > > > Trap screen is something like below (text attached), > > typed up from relatively clear photo, so could be some typo. > > > > This is shown just after usual kernel startup outputs. > > boot1.efi (as EFI/bootx64.efi on ESP) starts /boot/loader.efi > > properly, and loader.efi seems to boot kernel properly. > > > > As even single user shell selection doesn't appear, loader.efi > > is of r364744. But they works even if I proceeded irregular > > process, > > > > 1)Update src tree > > 2)Clean obj tree > > 3)buildworld > > 4)etcupdate -p > > 5)buildkernel > > 6)installkernel > > 7)shutdown to single user WITHOUT reboot <- Irregular! > > 8)installworld > > 9)etcupdate > > 10)rebuild src/sys-dependent ports (kmods, nvidia-driver, ...) > > 11)reboot > > > > loader.efi looks doing its job and panics after kernel startup ends. > > Needless to say, rolling back to r364744 state from stable/12 on nvd0 > > Fixes the issue. > > > > Regards. > > > > ===== > > > > Fatal trap 18: integer divide fault while in kernel mode > > cpuid = 2; apic id = 02 > > instruction pointer = 0x20:0xffffffff82bfa320 > > stack pointer = 0x28:0xfffffe00e20c6900 > > frame pointer = 0x28:0xfffffe00e20c6960 > > code segment = base 0x0, limit 0xfffff, type 0x1b > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > processor eflags = interrupt enabled, resume, IOPL = 0 > > current process = 27 (vdev_open) > > trap number = 18 > > panic: integer divide fault > > cpuid = 2 > > time = 16 > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > > 0xfffffe00e20c6610 vpanic() at vpanic+0x182/frame fffffe00e20c6660 > > panic() at panic+0x43/frame fffffe00e20c66c0 > > trap_fatal() at trap_fatal+0x387/frame fffffe00e20c6720 > > trap() at trap+0x8e/frame fffffe00e20c6830 > > calltrap() at calltrap+0x8/frame fffffe00e20c6830 > > --- trap 0x12, rip = 0xffffffff82bfa320, rsp = 0xfffffe00e20c6900, rbp > > = 0xfffffe00e20c6960 --- zio_wait() at zio_wait+0x60/frame > > 0xfffffe00e20c6960 vdev_open() at vdev_open+0x74d/frame > > 0xfffffe00e20c69c0 vdev_open_child() at vdev_open_child+0x1e/frame > > 0xfffffe00e20c69e0 taskq_run() at taskq_run+0x1f/frame > > 0xfffffe00e20c6a00 taskqueue_run_locked() at > > taskqueue_run_locked+0x181/frame 0xfffffe00e20c6a80 > > taskqueue_thread_loop() at taskqueue_thread_loop+0x118/frame > > 0xfffffe00e20c6ab0 fork_exit() at fork_exit+0x7d/frame > > 0xfffffe00e20c6af0 fork_trampoline() at fork_trampoline+0xe/frame > > 0xfffffe00e20c6af0 > > --- trap 0, rip = 0, rsp = 0, rbp = 0 --- > > KDB: enter: panic > > [ thread pid 27 tid 100570 ] > > Stopped at kdb_enter+0x37: movq $0,0x1091556(%rip) > > db> > > > > ===== > > > > Additional info: > > *Clean build with killing CPUTYPE from command line and > > make.conf (so should be equivalent with nocona) didn't help. > > > > *Clean build with commenting out WITH_KERNEL_RETPOLINE line > > and WITH_RETPOLINE line in src.conf didn't help. > > > > *Combination of the above two didn't help, too (at r364788). > > > > *There are two root pools in different physical drive. > > stable/12 on nvd0 (primary) and head on ada0 (secondary). > > > > *GENERIC-NODEBUG based (added options CAM_IOSCHED_DYNAMIC) > > kernel. > > > > -- > > Tomoaki AOKI > > > -- > Tomoaki AOKI > _______________________________________________ > 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" -- Tomoaki AOKI From owner-freebsd-current@freebsd.org Sun Sep 20 13:11: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 A75C63E08EF for ; Sun, 20 Sep 2020 13:11:34 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from gmailer.gwdg.de (gmailer.gwdg.de [134.76.11.17]) (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 4BvSdK6sHfz4X9m for ; Sun, 20 Sep 2020 13:11:33 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from excmbx-03.um.gwdg.de ([134.76.9.218] helo=email.gwdg.de) by mailer.gwdg.de with esmtp (GWDG Mailer) (envelope-from ) id 1kJz7s-0000qs-1m; Sun, 20 Sep 2020 15:11:32 +0200 Received: from krabat.raven.hur (10.250.9.199) by EXCMBX-03.um.gwdg.de (134.76.9.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2044.4; Sun, 20 Sep 2020 15:11:31 +0200 Subject: Re: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X To: Konstantin Belousov CC: Hans Petter Selasky , monochrome , References: <69ff9432-fc8f-b0ab-8ad2-8e3daa77f8e1@twcny.rr.com> <1a88773b-d2fa-a790-c7e2-868d3884ba8b@twcny.rr.com> <865D6BF0-9F1E-4125-81D3-FB9A369FED8D@gwdg.de> <88af31d4-9ed9-172a-d48f-1780f19841e3@twcny.rr.com> <11d27d41-029a-d7f5-eccc-0ba3a3fcfe97@gwdg.de> <2bbfb4b3-92e9-b3ca-9c31-6c513cee2f2d@gwdg.de> <20200920093814.GD94807@kib.kiev.ua> Reply-To: From: Rainer Hurling Message-ID: <0249197f-29f6-4df4-eb63-ca786aaea39d@gwdg.de> Date: Sun, 20 Sep 2020 15:11:26 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <20200920093814.GD94807@kib.kiev.ua> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.250.9.199] X-ClientProxiedBy: EXCMBX-23.um.gwdg.de (134.76.9.233) To EXCMBX-03.um.gwdg.de (134.76.9.218) X-Virus-Scanned: (clean) by clamav X-Rspamd-Queue-Id: 4BvSdK6sHfz4X9m X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.93 / 15.00]; HAS_REPLYTO(0.00)[rhurlin@freebsd.org]; HAS_XOIP(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:134.76.10.0/23]; RCVD_COUNT_THREE(0.00)[3]; RCVD_IN_DNSWL_MED(-0.20)[134.76.11.17:from]; NEURAL_HAM_SHORT(-0.40)[-0.404]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:680, ipnet:134.76.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[rhurlin]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_MEDIUM(-1.02)[-1.020]; NEURAL_HAM_LONG(-1.00)[-1.003]; MIME_GOOD(-0.10)[text/plain]; REPLYTO_DOM_NEQ_FROM_DOM(0.00)[]; DMARC_NA(0.00)[gwdg.de]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RWL_MAILSPIKE_VERYGOOD(0.00)[134.76.11.17:from]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 20 Sep 2020 13:11:34 -0000 Am 20.09.20 um 11:38 schrieb Konstantin Belousov: > On Sun, Sep 20, 2020 at 10:26:11AM +0200, Rainer Hurling wrote: >> Am 20.09.20 um 10:20 schrieb Hans Petter Selasky: >>> On 2020-09-20 10:05, Rainer Hurling wrote: >>>> Hi monochrome, >>>> >>>> back to keyboard, it tried newest CURRENT (r365920) on my box and even >>>> with newest sources the error occurs. >>>> >>>> After looking around somewhat more, I found some hints about Virtualbox >>>> kernel module having problems with r365488. Unfortunately, I am not able >>>> to find the thread again :( >>>> >>>> What seems to help as a workaround is to disable the loading of >>>> VirtualBox in /boot/loader.conf >>>> >>>> #vboxdrv_load="YES" >>>> >>>> and in /etc/rc.conf >>>> >>>> #vboxnet_enable="YES" >>>> #vboxguest_enable="YES" >>>> >>>> >>>> So probably, this page fault is not restricted to AMD Ryzen? >>>> >>> >>> Possibly you need to rebuild that kernel module. Maybe the FreeBSD >>> version was not bumped correctly. >>> >>> --HPS >>> >> >> Thanks for the hint. But I did rebuild all kernel modules before >> rebooting, in my case vbox*.ko, nvidia*.ko. > > Provide backtrace of the panic. > Hi Konstantin, Thanks for your response. After trying several ways to produce a core dump or a working kdb prompt without success, all I can offer is the following screen contents. I built a GENERIC kernel with debugging enabled, enable loading of vboxdrv via /boot/loader.conf and /etc/rc.conf as described above: [..snip..] procfs registered modulte_register_init: MOD_LOAD (tmpfs, 0xffffffff80caa060, 0xffffffff82520a70) error 17 Timecounters tick every 1.000 msec lo0: bpf attached vlan: initialized, using hash tables with chaining Fatal trap 12: page fault while in kernel mode cpuid = 31; apic id = 1f fault virtual address = 0x0 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff80ea889b stack pointer = 0x20:0xffffffff826017e0 frame pointer = 0x20:0xffffffff826017e0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) trap number = 12 panic: page fault cpuid = 31 time = 1 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffffff82601490 vpanic() at vpanic+0x182/frame 0xffffffff826014e0 panic() at panic+0x43/frame 0xffffffff82601540 trap_fatal() at trap_fatal+0x387/frame 0xffffffff826015a0 trap_pfault() at trap_pfault+0x97/frame 0xffffffff82601600 calltrap() at calltrap+0x8/frame 0xffffffff82601710 --- trap 0xc, rip = 0xffffffff80ea889b, rsp = 0xffffffff826017e0, rbp = 0xffffffff826017e0 --- phys_pager_getpages() at phys_pager_getpages+0xb/frame 0xffffffff826017e0 vm_pager_get_pages() at vm_pager_get_pages+0x4f/frame 0xffffffff82601830 vm_fault() at vm_fault+0x5d6/frame 0xffffffff82601940 vm_map_wire_locked() at vm_map_wire_locked+0x3a6/framw 0xffffffff826019f0 vm_map_wire() at vm_map_wire+0x6b/frame 0xffffffff82601a20 rtR0MemObjFreeBSDAllocHelper() at rtR0MemObjFreeBSDAllocHelper+0xdc/frame 0xffffffff82601a70 rtR0MemObjNativeAllocCont() at rtR0MemObjNativeAllocCont+0x50/frame 0xffffffff82601ac0 supdrvGipCreate() at supdrvGipCreate+0x97/frame 0xffffffff82601b60 supdrvInitDevExt() at supdrvInitDevExt+0x19a/frame 0xffffffff82601bd0 VBoxDrvFreeBSDModuleEvent() at VBoxDrvFreeBSDModuleEvent+0x46/frame 0xffffffff82601bf0 module_register_init() at module_register_init+0xbd/frame 0xffffffff82601c20 mi_startup() at mi_startup+0xec/frame 0xffffffff82601c70 btext() at btext+0x2c KDB: enter: panic [ thread pid 0 tid 100000 ] Stopped at kdb_enter+0x37: movq $0,0x10b5796(%rip9 db> The system freezes at this point, no core dump is generated ;) This does not happen without loading VBoxDrv. At least, the screen dump shows VBoxDrvFreeBSDModuleEvent(). I hope, this is of some help. Best regards, Rainer From owner-freebsd-current@freebsd.org Sun Sep 20 14:00: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 BC1E33E2388 for ; Sun, 20 Sep 2020 14:00:44 +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 4BvTk31M28z4ZfF; Sun, 20 Sep 2020 14:00:42 +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 08KE0PUq028191; Sun, 20 Sep 2020 07:00:25 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 08KE0PBd028190; Sun, 20 Sep 2020 07:00:25 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202009201400.08KE0PBd028190@gndrsh.dnsmgr.net> Subject: Re: Plans for git In-Reply-To: To: Warner Losh Date: Sun, 20 Sep 2020 07:00:25 -0700 (PDT) CC: =?UTF-8?Q?Lucas_Nali_de_Magalh=C3=A3es?= , Chris , Kristof Provost , FreeBSD Current X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 4BvTk31M28z4ZfF X-Spamd-Bar: / X-Spamd-Result: default: False [0.11 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_MEDIUM(-0.56)[-0.562]; NEURAL_HAM_LONG(-0.12)[-0.120]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.10)[-0.103]; R_SPF_NA(0.00)[no SPF record]; 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]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[FreeBSD-current]; FREEMAIL_CC(0.00)[gmail.com,bsdforge.com,freebsd.org] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 20 Sep 2020 14:00:44 -0000 > On Sat, Sep 19, 2020, 2:44 PM Lucas Nali de Magalh?es > wrote: > > > Just My 2?? > > > > On Sep 3, 2020, at 5:19 PM, Warner Losh wrote: > > > > ?On Thu, Sep 3, 2020 at 1:32 PM Chris wrote: > > > > On 2020-09-03 11:33, Kristof Provost wrote: > > > > On 3 Sep 2020, at 19:56, Chris wrote: > > > > Why was the intention to switch NOT announced as such MUCH sooner? > > > > > > There was discussion about a possible switch to git on the freebsd-git > > > > mailing > > > > list as early as February 2017: > > > > > > https://lists.freebsd.org/pipermail/freebsd-git/2017-February/000092.html > > > > > > Ed gave a talk about FreeBSD and git back in 2018: > > > > https://www.youtube.com/watch?v=G8wQ88d85s4 > > > > > > The Git Transition Working group was mentioned in the quarterly status > > > > reports a > > > > year ago: > > > > https://www.freebsd.org/news/status/report-2019-07-2019-09.html > > > > and > > > > https://www.freebsd.org/news/status/report-2019-04-2019-06.html > > > > It appears to me that the references you make here all allude to > > > > _investigation_ > > > > of a _possibility_ as opposed to a _likelihood_, or an _inevitable_. > > > > IMHO a change as significant as this, which will require tossing years of > > > > tooling > > > > out the window, and an untold amount of _re_tooling. Should have created an > > > > announcement at _least_ as significant as a new release gets on the mailing > > > > lists. > > > > > > > > Yes. We've been working on this for years. We've been working on the > > retooling in earnest for the last 6 months. We didn't make an announcement > > because we wanted to have most of the pieces in place before we did that. > > We've been doing the multi-year process for multiple years now. I'll also > > point out that only the 'git' people showed. A number of other ideas were > > suggested, but nothing else was stood up in a serious way (hg came the > > closest to setting up an exporter). Since there was really no alternatives > > being proposed to git, the process was less visible than if we'd had to > > have had a hg vs git bake off. One step has lead to the next, with much > > status reporting done for years. > > > > Subversion, btw, is not viable in the long run. The Apache foundation has > > moved all its projects from svn to git. The velocity of features with svn > > has diminished, and the number of CI/CT/etc tool sets that supported svn > > well has been dropping over time. It's also been identified as a barrier to > > entry for the project. Sure, some people climb the learning curve to learn > > and understand it, but our survey data has shown that for every one that > > did take the time, many others did not and simply didn't contribute. > > > > All of these issues have been discussed at length at conferences for the > > last 5 years at least, with increasing levels of sophistication. Had there > > been a BSDcan this year, I'd hoped to do a talk / BOF on this to help > > socialize the ideas and to get people's feedback in real time (rather than > > the slow and difficult process of getting it just in email). > > > > We've also talked about this in the BSD office hours and core election > > forums over the past year. > > > > We've been rolling out the beta git repo now for 3 months. People have > > found issues and we've been correcting them. We've heard from people that > > their automated tooling needs a bit of transition time, so we'll be > > exporting the stable/11 and stable/12 branches back into subversion (and > > the release branches) after the conversion for the life of those > > branches, though we don't plan on doing it for the current nor stable/13 > > branches (due to the inefficiencies of git-svn, we need separate trees for > > each, and each tree takes over a day to setup). We know we need some better > > docs (we have some decent preliminary ones, but there's some missing bits > > in them, and they are too long for more casual users). We need to spell out > > different commit policies, how we're going to have to shift our "MFC" > > terminology because that's very CVS/SVN centric (in git a merge means a > > more specific thing than it does in svn. A cherry-pick in git is also > > called a merge in svn, for example). We need to document to the developers > > how to make the shift (this doc is mostly complete and was posted earlier, > > though it could use some TLC). We'd hoped to have the documents done, the > > policies written and vetted and have a good test system before making an > > announcement. The last thing I wanted was to make a big announcement, only > > to fail to deliver. And since each step of the process followed naturally, > > there wasn't a clear A/B decision point where an announcement could have > > been generated. We were getting close to publishing the final schedule when > > this thread popped up, though, since it is finally feeling like it will be > > real soon. I also had hoped to refine things so that existing developers > > and users would have only minor disruption at the cut over because things > > were well documented. > > > > And once we have all the basics of phase 1 (which is just going to be 'do > > FreeBSD's current workflow in git, making minimal changes initially), we'll > > start on the refinements to the workflow that will help improve the quality > > of code, make it easier to integrate changes, etc. There's quite the > > diversity of views and opinions in the larger open source world on what > > best practices are here, with different projects doing different things. It > > will take some time for the project to adopt these new tools, new work > > flows and realize that in some cases a diversity of tools can be an > > advantage rather than a liability. This may be especially true as the needs > > of the ports tree differ from the needs of the src tree and what's optimal > > for one may not work too well for the other. > > > > So a lot of my reaction in the past few days has been frustration that this > > came up about a week before we had all our ducks in a row to talk about it > > effectively and talk about the transition plans. I apologize for being so > > snarky about it. > > > > > > The thing that bugs me most is the fact that this all happened and was > > done without bringing public attention until recently. It wasn't the > > fragility of the argumentations nor the feeling that we are now following > > the group. Many of the initiatives that didn't went forward and have been > > removed I evaluated as a positive point in the project, even. I saw many > > projects and ideas die due to bad management and lack of action, not for > > the kind of argumentation presented. > > > > We've been talking about this at conferences for years. The proceedings of > which have been public. It's hard to get more public than that. We've been *sigh* The projects primary means of communications should NOT be considered conferecnes and publication of there proceeds, it is and always has been EMAIL. Step up, face the facts, it is obvious that the project has failed to effectively communicate this change to the public, specifically the non-committer consumer user base. > making quarterly reports about this for almost a years as well. We put out > calls for people to help with the efforts about the same time. We have > tried at every step of the way to be open and honest that this was going to > happen. All developer centric communications.... > Now, we haven't had as good a PR campaign as we could have had? Sure. But > we've made no efforts to keep this secret, nor conceal that it was > happening. Now that the lack of PR is clear, I've started making some > videos and blog posts to raise awareness and to educate. Great, thanks for stepping up for what is surely needed. > > Warner > > -- > > rollingbits ? > > rollingbits@yahoo.com > > > > > _______________________________________________ > 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" > > -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-current@freebsd.org Sun Sep 20 14:59: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 3460B3E460F; Sun, 20 Sep 2020 14:59:11 +0000 (UTC) (envelope-from markm@FreeBSD.org) Received: from gromit.grondar.org (gromit.grondar.org [IPv6:2a01:348:e::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) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BvW1V6GZrz4f7B; Sun, 20 Sep 2020 14:59:10 +0000 (UTC) (envelope-from markm@FreeBSD.org) Received: from [2a02:8011:300b:42:15a1:5d87:ad1a:446e] by gromit.grondar.org with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94 (FreeBSD)) (envelope-from ) id 1kK0ns-000GqH-PO; Sun, 20 Sep 2020 15:59:00 +0100 From: Mark Murray Content-Type: multipart/signed; boundary="Apple-Mail=_3DD0343E-9EDD-4E34-A1B0-1C13C7B42097"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Sun, 20 Sep 2020 15:58:59 +0100 Subject: objcopy "text file busy" build failure with populated /usr/obj Cc: freebsd-current To: freebsd-arm Message-Id: <1AFD8BB9-F598-451A-A1D9-16D550402E3E@FreeBSD.org> X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Rspamd-Queue-Id: 4BvW1V6GZrz4f7B X-Spamd-Bar: / X-Spamd-Result: default: False [0.00 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; ASN(0.00)[asn:39326, ipnet:2a01:348::/32, country:GB] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 20 Sep 2020 14:59:11 -0000 --Apple-Mail=_3DD0343E-9EDD-4E34-A1B0-1C13C7B42097 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi * I've been getting these build failures for a while (weeks/months). The = machine is a MacchiatoBin DoubleShot (arm64, Quad core). with SATA disks = and zfs filesystem. If I empty out /usr/obj, then the build works, but = takes a few hours. If I do a no-clean build with /obj/obj populated with = he contents of a previous build, and /usr/src with updated ("svn = update") sources, then the below nearly always happens early in the = rebuild. It is in "stage 4.4: building everything" that this happens. = The build is parallel (-j8), and I have manually de-threaded the output. The generated command-line from the logfile is: cd /usr/src; _PARALLEL_SUBDIR_OK=3D1 MACHINE_ARCH=3Daarch64 = MACHINE=3Darm64 CPUTYPE=3Dcortex-a72 CC=3D"/usr/local/bin/ccache cc = -target aarch64-unknown-freebsd13.0 = --sysroot=3D/usr/obj/usr/src/arm64.aarch64/tmp = -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin" CXX=3D"/usr/local/bin/ccache= c++ -target aarch64-unknown-freebsd13.0 = --sysroot=3D/usr/obj/usr/src/arm64.aarch64/tmp = -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin" CPP=3D"cpp -target = aarch64-unknown-freebsd13.0 --sysroot=3D/usr/obj/usr/src/arm64.aarch64/tmp= -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin" AS=3D"as" AR=3D"ar" = LD=3D"ld" LLVM_LINK=3D"" NM=3Dnm OBJCOPY=3D"objcopy" RANLIB=3Dranlib = STRINGS=3D SIZE=3D"size" STRIPBIN=3D"strip" INSTALL=3D"install -U" = PATH=3D/usr/obj/usr/src/arm64.aarch64/tmp/bin:/usr/obj/usr/src/arm64.aarch= 64/tmp/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin:/usr/obj/usr/sr= c/arm64.aarch64/tmp/legacy/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/leg= acy/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/bin:/usr/obj/usr/src= /arm64.aarch64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin = SYSROOT=3D/usr/obj/usr/src/arm64.aarch64/tmp make -f Makefile.inc1 = BWPHASE=3Deverything DESTDIR=3D/usr/obj/usr/src/arm64.aarch64/tmp all Anyone else seeing this? objcopy --strip-debug --add-gnu-debuglink=3Dobjcopy.debug objcopy.full = objcopy objcopy: open objcopy failed: Text file busy --- all_subdir_usr.bin/objcopy --- *** [objcopy] Error code 1 make[4]: stopped in /usr/src/usr.bin/objcopy M -- --Apple-Mail=_3DD0343E-9EDD-4E34-A1B0-1C13C7B42097 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 Comment: GPGTools - http://gpgtools.org iQEzBAEBCgAdFiEEyzPHvybPbOpU9MCxQlsJDh9CUqAFAl9nbjMACgkQQlsJDh9C UqBwAwf+OyKMBoTzCRAJkzadH2KolarOTCxMXp33bY046WrSkZ8gO9iC21e6527P Kmn/AwskG7G1W1DtoLp4HJpfhjaCysllDVQRUCj8lB3/bWpYyE9WjPLxCos44oTv fTV/KwfcDomEdWAsGvJCyell5aHFblhjaNud/jhVh//+em5rOi2/lfJqLj5ujiFX B+DAotfnQlHz38+MTxlH8X8rhHp+ZB+Di236xl482B53QEET+Y8s1EmiawUi93/l l1VhHQfdUW6P7YYfxRDtM8QvX8X1RmG3KM4DEmyzcnmehrfwtbGuU+bhIE7VFV15 gPsEspYLGBUoaWgL8xPSMNqL/4BkXQ== =PnDi -----END PGP SIGNATURE----- --Apple-Mail=_3DD0343E-9EDD-4E34-A1B0-1C13C7B42097-- From owner-freebsd-current@freebsd.org Sun Sep 20 15:05:14 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 D30963E4C0A for ; Sun, 20 Sep 2020 15:05:14 +0000 (UTC) (envelope-from news@mips.inka.de) Received: from mail.inka.de (mail.inka.de [IPv6:2a04:c9c7:0:1073:217:a4ff:fe3b:e77c]) (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) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BvW8T5BYcz4fNm for ; Sun, 20 Sep 2020 15:05:13 +0000 (UTC) (envelope-from news@mips.inka.de) Received: from mips.inka.de (news@[127.0.0.1]) by mail.inka.de with uucp (rmailwrap 0.5) id 1kK0tl-00DtVK-8P; Sun, 20 Sep 2020 17:05:05 +0200 Received: from lorvorc.mips.inka.de (localhost [127.0.0.1]) by lorvorc.mips.inka.de (8.16.1/8.16.1) with ESMTP id 08KF3Cwk062833 for ; Sun, 20 Sep 2020 17:03:12 +0200 (CEST) (envelope-from news@lorvorc.mips.inka.de) Received: (from news@localhost) by lorvorc.mips.inka.de (8.16.1/8.16.1/Submit) id 08KF3CfV062832 for freebsd-current@freebsd.org; Sun, 20 Sep 2020 17:03:12 +0200 (CEST) (envelope-from news) To: freebsd-current@freebsd.org From: Christian Weisgerber Newsgroups: list.freebsd.current Subject: Re: Plans for git Date: Sun, 20 Sep 2020 15:03:12 -0000 (UTC) Message-ID: References: <20200902045939.GA15897@eureka.lemis.com> <20200902060117.GG53210@home.opsec.eu> <20200902063136.GA47543@troutmask.apl.washington.edu> <20200902164706.GA49777@troutmask.apl.washington.edu> <5c89b4d27281f5dfffc3252a90013b0ac6c763d7.camel@freebsd.org> <5c832482-b2bc-47e4-8762-8f5a886d5f11@www.fastmail.com> <68585ca4-5ca4-40d3-b2f4-67ff3b35b6ae@www.fastmail.com> <0be2ae57d1c58e2091f4cc4484731df0@bsdforge.com> <967D73EA-880E-413D-B748-62A406C46524@FreeBSD.org> <9f89dc553e7d7b0884c2862329bdfeae@bsdforge.com> User-Agent: slrn/1.0.3 (FreeBSD) X-Rspamd-Queue-Id: 4BvW8T5BYcz4fNm X-Spamd-Bar: ++ X-Spamd-Result: default: False [2.08 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[news]; FROM_HAS_DN(0.00)[]; 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)[]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[inka.de]; NEURAL_SPAM_MEDIUM(0.22)[0.223]; NEURAL_SPAM_LONG(0.86)[0.858]; NEURAL_HAM_SHORT(-0.20)[-0.203]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[naddy@mips.inka.de,news@mips.inka.de]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:202113, ipnet:2a04:c9c7::/32, country:DE]; FROM_NEQ_ENVFROM(0.00)[naddy@mips.inka.de,news@mips.inka.de]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 20 Sep 2020 15:05:14 -0000 On 2020-09-19, Zaphod Beeblebrox wrote: > Hrm. Maybe what I hear others saying, tho, and not entirely being replied > to is just a nice concise document of the why. What I hear you saying is > that GIT has momentum and that it's popular... (and I accept that --- it is > evidently true), but then I hear handwaving about features, but no list of > features that are a clear win/loose. How about the very basics (that Warner appears to have lost sight of)? Git is a distributed version control system. You clone a repository and apart from pulling and pushing changes to another repository, all your work happens with the local repository. Subversion has a central repository and needs to talk to the server all the time. Laptop on a plane? No change of workflow with Git. And since it's your repository, you can cheaply create your own branches, where you can commit your work and have a versioned history of it instead of just a flat diff. I can't overstate the value of that. Whether you work on something that will be pushed back upstream or just your private changes, it has a full commit history. You can easily revert commits, you can upstream it one by one, you can upstream it with history. When FreeBSD switched from CVS to SVN, there was hope or promise of lightweight branches, but that never materialized. Developers still can't have private branches in the FreeBSD repository. For a while, a lot of development happened in a Perforce repository--a commerical version control system, whose company had donated a license--which offered this feature. Nowadays, everybody who does any but the most trivial development does so in a private Git repository anyway. It only makes sense to interface this directly with the FreeBSD repository instead of going through a SVN<>Git media break. > Certainly the only clear things a quick search turns up that seem relevant > is that GIT is GPL2.0 and SVN is Apache2.0. This was enough for LLVM vs > GCC and the repository is a core function, but I suppose not a necessary > function for forked projects that can't abide, so... There is a bit of historical precedent: The original BSD work at Berkeley was kept in a SCCS repository, a proprietary version control system at the time. And of course the fact that significant FreeBSD development has effectively happened in Perforce, then in Git for a long time and is just merged back into the Subversion repository. To put it bluntly, the people doing the work have voted with their feet years ago. -- Christian "naddy" Weisgerber naddy@mips.inka.de From owner-freebsd-current@freebsd.org Sun Sep 20 15:41:14 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 89E023E5BE7 for ; Sun, 20 Sep 2020 15:41:14 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from mail.nomadlogic.org (mail.nomadlogic.org [174.136.98.114]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.nomadlogic.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BvWy11kMVz3SMk; Sun, 20 Sep 2020 15:41:12 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from [192.168.1.159] (cpe-23-243-161-111.socal.res.rr.com [23.243.161.111]) by mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id d0a99214 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Sun, 20 Sep 2020 15:41:11 +0000 (UTC) Subject: Re: Plans for git To: "Rodney W. Grimes" , Warner Losh Cc: =?UTF-8?Q?Lucas_Nali_de_Magalh=c3=a3es?= , Chris , Kristof Provost , FreeBSD Current References: <202009201400.08KE0PBd028190@gndrsh.dnsmgr.net> From: Pete Wright Message-ID: <13a965d9-ef02-f876-dd6c-aa872b66d114@nomadlogic.org> Date: Sun, 20 Sep 2020 08:41:13 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <202009201400.08KE0PBd028190@gndrsh.dnsmgr.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Rspamd-Queue-Id: 4BvWy11kMVz3SMk X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.96 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-0.94)[-0.943]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[nomadlogic.org]; ARC_NA(0.00)[]; RCPT_COUNT_FIVE(0.00)[6]; RECEIVED_SPAMHAUS_PBL(0.00)[23.243.161.111:received]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.73)[-0.733]; NEURAL_HAM_MEDIUM(-0.98)[-0.982]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:25795, ipnet:174.136.96.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[FreeBSD-current]; FREEMAIL_CC(0.00)[gmail.com,bsdforge.com,freebsd.org] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 20 Sep 2020 15:41:14 -0000 >> making quarterly reports about this for almost a years as well. We put out >> calls for people to help with the efforts about the same time. We have >> tried at every step of the way to be open and honest that this was going to >> happen. > All developer centric communications.... I would argue that quarterly reports are actually one of the few methods of getting accurate information about the state of the project as a non-insider.  i've been following the progress of this work via the quarterly status reports for years now, and as someone who is merely a freebsd operator felt like i was more or less kept up to date on this eventuality. honestly there has to be *some* responsibility of operators to at least make an effort to keep up to date on the status of the various efforts in such a large project.  and as an outsider the idea that comms can only happen on the mailing list isn't the greatest - how am i to know that the idea of one person on the ML carries more weight than another, or one persons opinion is the "official" stated opinion of the core group? -pete -- Pete Wright pete@nomadlogic.org @nomadlogicLA From owner-freebsd-current@freebsd.org Sun Sep 20 17:16: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 1D4F63E849C for ; Sun, 20 Sep 2020 17:16:33 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BvZ405j6Tz3YG3 for ; Sun, 20 Sep 2020 17:16:32 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 08KHGTZp051450 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 20 Sep 2020 10:16:29 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 08KHGST2051449; Sun, 20 Sep 2020 10:16:28 -0700 (PDT) (envelope-from sgk) Date: Sun, 20 Sep 2020 10:16:28 -0700 From: Steve Kargl To: Pete Wright Cc: "Rodney W. Grimes" , Warner Losh , Lucas Nali de =?iso-8859-1?Q?Magalh=E3es?= , Chris , Kristof Provost , FreeBSD Current Subject: Re: Plans for git Message-ID: <20200920171628.GC50963@troutmask.apl.washington.edu> References: <202009201400.08KE0PBd028190@gndrsh.dnsmgr.net> <13a965d9-ef02-f876-dd6c-aa872b66d114@nomadlogic.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <13a965d9-ef02-f876-dd6c-aa872b66d114@nomadlogic.org> X-Rspamd-Queue-Id: 4BvZ405j6Tz3YG3 X-Spamd-Bar: - X-Spamd-Result: default: False [-1.99 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM,none]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_MEDIUM(-0.82)[-0.823]; NEURAL_HAM_LONG(-0.66)[-0.663]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.51)[-0.508]; RCPT_COUNT_SEVEN(0.00)[7]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; FREEMAIL_CC(0.00)[gndrsh.dnsmgr.net,bsdimp.com,gmail.com,bsdforge.com,freebsd.org]; MAILMAN_DEST(0.00)[FreeBSD-current]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 20 Sep 2020 17:16:33 -0000 On Sun, Sep 20, 2020 at 08:41:13AM -0700, Pete Wright wrote: > > > > making quarterly reports about this for almost a years as well. We put out > > > calls for people to help with the efforts about the same time. We have > > > tried at every step of the way to be open and honest that this was going to > > > happen. > > All developer centric communications.... > > I would argue that quarterly reports are actually one of the few methods of > getting accurate information about the state of the project as a > non-insider.  i've been following the progress of this work via the > quarterly status reports for years now, and as someone who is merely a > freebsd operator felt like i was more or less kept up to date on this > eventuality. > > honestly there has to be *some* responsibility of operators to at least make > an effort to keep up to date on the status of the various efforts in such a > large project.  and as an outsider the idea that comms can only happen on > the mailing list isn't the greatest - how am i to know that the idea of one > person on the ML carries more weight than another, or one persons opinion is > the "official" stated opinion of the core group? > Traditionally, this has been done through the freebsd-hackers and freebsd-current mailing lists. Admittedly, the freebsd-current mailing list has never recovered from the jenkins debacle. Making an announcement or seeking input about a conversion from subversion to git on the freebsd-git mailing list is self-fulfilling. People interested in git on FreeBSD will subscribe to that list. People not interested in git, oh well, they'll find out eventually. Of course, not seeking input on the mailing lists avoids the inevitable bikeshed. A discussion about a conversion from subversion to git would devolve rather quickly. -- Steve From owner-freebsd-current@freebsd.org Sun Sep 20 17:55: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 B6B383E8A72; Sun, 20 Sep 2020 17:55:17 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.protected-networks.net (mail.protected-networks.net [IPv6:2001:470:8d59:1::8]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.protected-networks.net", Issuer "Protected Networks CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BvZwg5SD3z3b86; Sun, 20 Sep 2020 17:55:15 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (Client did not present a certificate) (Authenticated sender: imb@mail.protected-networks.net) by mail.protected-networks.net (Postfix) with ESMTPSA id AF34D298C4; Sun, 20 Sep 2020 13:55:07 -0400 (EDT) Subject: Re: objcopy "text file busy" build failure with populated /usr/obj To: Mark Murray , freebsd-arm Cc: freebsd-current References: <1AFD8BB9-F598-451A-A1D9-16D550402E3E@FreeBSD.org> From: Michael Butler Message-ID: Date: Sun, 20 Sep 2020 13:55:07 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.3.0 MIME-Version: 1.0 In-Reply-To: <1AFD8BB9-F598-451A-A1D9-16D550402E3E@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-NZ Content-Transfer-Encoding: base64 X-Rspamd-Queue-Id: 4BvZwg5SD3z3b86 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.61 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[protected-networks.net:s=201508]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; NEURAL_HAM_LONG(-1.04)[-1.045]; NEURAL_HAM_MEDIUM(-1.03)[-1.033]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[protected-networks.net:+]; MIME_BASE64_TEXT(0.10)[]; DMARC_POLICY_ALLOW(-0.50)[protected-networks.net,reject]; NEURAL_HAM_SHORT(-0.64)[-0.636]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm,freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 20 Sep 2020 17:55:17 -0000 T24gOS8yMC8yMCAxMDo1OCBBTSwgTWFyayBNdXJyYXkgd3JvdGU6DQo+IEhpICoNCj4gDQo+ IEkndmUgYmVlbiBnZXR0aW5nIHRoZXNlIGJ1aWxkIGZhaWx1cmVzIGZvciBhIHdoaWxlICh3 ZWVrcy9tb250aHMpLiBUaGUgbWFjaGluZSBpcyBhIE1hY2NoaWF0b0JpbiBEb3VibGVTaG90 IChhcm02NCwgUXVhZCBjb3JlKS4gd2l0aCBTQVRBIGRpc2tzIGFuZCB6ZnMgZmlsZXN5c3Rl bS4gSWYgSSBlbXB0eSBvdXQgL3Vzci9vYmosIHRoZW4gdGhlIGJ1aWxkIHdvcmtzLCBidXQg dGFrZXMgYSBmZXcgaG91cnMuIElmIEkgZG8gYSBuby1jbGVhbiBidWlsZCB3aXRoIC9vYmov b2JqIHBvcHVsYXRlZCB3aXRoIGhlIGNvbnRlbnRzIG9mIGEgcHJldmlvdXMgYnVpbGQsIGFu ZCAvdXNyL3NyYyB3aXRoIHVwZGF0ZWQgKCJzdm4gdXBkYXRlIikgc291cmNlcywgdGhlbiB0 aGUgYmVsb3cgbmVhcmx5IGFsd2F5cyBoYXBwZW5zIGVhcmx5IGluIHRoZSByZWJ1aWxkLiBJ dCBpcyBpbiAic3RhZ2UgNC40OiBidWlsZGluZyBldmVyeXRoaW5nIiB0aGF0IHRoaXMgaGFw cGVucy4gVGhlIGJ1aWxkIGlzIHBhcmFsbGVsICgtajgpLCBhbmQgSSBoYXZlIG1hbnVhbGx5 IGRlLXRocmVhZGVkIHRoZSBvdXRwdXQuDQo+IA0KPiBUaGUgZ2VuZXJhdGVkIGNvbW1hbmQt bGluZSBmcm9tIHRoZSBsb2dmaWxlIGlzOg0KPiANCj4gY2QgL3Vzci9zcmM7IF9QQVJBTExF TF9TVUJESVJfT0s9MSBNQUNISU5FX0FSQ0g9YWFyY2g2NCAgTUFDSElORT1hcm02NCAgQ1BV VFlQRT1jb3J0ZXgtYTcyIENDPSIvdXNyL2xvY2FsL2Jpbi9jY2FjaGUgY2MgLXRhcmdldCBh YXJjaDY0LXVua25vd24tZnJlZWJzZDEzLjAgLS1zeXNyb290PS91c3Ivb2JqL3Vzci9zcmMv YXJtNjQuYWFyY2g2NC90bXAgLUIvdXNyL29iai91c3Ivc3JjL2FybTY0LmFhcmNoNjQvdG1w L3Vzci9iaW4iIENYWD0iL3Vzci9sb2NhbC9iaW4vY2NhY2hlIGMrKyAgLXRhcmdldCBhYXJj aDY0LXVua25vd24tZnJlZWJzZDEzLjAgLS1zeXNyb290PS91c3Ivb2JqL3Vzci9zcmMvYXJt NjQuYWFyY2g2NC90bXAgLUIvdXNyL29iai91c3Ivc3JjL2FybTY0LmFhcmNoNjQvdG1wL3Vz ci9iaW4iICBDUFA9ImNwcCAtdGFyZ2V0IGFhcmNoNjQtdW5rbm93bi1mcmVlYnNkMTMuMCAt LXN5c3Jvb3Q9L3Vzci9vYmovdXNyL3NyYy9hcm02NC5hYXJjaDY0L3RtcCAtQi91c3Ivb2Jq L3Vzci9zcmMvYXJtNjQuYWFyY2g2NC90bXAvdXNyL2JpbiIgIEFTPSJhcyIgQVI9ImFyIiBM RD0ibGQiIExMVk1fTElOSz0iIiAgTk09bm0gT0JKQ09QWT0ib2JqY29weSIgIFJBTkxJQj1y YW5saWIgU1RSSU5HUz0gIFNJWkU9InNpemUiIFNUUklQQklOPSJzdHJpcCIgIElOU1RBTEw9 Imluc3RhbGwgLVUiICBQQVRIPS91c3Ivb2JqL3Vzci9zcmMvYXJtNjQuYWFyY2g2NC90bXAv YmluOi91c3Ivb2JqL3Vzci9zcmMvYXJtNjQuYWFyY2g2NC90bXAvdXNyL3NiaW46L3Vzci9v YmovdXNyL3NyYy9hcm02NC5hYXJjaDY0L3RtcC91c3IvYmluOi91c3Ivb2JqL3Vzci9zcmMv YXJtNjQuYWFyY2g2NC90bXAvbGVnYWN5L3Vzci9zYmluOi91c3Ivb2JqL3Vzci9zcmMvYXJt NjQuYWFyY2g2NC90bXAvbGVnYWN5L3Vzci9iaW46L3Vzci9vYmovdXNyL3NyYy9hcm02NC5h YXJjaDY0L3RtcC9sZWdhY3kvYmluOi91c3Ivb2JqL3Vzci9zcmMvYXJtNjQuYWFyY2g2NC90 bXAvbGVnYWN5L3Vzci9saWJleGVjOjovc2JpbjovYmluOi91c3Ivc2JpbjovdXNyL2JpbiAg U1lTUk9PVD0vdXNyL29iai91c3Ivc3JjL2FybTY0LmFhcmNoNjQvdG1wIG1ha2UgIC1mIE1h a2VmaWxlLmluYzEgIEJXUEhBU0U9ZXZlcnl0aGluZyAgREVTVERJUj0vdXNyL29iai91c3Iv c3JjL2FybTY0LmFhcmNoNjQvdG1wIGFsbA0KPiANCj4gQW55b25lIGVsc2Ugc2VlaW5nIHRo aXM/DQo+IA0KPiBvYmpjb3B5IC0tc3RyaXAtZGVidWcgLS1hZGQtZ251LWRlYnVnbGluaz1v Ympjb3B5LmRlYnVnICBvYmpjb3B5LmZ1bGwgb2JqY29weQ0KPiBvYmpjb3B5OiBvcGVuIG9i amNvcHkgZmFpbGVkOiBUZXh0IGZpbGUgYnVzeQ0KPiAtLS0gYWxsX3N1YmRpcl91c3IuYmlu L29iamNvcHkgLS0tDQo+ICoqKiBbb2JqY29weV0gRXJyb3IgY29kZSAxDQo+IA0KPiBtYWtl WzRdOiBzdG9wcGVkIGluIC91c3Ivc3JjL3Vzci5iaW4vb2JqY29weQ0KDQpZZXMsIGFsdGhv dWdoIHNpbXBseSByZXN0YXJ0aW5nIHRoZSBidWlsZCBzZWVtcyB0byBhdm9pZCB0aGUgcHJv YmxlbSBvbiANCnRoZSBzZWNvbmQgYXR0ZW1wdC4NCg0KSG93ZXZlciwgSSdtIGJ1aWxkaW5n IG9uIGEgZHVhbCBxdWFkLWNvcmUgYW1kNjQgcGxhdGZvcm0gKDggY29yZXMgdG90YWwpIA0K c28gaXQncyBub3QganVzdCBBUk0gYmVpbmcgYWZmZWN0ZWQsDQoNCglpbWINCg0KDQo= From owner-freebsd-current@freebsd.org Sun Sep 20 17:55:56 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 E526D3E8EC1 for ; Sun, 20 Sep 2020 17:55:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qv1-xf30.google.com (mail-qv1-xf30.google.com [IPv6:2607:f8b0:4864:20::f30]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4BvZxS1fhDz3ZqW for ; Sun, 20 Sep 2020 17:55:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qv1-xf30.google.com with SMTP id f11so6169688qvw.3 for ; Sun, 20 Sep 2020 10:55:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2P1lxD/hEHg13QgmMpZ6o2J3EyCLVHsIcjEgsLRQ3OY=; b=SXOHhRLfVvfuFyFkmo8xwnkeM68GsX0+NgmQlbRmq+Aw2Lzui79dbpJAxl9EI7foqy 2bSmIRslSDTZza+P3Ho3jSFoQhp0X4HaDX+fZRWgAmt+tXk4ycyp9BQ5KxhgXNG/dWQk n1s2bU2v4DzxCNE3QQGmCgliQkzQSOpblU7xoYZMb8MYjAZyj2WQUSdEyhba2+QmgISC GZI6uciHHhuVGjXcBsCuTwTkmDNpTzgGSlLfzl9e1KBmpuNO1rS8cSFUFWBe5ryJK3bZ Sub/34hZzjl0345cO3BpioaUotQnAeaWC/7yPTQwvgEpWd6ve7vs/uvyQJagCl2pXILu QNHw== X-Gm-Message-State: AOAM533SW7D5DSoXvbBrT0s6J180XFwB/+CNKrebBkBMS1GGgwa5O0Sy AvG2+8Z/8N6j6thOrMg20+N9xtd3sHUz66H235V8hT8Qr91+bFP6 X-Google-Smtp-Source: ABdhPJxqtJrm3AV9UEPZGmQaDPksApRYBSDmY2kS8M30uL/G+Dg3J2XQTWK9Ro4I8hXyFP0UKOUGD/b8A+EnIhqgfRA= X-Received: by 2002:ad4:4a6b:: with SMTP id cn11mr27573572qvb.53.1600624555058; Sun, 20 Sep 2020 10:55:55 -0700 (PDT) MIME-Version: 1.0 References: <202009201400.08KE0PBd028190@gndrsh.dnsmgr.net> <13a965d9-ef02-f876-dd6c-aa872b66d114@nomadlogic.org> In-Reply-To: <13a965d9-ef02-f876-dd6c-aa872b66d114@nomadlogic.org> From: Warner Losh Date: Sun, 20 Sep 2020 11:55:44 -0600 Message-ID: Subject: Re: Plans for git To: Pete Wright Cc: FreeBSD Current X-Rspamd-Queue-Id: 4BvZxS1fhDz3ZqW X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.97 / 15.00]; ARC_NA(0.00)[]; MAILMAN_DEST(0.00)[FreeBSD-current]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.05)[-1.050]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f30:from]; NEURAL_HAM_SHORT(-0.93)[-0.925]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 20 Sep 2020 17:55:57 -0000 On Sun, Sep 20, 2020 at 9:41 AM Pete Wright wrote: > > >> making quarterly reports about this for almost a years as well. We put > out > >> calls for people to help with the efforts about the same time. We have > >> tried at every step of the way to be open and honest that this was > going to > >> happen. > > All developer centric communications.... > > I would argue that quarterly reports are actually one of the few methods > of getting accurate information about the state of the project as a > non-insider. i've been following the progress of this work via the > quarterly status reports for years now, and as someone who is merely a > freebsd operator felt like i was more or less kept up to date on this > eventuality. > Plus the git list also gave status updates and it was public and mentioned in the reports. > honestly there has to be *some* responsibility of operators to at least > make an effort to keep up to date on the status of the various efforts > in such a large project. and as an outsider the idea that comms can > only happen on the mailing list isn't the greatest - how am i to know > that the idea of one person on the ML carries more weight than another, > or one persons opinion is the "official" stated opinion of the core group? > And to be honest, we'd planned on a final PR push once we had a confirmed date with enough lead time for people to adjust. Be all that as it may, I've finished up the first of a series of videos. This one talks about the fundamental differences between the two in 4 minutes. Future videos will delve into details of how it affects different segments of our community: users, developers, integrators, etc. https://youtu.be/Lx9lKr_M-DI if you want to take a look. The next one will be one on why (though it largely rehashes this thread and the blog post I made, again in about 4 minutes). Warner From owner-freebsd-current@freebsd.org Sun Sep 20 18:25: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 14C6F3E9E66 for ; Sun, 20 Sep 2020 18:25:05 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Bvbb33JDBz3cq4 for ; Sun, 20 Sep 2020 18:25:03 +0000 (UTC) (envelope-from ohartmann@walstatt.org) X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from hermann.fritz.box ([77.183.147.118]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MMGN2-1k0sRO3M06-00JIkU for ; Sun, 20 Sep 2020 20:25:00 +0200 Date: Sun, 20 Sep 2020 20:24:53 +0200 From: "Hartmann, O." To: FreeBSD CURRENT Subject: bin/cp/utils.c:517:14: error: member reference base type 'void' is not a structure or union (RESCUE) Message-ID: <20200920202453.25556711@hermann.fritz.box> Organization: walstatt.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/wSZ51QYMKDCj_RRrvRY9QXQ"; protocol="application/pgp-signature" X-Provags-ID: V03:K1:8a+boeL7uPXhfLhx7qIpANQPzGZX5ajxo1wOSt9YULc+9+LU+s/ 8erTBPQNMv5B7KqluA9byASKneTGid8K7q/Irb4Q/nBrm+CXNmL+TkTdjzSU0/M3vMlsV9S JV+RvtjBwHvWl/91aj43WYts3WrkzugOPZf1E5ZlUrHUl7VySrfvEkZ/7ZYJMoJTFFohkv0 bFV7ZRzHCbbMD1dRExr8w== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:O0n4pVh8QU4=:cpgxXq08v8iCNG98MSL1sT /Ha/A9JpHXAl846W7+SG8/JenLzfN/mdl9XVoKP7W8lCcgbhmkAMkfaqaCD/0geXvfV7bQKmq eMFgKv/qA0q46KS9vdPbpLKTUw+joffvS7v7PwLz/gooG83SipWMtcoOZTMFx9bUmqusAls5a kRoJHTMjp1FesSRjUr0XkaXmDqHwmKrzwQ3oNTgn7QEHliLJDMdpsoZjTEW49o28+VOB9H3kb fORHm950sdNmCDzB79Y9ejB/qucrqu3Ww6o+i0PT0/sOjandksEVnV0LKLE2GCYSgkWSvx4pn imwRRvXsnKwOml16Pr33m3rXjvudyj2wQQU492V67bIrQl9jDnGfOcyClT3y7ByH3vQlORNbC PYKxv3NDdsNmlIQ24VQgjfmb9z1XyHvT53kInD5Sx+kol6DIDy5W02pyYroa0i9ATrnkxJ6+k z8d7qt0z+lFAlBw8cFwcTQAx8gqNMu1GKcLqnXgtPggnEJXgErWyTL2QZWcpmrCjm9DhfmM+v uYHoX/PeF39GIgI5hw0BWlpA3fZPvXvqkeB6yg1pMf/v1cgsjcvol+ZLxZizpKvyU+X1CJTXB pCrkjwCPkwgTgnrzGjAGGWKsITnoTOBZxQVq/50z6wFtqFYhQvKrotq5KWpGEsrf0BBbawRyH 0hzWUI+KTa2vJOdA8aN8D+Ow/Ip5sO4IGXJQlDUDm+kpkcvN7E1vCHkTgtKC8D/IvAiPEYD1c m6aUmQgY+O+CrHUmN0tI0zye+ffuvAzv1QQFhOjL4615q/jpKyqq0UTp+XOKH1MAOQoW9L9Il aIlfx49p+eBrgvf7h0pxoE9PS8pGSu8jeGmGdJpiAD5yVb/S7FiGrWI7HU+PWwsH8Yk++lGc2 2acyj0o6/r75489UylL7GOOLzm2lhgmCz0v1tXO16M9MT0SxwwEiixUYbMdHgKCIdgTdBJyqS yOo4EfYuklBb5M7W9b7i4rxBwIBvFe+Fo8d/R+DUKT9AdfNDAUnUCaUj/nmqZ5p6w+nq8Z+HC y8XfZEb5PyBU35V/louiTE4AkptKteAFYEPtALi10DSR+2bJb+0uQlHrz8E5V6FOxrPoCeJoH VLCGGODoe6EfzCHPxXa5uyF9US68q03G3qsUF8xjy5eNl7ghR0lssfhR/GPWw2jWeIxR+bKZ0 rW+ge2hqPfTa7sCk/igaSzGNRiCxJMKVQGdHwGvqdD8YmvNS71egABqFDrEOK1l388OK6nYye DTVVu7TRB8PHAXzWyB+eeu6QuOOE39lTK7QFRyg== X-Rspamd-Queue-Id: 4Bvbb33JDBz3cq4 X-Spamd-Bar: - X-Spamd-Result: default: False [-1.11 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[gmx.net:s=badeba3b8450]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[walstatt.org]; RCPT_COUNT_ONE(0.00)[1]; HAS_ORG_HEADER(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[212.227.15.19:from]; NEURAL_HAM_MEDIUM(-0.68)[-0.678]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmx.net:+]; NEURAL_SPAM_LONG(0.20)[0.196]; NEURAL_HAM_SHORT(-0.13)[-0.127]; RECEIVED_SPAMHAUS_PBL(0.00)[77.183.147.118:received]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; MAILMAN_DEST(0.00)[freebsd-current]; RCVD_IN_DNSWL_LOW(-0.10)[212.227.15.19:from] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 20 Sep 2020 18:25:05 -0000 --Sig_/wSZ51QYMKDCj_RRrvRY9QXQ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable A couple of weeks for now it is impossible to compile nanoBSD (based on 12-STABLE, most recent r365925), compiled on a host running recent CURRENT (FreeBSD 13.0-CURRENT #0 r365487: Fri Sep 18 16:31:04 CEST 2020 amd64). Since the introduction of LLVM 10 to 12-STABLE and LLVM 11 to CURRENT, the (cross) compilation of nanoBSD fails on the building host with the error shown below. Although option "WITHOUT_RESCU" is set when either building or building/installing the sources, the shown error popps up. The curious thing is, that I also build 12-STABLE jails on the same CURRENT system the "tradiotional way" (means: building the 12-STABLE and then installing the jail via ezjail-admin without interaction of any foreign/network sources except the source repository. No error of the shown kind ever occurs. Can someon please explain this problem? It looks like a bug in a make file. Regards, Oliver [...] cc -target x86_64-unknown-freebsd12.2 --sysroot=3D/pool/nanobsd/amd64/ALERICH_12-STABLE_amd64/pool/sources/12-STA= BLE/src/amd64.amd64/tmp -B/pool/nanobsd/amd64/ALERICH_12-STABLE_amd64/pool/sources/12-STABLE/src/am= d64.amd64/tmp/usr/bin -pg -O2 -pipe -O3 -pipe -fno-common -I/pool/sources/12-STABLE/src/lib/msun/x86 -I/pool/sources/12-STABLE/src/lib/msun/ld80 -I/pool/sources/12-STABLE/src/lib/msun/amd64 -I/pool/sources/12-STABLE/src/lib/msun/src -I/pool/sources/12-STABLE/src/lib/libc/include -I/pool/sources/12-STABLE/src/lib/libc/amd64 -DNDEBUG -mretpoline -MD -MF.depend.e_j1f.po -MTe_j1f.po -std=3Dgnu99 -fstack-protector-strong -Wsystem-headers -Wno-pointer-sign -Wno-unknown-pragmas -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c /pool/sources/12-STABLE/src/lib/msun/src/e_j1f.c -o e_j1f.po --- all_subdir_rescue --- /pool/sources/12-STABLE/src/bin/cp/utils.c:517:14: error: member reference base type 'void' is not a structure or union aclp =3D &acl->ats_acl; ~~~^ ~~~~~~~ /pool/sources/12-STABLE/src/bin/cp/utils.c:518:11: error: incomplete definition of type 'struct acl' if (aclp->acl_cnt !=3D 0 && aclsetf(dest_dir, ~~~~^ /pool/sources/12-STABLE/src/bin/cp/utils.c:468:9: note: forward declaration of 'struct acl' struct acl *aclp; ^ 2 errors generated. *** [/pool/sources/12-STABLE/src/bin/cp/utils.o] Error code 1 make[6]: stopped in /pool/nanobsd/amd64/ALERICH_12-STABLE_amd64/pool/sources/12-STABLE/src/amd6= 4.amd64/rescue/rescue 1 error make[6]: stopped in /pool/nanobsd/amd64/ALERICH_12-STABLE_amd64/pool/sources/12-STABLE/src/amd6= 4.amd64/rescue/rescue *** [rescue] Error code 2 make[5]: stopped in /pool/sources/12-STABLE/src/rescue/rescue 1 error make[5]: stopped in /pool/sources/12-STABLE/src/rescue/rescue --Sig_/wSZ51QYMKDCj_RRrvRY9QXQ Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQSy8IBxAPDkqVBaTJ44N1ZZPba5RwUCX2eedQAKCRA4N1ZZPba5 R46qAQC2mb8BWQoqLMs4H6qGy4o2EFL4vUws5FvwB3bMI3SINQD+PDVfQ7oZs70K O/S5X934oAQYe3/Yds1XufWWknYc7QM= =sSRB -----END PGP SIGNATURE----- --Sig_/wSZ51QYMKDCj_RRrvRY9QXQ-- From owner-freebsd-current@freebsd.org Sun Sep 20 19:06: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 508663EBA53 for ; Sun, 20 Sep 2020 19:06:25 +0000 (UTC) (envelope-from lev@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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4BvcVm47Dkz436T; Sun, 20 Sep 2020 19:06:24 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.not-for.work (onlyone.not-for.work [IPv6:2a01:4f8:201:6350::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: lev/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 20BBB28494; Sun, 20 Sep 2020 19:06:22 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [192.168.23.230] (unknown [89.113.128.32]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.not-for.work (Postfix) with ESMTPSA id D24B11B47E; Sun, 20 Sep 2020 22:06:18 +0300 (MSK) Reply-To: lev@FreeBSD.org Subject: Re: Plans for git To: Bakul Shah , Warner Losh Cc: Zaphod Beeblebrox , Chris , Kristof Provost , FreeBSD Current References: <20200902063136.GA47543@troutmask.apl.washington.edu> <20200902164706.GA49777@troutmask.apl.washington.edu> <5c89b4d27281f5dfffc3252a90013b0ac6c763d7.camel@freebsd.org> <5c832482-b2bc-47e4-8762-8f5a886d5f11@www.fastmail.com> <68585ca4-5ca4-40d3-b2f4-67ff3b35b6ae@www.fastmail.com> <0be2ae57d1c58e2091f4cc4484731df0@bsdforge.com> <967D73EA-880E-413D-B748-62A406C46524@FreeBSD.org> <9f89dc553e7d7b0884c2862329bdfeae@bsdforge.com> From: Lev Serebryakov Organization: FreeBSD Message-ID: <23e7fc1c-6769-ceaf-4089-46e5cc575c20@FreeBSD.org> Date: Sun, 20 Sep 2020 22:06:18 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 20 Sep 2020 19:06:25 -0000 On 19.09.2020 19:05, Bakul Shah wrote: >> These are the main ones. The three down sides are lack of $FreeBSD$ support >> and tags in general. > > Can a git hook be used for this? git filters could be used for that, problem is it should be local configuration. You could not configure filters in clones automatically :-( -- // Lev Serebryakov From owner-freebsd-current@freebsd.org Sun Sep 20 19:29: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 6371C3EDE8E for ; Sun, 20 Sep 2020 19:29:04 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lj1-f176.google.com (mail-lj1-f176.google.com [209.85.208.176]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4Bvd0q4WXsz4N5y for ; Sun, 20 Sep 2020 19:28:57 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lj1-f176.google.com with SMTP id v23so9341948ljd.1 for ; Sun, 20 Sep 2020 12:28:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=+NZD+8ryAVNxdcD22DzrxhZl7erkdpKDO1ytbcSYkHM=; b=NsFlV7F/D0Jd+7c53Egy/13twu72PIjsSWcYMHiO+jtfqWNfD/tsfega+u4WkIHlsK I429vQ6MQe5T0SUDcN9vsWLqw1mMVMZk2agqh0BNo4KPAG3OSg6E2GyXHXFgsaNjFleE GQcVgiLTglj1zpYtkjslIQC7clXntxf80f3Pd3Wnt+OBLUacNsaiOpgtpHpiIk6gZzHU fEGXn1qs25TAZClCjSksHOROKJfQ3cZZga7uiqwGa28r0T38PladfuPsKNxf2YhBECw4 TudGDFlHKuVMQE66KlmHBjMAmnCmYhCJk5pnwmeRXlQGlBVNYHgnkULkheVoiC07FWfF 5rIg== X-Gm-Message-State: AOAM5339WAVraEzS1Bst4JhnCjI0ZY/dsXQlxPDxuUXYU8rBM3sYmbOk 5BhE88kskTmLdPsKF8P/srVD6D4EmgU= X-Google-Smtp-Source: ABdhPJxi1AwVO3hZw9yP/nQpLvAlH2kQWbxSVXcBJ1Nb0esS6lIZiC6gLh8QJg6ApJ7I73G5DQtPWg== X-Received: by 2002:a2e:907:: with SMTP id 7mr16113845ljj.470.1600630132586; Sun, 20 Sep 2020 12:28:52 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id y26sm2004421lfy.163.2020.09.20.12.28.51 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 20 Sep 2020 12:28:51 -0700 (PDT) Subject: Re: Plans for git To: freebsd-current@freebsd.org References: <20200902045939.GA15897@eureka.lemis.com> <20200902060117.GG53210@home.opsec.eu> <20200902063136.GA47543@troutmask.apl.washington.edu> <20200902164706.GA49777@troutmask.apl.washington.edu> <5c89b4d27281f5dfffc3252a90013b0ac6c763d7.camel@freebsd.org> <5c832482-b2bc-47e4-8762-8f5a886d5f11@www.fastmail.com> <68585ca4-5ca4-40d3-b2f4-67ff3b35b6ae@www.fastmail.com> <0be2ae57d1c58e2091f4cc4484731df0@bsdforge.com> <967D73EA-880E-413D-B748-62A406C46524@FreeBSD.org> <9f89dc553e7d7b0884c2862329bdfeae@bsdforge.com> From: Andriy Gapon Openpgp: preference=signencrypt Autocrypt: addr=avg@FreeBSD.org; prefer-encrypt=mutual; keydata= mDMEX1iFDhYJKwYBBAHaRw8BAQdAiu8JG/oLFkVkOAJqJc7Dx5KI/Q6C3SBI20EQm+DXnAu0 HkFuZHJpeSBHYXBvbiA8YXZnQEZyZWVCU0Qub3JnPoiWBBMWCAA+FiEEyCHHZM09l0OE3Ir/ 1A1+Gq8+L1EFAl9YhQ4CGwMFCQeEzgAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQ1A1+ Gq8+L1Fc0wD/ZjmhHfbCJywZU3aOxXIPjcz73FYEGMvqMCCLAWyLbSABALFL+1ZNrjV3BGjq 889cOYFuboA/Yn3eWezS+tfqYBsGuDgEX1iFDhIKKwYBBAGXVQEFAQEHQL6B20Xi600TrkpG P9fWjl7JtHNxqrHKhX6Kg7kgb4ILAwEIB4h+BBgWCAAmFiEEyCHHZM09l0OE3Ir/1A1+Gq8+ L1EFAl9YhQ4CGwwFCQeEzgAACgkQ1A1+Gq8+L1F3cgEAktp4h+IJUJxL1vn6zMOt//znni/J TanKfQuA8wGXcGkBAKpZJhqMkg+pKk7MGvJhgJ6nCpTZ+rMK6vZVZLUWc3QF Message-ID: <6ae80681-f866-756e-d361-10e742d2dbf5@FreeBSD.org> Date: Sun, 20 Sep 2020 22:28:50 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Firefox/60.0 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4Bvd0q4WXsz4N5y X-Spamd-Bar: - X-Spamd-Result: default: False [-1.72 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; NEURAL_HAM_SHORT(-0.29)[-0.288]; FORGED_SENDER(0.30)[avg@FreeBSD.org,agapon@gmail.com]; RECEIVED_SPAMHAUS_PBL(0.00)[93.72.151.96:received]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FROM_NEQ_ENVFROM(0.00)[avg@FreeBSD.org,agapon@gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; TO_DOM_EQ_FROM_DOM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.92)[-0.924]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.51)[-0.506]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[FreeBSD.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[209.85.208.176:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.208.176:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 20 Sep 2020 19:29:04 -0000 Just my +100500 to this. On 20/09/2020 18:03, Christian Weisgerber wrote: > On 2020-09-19, Zaphod Beeblebrox wrote: > >> Hrm. Maybe what I hear others saying, tho, and not entirely being replied >> to is just a nice concise document of the why. What I hear you saying is >> that GIT has momentum and that it's popular... (and I accept that --- it is >> evidently true), but then I hear handwaving about features, but no list of >> features that are a clear win/loose. > > How about the very basics (that Warner appears to have lost sight > of)? > > Git is a distributed version control system. You clone a repository > and apart from pulling and pushing changes to another repository, > all your work happens with the local repository. Subversion has a > central repository and needs to talk to the server all the time. > Laptop on a plane? No change of workflow with Git. > > And since it's your repository, you can cheaply create your own > branches, where you can commit your work and have a versioned history > of it instead of just a flat diff. I can't overstate the value of > that. Whether you work on something that will be pushed back > upstream or just your private changes, it has a full commit history. > You can easily revert commits, you can upstream it one by one, you > can upstream it with history. > > When FreeBSD switched from CVS to SVN, there was hope or promise > of lightweight branches, but that never materialized. Developers > still can't have private branches in the FreeBSD repository. For > a while, a lot of development happened in a Perforce repository--a > commerical version control system, whose company had donated a > license--which offered this feature. Nowadays, everybody who does > any but the most trivial development does so in a private Git > repository anyway. It only makes sense to interface this directly > with the FreeBSD repository instead of going through a SVN<>Git > media break. > >> Certainly the only clear things a quick search turns up that seem relevant >> is that GIT is GPL2.0 and SVN is Apache2.0. This was enough for LLVM vs >> GCC and the repository is a core function, but I suppose not a necessary >> function for forked projects that can't abide, so... > > There is a bit of historical precedent: The original BSD work at > Berkeley was kept in a SCCS repository, a proprietary version control > system at the time. > > And of course the fact that significant FreeBSD development has > effectively happened in Perforce, then in Git for a long time and > is just merged back into the Subversion repository. To put it > bluntly, the people doing the work have voted with their feet years > ago. > -- Andriy Gapon From owner-freebsd-current@freebsd.org Sun Sep 20 19:55: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 D6F613EF8B1 for ; Sun, 20 Sep 2020 19:55:37 +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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BvdbX3MDhz4SMb; Sun, 20 Sep 2020 19:55:36 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 08KJtRRD092848 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 20 Sep 2020 22:55:30 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 08KJtRRD092848 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 08KJtQqA092841; Sun, 20 Sep 2020 22:55:26 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 20 Sep 2020 22:55:26 +0300 From: Konstantin Belousov To: rhurlin@freebsd.org Cc: Hans Petter Selasky , monochrome , freebsd-current@freebsd.org Subject: Re: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X Message-ID: <20200920195526.GH94807@kib.kiev.ua> References: <69ff9432-fc8f-b0ab-8ad2-8e3daa77f8e1@twcny.rr.com> <1a88773b-d2fa-a790-c7e2-868d3884ba8b@twcny.rr.com> <865D6BF0-9F1E-4125-81D3-FB9A369FED8D@gwdg.de> <88af31d4-9ed9-172a-d48f-1780f19841e3@twcny.rr.com> <11d27d41-029a-d7f5-eccc-0ba3a3fcfe97@gwdg.de> <2bbfb4b3-92e9-b3ca-9c31-6c513cee2f2d@gwdg.de> <20200920093814.GD94807@kib.kiev.ua> <0249197f-29f6-4df4-eb63-ca786aaea39d@gwdg.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0249197f-29f6-4df4-eb63-ca786aaea39d@gwdg.de> 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: 4BvdbX3MDhz4SMb X-Spamd-Bar: / X-Spamd-Result: default: False [0.89 / 15.00]; RCVD_TLS_ALL(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_HAM_LONG(-0.22)[-0.225]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; NEURAL_HAM_MEDIUM(-0.19)[-0.195]; TO_DN_SOME(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_SHORT(1.31)[1.313]; 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]; MAILMAN_DEST(0.00)[freebsd-current]; 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.33 Precedence: 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, 20 Sep 2020 19:55:37 -0000 On Sun, Sep 20, 2020 at 03:11:26PM +0200, Rainer Hurling wrote: > Am 20.09.20 um 11:38 schrieb Konstantin Belousov: > > On Sun, Sep 20, 2020 at 10:26:11AM +0200, Rainer Hurling wrote: > >> Am 20.09.20 um 10:20 schrieb Hans Petter Selasky: > >>> On 2020-09-20 10:05, Rainer Hurling wrote: > >>>> Hi monochrome, > >>>> > >>>> back to keyboard, it tried newest CURRENT (r365920) on my box and even > >>>> with newest sources the error occurs. > >>>> > >>>> After looking around somewhat more, I found some hints about Virtualbox > >>>> kernel module having problems with r365488. Unfortunately, I am not able > >>>> to find the thread again :( > >>>> > >>>> What seems to help as a workaround is to disable the loading of > >>>> VirtualBox in /boot/loader.conf > >>>> > >>>> #vboxdrv_load="YES" > >>>> > >>>> and in /etc/rc.conf > >>>> > >>>> #vboxnet_enable="YES" > >>>> #vboxguest_enable="YES" > >>>> > >>>> > >>>> So probably, this page fault is not restricted to AMD Ryzen? > >>>> > >>> > >>> Possibly you need to rebuild that kernel module. Maybe the FreeBSD > >>> version was not bumped correctly. > >>> > >>> --HPS > >>> > >> > >> Thanks for the hint. But I did rebuild all kernel modules before > >> rebooting, in my case vbox*.ko, nvidia*.ko. > > > > Provide backtrace of the panic. > > > > Hi Konstantin, > > Thanks for your response. > > After trying several ways to produce a core dump or a working kdb prompt > without success, all I can offer is the following screen contents. I > built a GENERIC kernel with debugging enabled, enable loading of vboxdrv > via /boot/loader.conf and /etc/rc.conf as described above: > > > [..snip..] > procfs registered > modulte_register_init: MOD_LOAD (tmpfs, 0xffffffff80caa060, > 0xffffffff82520a70) error 17 > Timecounters tick every 1.000 msec > lo0: bpf attached > vlan: initialized, using hash tables with chaining > > > Fatal trap 12: page fault while in kernel mode > cpuid = 31; apic id = 1f > fault virtual address = 0x0 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff80ea889b > stack pointer = 0x20:0xffffffff826017e0 > frame pointer = 0x20:0xffffffff826017e0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 0 (swapper) > trap number = 12 > panic: page fault > cpuid = 31 > time = 1 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > 0xffffffff82601490 > vpanic() at vpanic+0x182/frame 0xffffffff826014e0 > panic() at panic+0x43/frame 0xffffffff82601540 > trap_fatal() at trap_fatal+0x387/frame 0xffffffff826015a0 > trap_pfault() at trap_pfault+0x97/frame 0xffffffff82601600 > calltrap() at calltrap+0x8/frame 0xffffffff82601710 > --- trap 0xc, rip = 0xffffffff80ea889b, rsp = 0xffffffff826017e0, rbp = > 0xffffffff826017e0 --- > phys_pager_getpages() at phys_pager_getpages+0xb/frame 0xffffffff826017e0 > vm_pager_get_pages() at vm_pager_get_pages+0x4f/frame 0xffffffff82601830 > vm_fault() at vm_fault+0x5d6/frame 0xffffffff82601940 > vm_map_wire_locked() at vm_map_wire_locked+0x3a6/framw 0xffffffff826019f0 > vm_map_wire() at vm_map_wire+0x6b/frame 0xffffffff82601a20 > rtR0MemObjFreeBSDAllocHelper() at > rtR0MemObjFreeBSDAllocHelper+0xdc/frame 0xffffffff82601a70 > rtR0MemObjNativeAllocCont() at rtR0MemObjNativeAllocCont+0x50/frame > 0xffffffff82601ac0 > supdrvGipCreate() at supdrvGipCreate+0x97/frame 0xffffffff82601b60 > supdrvInitDevExt() at supdrvInitDevExt+0x19a/frame 0xffffffff82601bd0 > VBoxDrvFreeBSDModuleEvent() at VBoxDrvFreeBSDModuleEvent+0x46/frame > 0xffffffff82601bf0 > module_register_init() at module_register_init+0xbd/frame 0xffffffff82601c20 > mi_startup() at mi_startup+0xec/frame 0xffffffff82601c70 > btext() at btext+0x2c > KDB: enter: panic > [ thread pid 0 tid 100000 ] > Stopped at kdb_enter+0x37: movq $0,0x10b5796(%rip9 > db> > > > The system freezes at this point, no core dump is generated ;) This > does not happen without loading VBoxDrv. > > At least, the screen dump shows VBoxDrvFreeBSDModuleEvent(). I hope, > this is of some help. > Yes it seems to be enough for me to see where the possible issue is. Try this patch, I did not even compiled it. Probably you need to put it into ports/emulators/virtualbox-ose-kmod/files with the name ending with .patch. --- src/VBox/Runtime/r0drv/freebsd/memobj-r0drv-freebsd.c.xxx 2020-09-20 19:40:07.471956776 +0000 +++ src/VBox/Runtime/r0drv/freebsd/memobj-r0drv-freebsd.c 2020-09-20 19:46:03.606966773 +0000 @@ -323,7 +323,8 @@ size_t cPages = atop(pMemFreeBSD->Core.cb); int rc; - pMemFreeBSD->pObject = vm_object_allocate(OBJT_PHYS, cPages); + pMemFreeBSD->pObject = vm_pager_allocate(OBJT_PHYS, NULL, + pMemFreeBSD->Core.cb, VM_PROT_ALL, 0, curthread->td_ucred); /* No additional object reference for auto-deallocation upon unmapping. */ #if __FreeBSD_version >= 1000055 @@ -457,7 +458,8 @@ return VERR_NO_MEMORY; } - pMemFreeBSD->pObject = vm_object_allocate(OBJT_PHYS, atop(cb)); + pMemFreeBSD->pObject = vm_pager_allocate(OBJT_PHYS, NULL, cb, VM_PROT_ALL, + 0, curthread->td_ucred); if (PhysHighest != NIL_RTHCPHYS) VmPhysAddrHigh = PhysHighest; From owner-freebsd-current@freebsd.org Sun Sep 20 20:07: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 659993EFB59 for ; Sun, 20 Sep 2020 20:07:44 +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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BvdsW4KB3z4TBS; Sun, 20 Sep 2020 20:07:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 08KK7Zva095710 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 20 Sep 2020 23:07:38 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 08KK7Zva095710 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 08KK7ZMr095709; Sun, 20 Sep 2020 23:07:35 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 20 Sep 2020 23:07:35 +0300 From: Konstantin Belousov To: rhurlin@freebsd.org Cc: Hans Petter Selasky , monochrome , freebsd-current@freebsd.org Subject: Re: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X Message-ID: <20200920200735.GJ94807@kib.kiev.ua> References: <69ff9432-fc8f-b0ab-8ad2-8e3daa77f8e1@twcny.rr.com> <1a88773b-d2fa-a790-c7e2-868d3884ba8b@twcny.rr.com> <865D6BF0-9F1E-4125-81D3-FB9A369FED8D@gwdg.de> <88af31d4-9ed9-172a-d48f-1780f19841e3@twcny.rr.com> <11d27d41-029a-d7f5-eccc-0ba3a3fcfe97@gwdg.de> <2bbfb4b3-92e9-b3ca-9c31-6c513cee2f2d@gwdg.de> <20200920093814.GD94807@kib.kiev.ua> <0249197f-29f6-4df4-eb63-ca786aaea39d@gwdg.de> <20200920195526.GH94807@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200920195526.GH94807@kib.kiev.ua> 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: 4BvdsW4KB3z4TBS X-Spamd-Bar: / X-Spamd-Result: default: False [0.77 / 15.00]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_HAM_LONG(-0.26)[-0.264]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; NEURAL_HAM_MEDIUM(-0.20)[-0.200]; R_SPF_SOFTFAIL(0.00)[~all:c]; NEURAL_SPAM_SHORT(1.24)[1.239]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; 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]; MAILMAN_DEST(0.00)[freebsd-current]; 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.33 Precedence: 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, 20 Sep 2020 20:07:44 -0000 On Sun, Sep 20, 2020 at 10:55:26PM +0300, Konstantin Belousov wrote: > On Sun, Sep 20, 2020 at 03:11:26PM +0200, Rainer Hurling wrote: > > Am 20.09.20 um 11:38 schrieb Konstantin Belousov: > > > On Sun, Sep 20, 2020 at 10:26:11AM +0200, Rainer Hurling wrote: > > >> Am 20.09.20 um 10:20 schrieb Hans Petter Selasky: > > >>> On 2020-09-20 10:05, Rainer Hurling wrote: > > >>>> Hi monochrome, > > >>>> > > >>>> back to keyboard, it tried newest CURRENT (r365920) on my box and even > > >>>> with newest sources the error occurs. > > >>>> > > >>>> After looking around somewhat more, I found some hints about Virtualbox > > >>>> kernel module having problems with r365488. Unfortunately, I am not able > > >>>> to find the thread again :( > > >>>> > > >>>> What seems to help as a workaround is to disable the loading of > > >>>> VirtualBox in /boot/loader.conf > > >>>> > > >>>> #vboxdrv_load="YES" > > >>>> > > >>>> and in /etc/rc.conf > > >>>> > > >>>> #vboxnet_enable="YES" > > >>>> #vboxguest_enable="YES" > > >>>> > > >>>> > > >>>> So probably, this page fault is not restricted to AMD Ryzen? > > >>>> > > >>> > > >>> Possibly you need to rebuild that kernel module. Maybe the FreeBSD > > >>> version was not bumped correctly. > > >>> > > >>> --HPS > > >>> > > >> > > >> Thanks for the hint. But I did rebuild all kernel modules before > > >> rebooting, in my case vbox*.ko, nvidia*.ko. > > > > > > Provide backtrace of the panic. > > > > > > > Hi Konstantin, > > > > Thanks for your response. > > > > After trying several ways to produce a core dump or a working kdb prompt > > without success, all I can offer is the following screen contents. I > > built a GENERIC kernel with debugging enabled, enable loading of vboxdrv > > via /boot/loader.conf and /etc/rc.conf as described above: > > > > > > [..snip..] > > procfs registered > > modulte_register_init: MOD_LOAD (tmpfs, 0xffffffff80caa060, > > 0xffffffff82520a70) error 17 > > Timecounters tick every 1.000 msec > > lo0: bpf attached > > vlan: initialized, using hash tables with chaining > > > > > > Fatal trap 12: page fault while in kernel mode > > cpuid = 31; apic id = 1f > > fault virtual address = 0x0 > > fault code = supervisor read data, page not present > > instruction pointer = 0x20:0xffffffff80ea889b > > stack pointer = 0x20:0xffffffff826017e0 > > frame pointer = 0x20:0xffffffff826017e0 > > code segment = base 0x0, limit 0xfffff, type 0x1b > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > processor eflags = interrupt enabled, resume, IOPL = 0 > > current process = 0 (swapper) > > trap number = 12 > > panic: page fault > > cpuid = 31 > > time = 1 > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > > 0xffffffff82601490 > > vpanic() at vpanic+0x182/frame 0xffffffff826014e0 > > panic() at panic+0x43/frame 0xffffffff82601540 > > trap_fatal() at trap_fatal+0x387/frame 0xffffffff826015a0 > > trap_pfault() at trap_pfault+0x97/frame 0xffffffff82601600 > > calltrap() at calltrap+0x8/frame 0xffffffff82601710 > > --- trap 0xc, rip = 0xffffffff80ea889b, rsp = 0xffffffff826017e0, rbp = > > 0xffffffff826017e0 --- > > phys_pager_getpages() at phys_pager_getpages+0xb/frame 0xffffffff826017e0 > > vm_pager_get_pages() at vm_pager_get_pages+0x4f/frame 0xffffffff82601830 > > vm_fault() at vm_fault+0x5d6/frame 0xffffffff82601940 > > vm_map_wire_locked() at vm_map_wire_locked+0x3a6/framw 0xffffffff826019f0 > > vm_map_wire() at vm_map_wire+0x6b/frame 0xffffffff82601a20 > > rtR0MemObjFreeBSDAllocHelper() at > > rtR0MemObjFreeBSDAllocHelper+0xdc/frame 0xffffffff82601a70 > > rtR0MemObjNativeAllocCont() at rtR0MemObjNativeAllocCont+0x50/frame > > 0xffffffff82601ac0 > > supdrvGipCreate() at supdrvGipCreate+0x97/frame 0xffffffff82601b60 > > supdrvInitDevExt() at supdrvInitDevExt+0x19a/frame 0xffffffff82601bd0 > > VBoxDrvFreeBSDModuleEvent() at VBoxDrvFreeBSDModuleEvent+0x46/frame > > 0xffffffff82601bf0 > > module_register_init() at module_register_init+0xbd/frame 0xffffffff82601c20 > > mi_startup() at mi_startup+0xec/frame 0xffffffff82601c70 > > btext() at btext+0x2c > > KDB: enter: panic > > [ thread pid 0 tid 100000 ] > > Stopped at kdb_enter+0x37: movq $0,0x10b5796(%rip9 > > db> > > > > > > The system freezes at this point, no core dump is generated ;) This > > does not happen without loading VBoxDrv. > > > > At least, the screen dump shows VBoxDrvFreeBSDModuleEvent(). I hope, > > this is of some help. > > > Yes it seems to be enough for me to see where the possible issue is. > Try this patch, I did not even compiled it. Probably you need to put > it into ports/emulators/virtualbox-ose-kmod/files with the name ending > with .patch. This seems to be wrong, name should _start_ with the prefix 'patch-'. > > --- src/VBox/Runtime/r0drv/freebsd/memobj-r0drv-freebsd.c.xxx 2020-09-20 19:40:07.471956776 +0000 > +++ src/VBox/Runtime/r0drv/freebsd/memobj-r0drv-freebsd.c 2020-09-20 19:46:03.606966773 +0000 > @@ -323,7 +323,8 @@ > size_t cPages = atop(pMemFreeBSD->Core.cb); > int rc; > > - pMemFreeBSD->pObject = vm_object_allocate(OBJT_PHYS, cPages); > + pMemFreeBSD->pObject = vm_pager_allocate(OBJT_PHYS, NULL, > + pMemFreeBSD->Core.cb, VM_PROT_ALL, 0, curthread->td_ucred); > > /* No additional object reference for auto-deallocation upon unmapping. */ > #if __FreeBSD_version >= 1000055 > @@ -457,7 +458,8 @@ > return VERR_NO_MEMORY; > } > > - pMemFreeBSD->pObject = vm_object_allocate(OBJT_PHYS, atop(cb)); > + pMemFreeBSD->pObject = vm_pager_allocate(OBJT_PHYS, NULL, cb, VM_PROT_ALL, > + 0, curthread->td_ucred); > > if (PhysHighest != NIL_RTHCPHYS) > VmPhysAddrHigh = PhysHighest; > > _______________________________________________ > 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 Sep 20 20:35: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 B32933F064A for ; Sun, 20 Sep 2020 20:35:38 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from gmailer.gwdg.de (gmailer.gwdg.de [134.76.11.17]) (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 4BvfTj5nXdz4VBV for ; Sun, 20 Sep 2020 20:35:37 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from excmbx-03.um.gwdg.de ([134.76.9.218] helo=email.gwdg.de) by mailer.gwdg.de with esmtp (GWDG Mailer) (envelope-from ) id 1kK63b-0005QE-Nq; Sun, 20 Sep 2020 22:35:35 +0200 Received: from krabat.raven.hur (10.250.9.199) by EXCMBX-03.um.gwdg.de (134.76.9.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521) id 15.1.2044.4; Sun, 20 Sep 2020 22:35:35 +0200 Subject: Re: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X To: Konstantin Belousov CC: Hans Petter Selasky , monochrome , References: <69ff9432-fc8f-b0ab-8ad2-8e3daa77f8e1@twcny.rr.com> <1a88773b-d2fa-a790-c7e2-868d3884ba8b@twcny.rr.com> <865D6BF0-9F1E-4125-81D3-FB9A369FED8D@gwdg.de> <88af31d4-9ed9-172a-d48f-1780f19841e3@twcny.rr.com> <11d27d41-029a-d7f5-eccc-0ba3a3fcfe97@gwdg.de> <2bbfb4b3-92e9-b3ca-9c31-6c513cee2f2d@gwdg.de> <20200920093814.GD94807@kib.kiev.ua> <0249197f-29f6-4df4-eb63-ca786aaea39d@gwdg.de> <20200920195526.GH94807@kib.kiev.ua> <20200920200735.GJ94807@kib.kiev.ua> Reply-To: From: Rainer Hurling Message-ID: <1621df05-35a9-92b9-ffee-d93c17110d87@gwdg.de> Date: Sun, 20 Sep 2020 22:35:26 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.3.0 MIME-Version: 1.0 In-Reply-To: <20200920200735.GJ94807@kib.kiev.ua> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.250.9.199] X-ClientProxiedBy: EXCMBX-03.um.gwdg.de (134.76.9.218) To EXCMBX-03.um.gwdg.de (134.76.9.218) X-Virus-Scanned: (clean) by clamav X-Rspamd-Queue-Id: 4BvfTj5nXdz4VBV X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.28 / 15.00]; HAS_REPLYTO(0.00)[rhurlin@freebsd.org]; HAS_XOIP(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:134.76.10.0/23]; RCVD_COUNT_THREE(0.00)[3]; RCVD_IN_DNSWL_MED(-0.20)[134.76.11.17:from]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:680, ipnet:134.76.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[rhurlin]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_MEDIUM(-1.03)[-1.034]; NEURAL_HAM_LONG(-0.96)[-0.959]; MIME_GOOD(-0.10)[text/plain]; REPLYTO_DOM_NEQ_FROM_DOM(0.00)[]; DMARC_NA(0.00)[gwdg.de]; NEURAL_SPAM_SHORT(0.21)[0.214]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RWL_MAILSPIKE_VERYGOOD(0.00)[134.76.11.17:from]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 20 Sep 2020 20:35:38 -0000 On 20.09.20 22:07, Konstantin Belousov wrote: > On Sun, Sep 20, 2020 at 10:55:26PM +0300, Konstantin Belousov wrote: >> On Sun, Sep 20, 2020 at 03:11:26PM +0200, Rainer Hurling wrote: >>> Am 20.09.20 um 11:38 schrieb Konstantin Belousov: >>>> On Sun, Sep 20, 2020 at 10:26:11AM +0200, Rainer Hurling wrote: >>>>> Am 20.09.20 um 10:20 schrieb Hans Petter Selasky: >>>>>> On 2020-09-20 10:05, Rainer Hurling wrote: >>>>>>> Hi monochrome, >>>>>>> >>>>>>> back to keyboard, it tried newest CURRENT (r365920) on my box and even >>>>>>> with newest sources the error occurs. >>>>>>> >>>>>>> After looking around somewhat more, I found some hints about Virtualbox >>>>>>> kernel module having problems with r365488. Unfortunately, I am not able >>>>>>> to find the thread again :( >>>>>>> >>>>>>> What seems to help as a workaround is to disable the loading of >>>>>>> VirtualBox in /boot/loader.conf >>>>>>> >>>>>>> #vboxdrv_load="YES" >>>>>>> >>>>>>> and in /etc/rc.conf >>>>>>> >>>>>>> #vboxnet_enable="YES" >>>>>>> #vboxguest_enable="YES" >>>>>>> >>>>>>> >>>>>>> So probably, this page fault is not restricted to AMD Ryzen? >>>>>>> >>>>>> >>>>>> Possibly you need to rebuild that kernel module. Maybe the FreeBSD >>>>>> version was not bumped correctly. >>>>>> >>>>>> --HPS >>>>>> >>>>> >>>>> Thanks for the hint. But I did rebuild all kernel modules before >>>>> rebooting, in my case vbox*.ko, nvidia*.ko. >>>> >>>> Provide backtrace of the panic. >>>> >>> >>> Hi Konstantin, >>> >>> Thanks for your response. >>> >>> After trying several ways to produce a core dump or a working kdb prompt >>> without success, all I can offer is the following screen contents. I >>> built a GENERIC kernel with debugging enabled, enable loading of vboxdrv >>> via /boot/loader.conf and /etc/rc.conf as described above: >>> >>> >>> [..snip..] >>> procfs registered >>> modulte_register_init: MOD_LOAD (tmpfs, 0xffffffff80caa060, >>> 0xffffffff82520a70) error 17 >>> Timecounters tick every 1.000 msec >>> lo0: bpf attached >>> vlan: initialized, using hash tables with chaining >>> >>> >>> Fatal trap 12: page fault while in kernel mode >>> cpuid = 31; apic id = 1f >>> fault virtual address = 0x0 >>> fault code = supervisor read data, page not present >>> instruction pointer = 0x20:0xffffffff80ea889b >>> stack pointer = 0x20:0xffffffff826017e0 >>> frame pointer = 0x20:0xffffffff826017e0 >>> code segment = base 0x0, limit 0xfffff, type 0x1b >>> = DPL 0, pres 1, long 1, def32 0, gran 1 >>> processor eflags = interrupt enabled, resume, IOPL = 0 >>> current process = 0 (swapper) >>> trap number = 12 >>> panic: page fault >>> cpuid = 31 >>> time = 1 >>> KDB: stack backtrace: >>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >>> 0xffffffff82601490 >>> vpanic() at vpanic+0x182/frame 0xffffffff826014e0 >>> panic() at panic+0x43/frame 0xffffffff82601540 >>> trap_fatal() at trap_fatal+0x387/frame 0xffffffff826015a0 >>> trap_pfault() at trap_pfault+0x97/frame 0xffffffff82601600 >>> calltrap() at calltrap+0x8/frame 0xffffffff82601710 >>> --- trap 0xc, rip = 0xffffffff80ea889b, rsp = 0xffffffff826017e0, rbp = >>> 0xffffffff826017e0 --- >>> phys_pager_getpages() at phys_pager_getpages+0xb/frame 0xffffffff826017e0 >>> vm_pager_get_pages() at vm_pager_get_pages+0x4f/frame 0xffffffff82601830 >>> vm_fault() at vm_fault+0x5d6/frame 0xffffffff82601940 >>> vm_map_wire_locked() at vm_map_wire_locked+0x3a6/framw 0xffffffff826019f0 >>> vm_map_wire() at vm_map_wire+0x6b/frame 0xffffffff82601a20 >>> rtR0MemObjFreeBSDAllocHelper() at >>> rtR0MemObjFreeBSDAllocHelper+0xdc/frame 0xffffffff82601a70 >>> rtR0MemObjNativeAllocCont() at rtR0MemObjNativeAllocCont+0x50/frame >>> 0xffffffff82601ac0 >>> supdrvGipCreate() at supdrvGipCreate+0x97/frame 0xffffffff82601b60 >>> supdrvInitDevExt() at supdrvInitDevExt+0x19a/frame 0xffffffff82601bd0 >>> VBoxDrvFreeBSDModuleEvent() at VBoxDrvFreeBSDModuleEvent+0x46/frame >>> 0xffffffff82601bf0 >>> module_register_init() at module_register_init+0xbd/frame 0xffffffff82601c20 >>> mi_startup() at mi_startup+0xec/frame 0xffffffff82601c70 >>> btext() at btext+0x2c >>> KDB: enter: panic >>> [ thread pid 0 tid 100000 ] >>> Stopped at kdb_enter+0x37: movq $0,0x10b5796(%rip9 >>> db> >>> >>> >>> The system freezes at this point, no core dump is generated ;) This >>> does not happen without loading VBoxDrv. >>> >>> At least, the screen dump shows VBoxDrvFreeBSDModuleEvent(). I hope, >>> this is of some help. >>> >> Yes it seems to be enough for me to see where the possible issue is. >> Try this patch, I did not even compiled it. Probably you need to put >> it into ports/emulators/virtualbox-ose-kmod/files with the name ending >> with .patch. > This seems to be wrong, name should _start_ with the prefix 'patch-'. Many thanks for the patch! Putting it into emulators/virtualbox-ose-kmod/files/ as patch-src_VBox_Runtime_r0drv_freebsd_memobj-r0drv-freebsd.c does not patch the sources, probably because emobj-r0drv-freebsd.c was already patched from the main port (virtualbox-ose). Patching manually, build and install the kernel module seems to work fine. Unfortunaly, after rebooting the same page fault occurs :( >> >> --- src/VBox/Runtime/r0drv/freebsd/memobj-r0drv-freebsd.c.xxx 2020-09-20 19:40:07.471956776 +0000 >> +++ src/VBox/Runtime/r0drv/freebsd/memobj-r0drv-freebsd.c 2020-09-20 19:46:03.606966773 +0000 >> @@ -323,7 +323,8 @@ >> size_t cPages = atop(pMemFreeBSD->Core.cb); >> int rc; >> >> - pMemFreeBSD->pObject = vm_object_allocate(OBJT_PHYS, cPages); >> + pMemFreeBSD->pObject = vm_pager_allocate(OBJT_PHYS, NULL, >> + pMemFreeBSD->Core.cb, VM_PROT_ALL, 0, curthread->td_ucred); >> >> /* No additional object reference for auto-deallocation upon unmapping. */ >> #if __FreeBSD_version >= 1000055 >> @@ -457,7 +458,8 @@ >> return VERR_NO_MEMORY; >> } >> >> - pMemFreeBSD->pObject = vm_object_allocate(OBJT_PHYS, atop(cb)); >> + pMemFreeBSD->pObject = vm_pager_allocate(OBJT_PHYS, NULL, cb, VM_PROT_ALL, >> + 0, curthread->td_ucred); >> >> if (PhysHighest != NIL_RTHCPHYS) >> VmPhysAddrHigh = PhysHighest; >> >> _______________________________________________ >> 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 Sep 20 20:54: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 843B53F0DD6 for ; Sun, 20 Sep 2020 20:54:06 +0000 (UTC) (envelope-from rcarter@pinyon.org) Received: from h2.pinyon.org (h2.pinyon.org [65.101.20.170]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4Bvfv11GZHz4WNv for ; Sun, 20 Sep 2020 20:54:04 +0000 (UTC) (envelope-from rcarter@pinyon.org) Received: from [10.0.10.15] (unknown [10.0.10.15]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by h2.pinyon.org (Postfix) with ESMTPSA id 8750329BC1 for ; Sun, 20 Sep 2020 13:54:02 -0700 (MST) Subject: Re: Plans for git To: freebsd-current@freebsd.org References: <20200902060117.GG53210@home.opsec.eu> <20200902063136.GA47543@troutmask.apl.washington.edu> <20200902164706.GA49777@troutmask.apl.washington.edu> <5c89b4d27281f5dfffc3252a90013b0ac6c763d7.camel@freebsd.org> <5c832482-b2bc-47e4-8762-8f5a886d5f11@www.fastmail.com> <68585ca4-5ca4-40d3-b2f4-67ff3b35b6ae@www.fastmail.com> <0be2ae57d1c58e2091f4cc4484731df0@bsdforge.com> <967D73EA-880E-413D-B748-62A406C46524@FreeBSD.org> <9f89dc553e7d7b0884c2862329bdfeae@bsdforge.com> <6ae80681-f866-756e-d361-10e742d2dbf5@FreeBSD.org> From: "Russell L. Carter" Message-ID: <23a4cfd5-e7a7-4c8f-5cc8-7937caae4009@pinyon.org> Date: Sun, 20 Sep 2020 13:54:02 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Firefox/68.0 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <6ae80681-f866-756e-d361-10e742d2dbf5@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.10 X-Rspamd-Server: h2 X-Rspamd-Queue-Id: 4Bvfv11GZHz4WNv X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.70 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[pinyon.org:s=dkim]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; 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(-1.05)[-1.045]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[pinyon.org:+]; NEURAL_HAM_SHORT(-0.19)[-0.195]; DMARC_NA(0.00)[pinyon.org]; NEURAL_HAM_MEDIUM(-0.96)[-0.959]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:209, ipnet:65.101.0.0/18, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 20 Sep 2020 20:54:06 -0000 On 2020-09-20 12:28, Andriy Gapon wrote: > Just my +100500 to this. > > On 20/09/2020 18:03, Christian Weisgerber wrote: >> On 2020-09-19, Zaphod Beeblebrox wrote: >> >>> Hrm. Maybe what I hear others saying, tho, and not entirely being replied >>> to is just a nice concise document of the why. What I hear you saying is >>> that GIT has momentum and that it's popular... (and I accept that --- it is >>> evidently true), but then I hear handwaving about features, but no list of >>> features that are a clear win/loose. >> >> How about the very basics (that Warner appears to have lost sight >> of)? >> >> Git is a distributed version control system. You clone a repository >> and apart from pulling and pushing changes to another repository, >> all your work happens with the local repository. Subversion has a >> central repository and needs to talk to the server all the time. >> Laptop on a plane? No change of workflow with Git. >> >> And since it's your repository, you can cheaply create your own >> branches, where you can commit your work and have a versioned history >> of it instead of just a flat diff. I can't overstate the value of >> that. Whether you work on something that will be pushed back >> upstream or just your private changes, it has a full commit history. >> You can easily revert commits, you can upstream it one by one, you >> can upstream it with history. Back in 2009 I had my small dev group using git-svn to allow us all to work remotely with at least *some* flexibility against the $JOB svn repo. The svn interactive response was dreadful over our DSL connections. I flew to SF to the $JOB hq and purposely made a few offline commits on the plane. Then at the office I merged them, trivially. None of the devs there had any experience with git. It blew their minds. (obvs any other DVCS can do that too) git can seem to have bottomless command line complexity from the point of view of a casual user. I look at the answers to edge case problems posted on SO and just laugh. People have careers being git specialists. However you don't need to know much to get very productive. And if you use emacs, there is no debate that magit is a stellar interface to git, maybe the very best. I believe I've heard noises about its functionality being replicated into vim. Once you use something like magit even complex operations have very little cognitive overhead. For example, picking the exact changes you want to commit together from an already coded larger set of changes is easy. I'm always fixing eg. doc nits when I see them, when working on code/bugs and then later group those into their own commit. Maybe you can do that now in svn but it is a pleasure with magit. just my 2¢ Russell >> >> When FreeBSD switched from CVS to SVN, there was hope or promise >> of lightweight branches, but that never materialized. Developers >> still can't have private branches in the FreeBSD repository. For >> a while, a lot of development happened in a Perforce repository--a >> commerical version control system, whose company had donated a >> license--which offered this feature. Nowadays, everybody who does >> any but the most trivial development does so in a private Git >> repository anyway. It only makes sense to interface this directly >> with the FreeBSD repository instead of going through a SVN<>Git >> media break. >> >>> Certainly the only clear things a quick search turns up that seem relevant >>> is that GIT is GPL2.0 and SVN is Apache2.0. This was enough for LLVM vs >>> GCC and the repository is a core function, but I suppose not a necessary >>> function for forked projects that can't abide, so... >> >> There is a bit of historical precedent: The original BSD work at >> Berkeley was kept in a SCCS repository, a proprietary version control >> system at the time. >> >> And of course the fact that significant FreeBSD development has >> effectively happened in Perforce, then in Git for a long time and >> is just merged back into the Subversion repository. To put it >> bluntly, the people doing the work have voted with their feet years >> ago. >> > > From owner-freebsd-current@freebsd.org Sun Sep 20 21:53:42 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 55B093F348E for ; Sun, 20 Sep 2020 21:53:42 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qt1-f173.google.com (mail-qt1-f173.google.com [209.85.160.173]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4BvhCn29qJz4bQy; Sun, 20 Sep 2020 21:53:41 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-qt1-f173.google.com with SMTP id n10so10690322qtv.3; Sun, 20 Sep 2020 14:53:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=qCJC0+hyocSh8imEHogH2nau/Vkq0dG8uAFXbH3CxrA=; b=dFbB9OtBXmcjcdsw35uFggWf9n9ddPc1gaMRNymbkk6tm6LaRD2QlA4yg6WGYu0Nif YtdoS9O4AB+pYw/VkQoN595fPx1/LEw8ywSGFqV5GpfWIGzVuivSyp/4aVk1JpgwahEo Tyh4ueg0UsjQZ19ivPPhgsevZ9/38E5OqOYaFK3+uuZ1XLZK311Fm+eTmS1hY7F0T8Pl 9Nyn+1vGc6vEtlU4sblQmo9od7jaFtKik5PBbQI/GE3GI5OhA3lLobB6DsasSvoUV2N2 RWC+zMFvW68upJyd/7Kc/otac3QcSQsUngy4dFQkARGzTza8deGd1013X5gfDm5FWJrz vUJQ== X-Gm-Message-State: AOAM533cZgDEoMkJFOPYx1RE1O+MPglsJF9aTCs0VQi0NySPojLWcgvy 2mHwTHGZu5dBQigY45Ils44qOsyU7yCWiRJkN/jzol8izMODFQ== X-Google-Smtp-Source: ABdhPJyOHUAHis3zu6J8sXu0mxHtF1t42XvRLP+RoDk6tm79V1QFPL4J39n9aeH96IgZb0pHk3SbGckEKdUv4aDg9aw= X-Received: by 2002:ac8:3704:: with SMTP id o4mr40311391qtb.330.1600638818210; Sun, 20 Sep 2020 14:53:38 -0700 (PDT) MIME-Version: 1.0 References: <202008282003.07SK3tuD093523@repo.freebsd.org> In-Reply-To: <202008282003.07SK3tuD093523@repo.freebsd.org> From: Adrian Chadd Date: Sun, 20 Sep 2020 14:53:26 -0700 Message-ID: Subject: Re: svn commit: r364936 - in head: lib lib/libnetmap share/mk To: Vincenzo Maffione , freebsd-current X-Rspamd-Queue-Id: 4BvhCn29qJz4bQy X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.45 / 15.00]; FROM_NEQ_ENVFROM(0.00)[adrian@freebsd.org,adrianchadd@gmail.com]; MAILMAN_DEST(0.00)[freebsd-current]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[209.85.160.173:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[freebsd.org]; ARC_NA(0.00)[]; NEURAL_HAM_LONG(-1.01)[-1.009]; NEURAL_HAM_MEDIUM(-0.96)[-0.963]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.47)[-0.474]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[209.85.160.173:from]; FORGED_SENDER(0.30)[adrian@freebsd.org,adrianchadd@gmail.com]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 20 Sep 2020 21:53:42 -0000 hi! This code fails compilation on mips32 + gcc, as it assumes uint64_t and pointer casts are the same underlying size. === /usr/local/bin/mips-unknown-freebsd13.0-gcc9 --sysroot=/usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp -B/usr/local/mips-unknown-freebsd13.0/bin/ -O -pipe -fno-common -G0 -EB -mabi=32 -msoft-float -march=mips32 -I/usr/home/adrian/work/freebsd/head-embedded/src/sys/net -I/usr/home/adrian/work/freebsd/head-embedded/src/lib/libnetmap -g -MD -MF.depend.nmport.o -MTnmport.o -std=gnu99 -Wno-format-zero-length -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-error=address -Wno-error=array-bounds -Wno-error=attributes -Wno-error=bool-compare -Wno-error=cast-align -Wno-error=clobbered -Wno-error=deprecated-declarations -Wno-error=enum-compare -Wno-error=extra -Wno-error=inline -Wno-error=logical-not-parentheses -Wno-error=strict-aliasing -Wno-error=uninitialized -Wno-error=unused-but-set-variable -Wno-error=unused-function -Wno-error=unused-value -Wno-error=empty-body -Wno-error=maybe-uninitialized -Wno-error=nonnull-compare -Wno-error=redundant-decls -Wno-error=shift-negative-value -Wno-error=tautological-compare -Wno-error=unused-const-variable -Wno-error=bool-operation -Wno-error=deprecated -Wno-error=expansion-to-defined -Wno-error=format-overflow -Wno-error=format-truncation -Wno-error=implicit-fallthrough -Wno-error=int-in-bool-context -Wno-error=memset-elt-size -Wno-error=noexcept-type -Wno-error=nonnull -Wno-error=pointer-compare -Wno-error=stringop-overflow -Wno-error=aggressive-loop-optimizations -Wno-error=cast-function-type -Wno-error=catch-value -Wno-error=multistatement-macros -Wno-error=restrict -Wno-error=sizeof-pointer-memaccess -Wno-error=stringop-truncation -Wno-error=empty-body -Wno-error=overflow -Wno-address-of-packed-member -c /usr/home/adrian/work/freebsd/head-embedded/src/lib/libnetmap/nmport.c -o nmport.o In file included from /usr/home/adrian/work/freebsd/head-embedded/src/lib/libnetmap/nmport.c:46: /usr/home/adrian/work/freebsd/head-embedded/src/lib/libnetmap/nmport.c: In function 'nmport_register': /usr/home/adrian/work/freebsd/head-embedded/src/lib/libnetmap/libnetmap.h:557:14: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] 557 | for ((o_) = (struct nmreq_option *)((h_)->nr_options);\ | ^ /usr/home/adrian/work/freebsd/head-embedded/src/lib/libnetmap/nmport.c:547:3: note: in expansion of macro 'nmreq_foreach_option' 547 | nmreq_foreach_option(&d->hdr, o) { | ^~~~~~~~~~~~~~~~~~~~ /usr/home/adrian/work/freebsd/head-embedded/src/lib/libnetmap/libnetmap.h:559:14: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] 559 | (o_) = (struct nmreq_option *)((o_)->nro_next)) | ^ /usr/home/adrian/work/freebsd/head-embedded/src/lib/libnetmap/nmport.c:547:3: note: in expansion of macro 'nmreq_foreach_option' 547 | nmreq_foreach_option(&d->hdr, o) { | ^~~~~~~~~~~~~~~~~~~~ /usr/home/adrian/work/freebsd/head-embedded/src/lib/libnetmap/nmport.c: In function 'nmport_mmap': /usr/home/adrian/work/freebsd/head-embedded/src/lib/libnetmap/nmport.c:617:13: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] 617 | m->mem = (void *)d->extmem->nro_usrptr; | ^ cc1: all warnings being treated as errors *** [nmport.o] Error code 1 === Are you able to fix this? pretty please? :) -adrian On Fri, 28 Aug 2020 at 13:04, Vincenzo Maffione wrote: > Author: vmaffione > Date: Fri Aug 28 20:03:54 2020 > New Revision: 364936 > URL: https://svnweb.freebsd.org/changeset/base/364936 > > Log: > lib: add libnetmap > > This changeset introduces the new libnetmap library for writing > netmap applications. > Before libnetmap, applications could either use the kernel API > directly (e.g. NIOCREGIF/NIOCCTRL) or the simple header-only-library > netmap_user.h (e.g. nm_open(), nm_close(), nm_mmap() etc.) > > The new library offers more functionalities than netmap_user.h: > - Support for complex netmap options, such as external memory > allocators or per-buffer offsets. This opens the way to future > extensions. > - More flexibility in the netmap port bind options, such as > non-numeric names for pipes, or the ability to specify the netmap > allocator that must be used for a given port. > - Automatic tracking of the netmap memory regions in use across the > open ports. > > At the moment there is no man page, but the libnetmap.h header file > has in-depth documentation. > > Reviewed by: hrs > MFC after: 2 weeks > Differential Revision: https://reviews.freebsd.org/D26171 > > Added: > head/lib/libnetmap/ > head/lib/libnetmap/Makefile (contents, props changed) > head/lib/libnetmap/libnetmap.h (contents, props changed) > head/lib/libnetmap/nmctx-pthreads.c (contents, props changed) > head/lib/libnetmap/nmctx.c (contents, props changed) > head/lib/libnetmap/nmport.c (contents, props changed) > head/lib/libnetmap/nmreq.c (contents, props changed) > Modified: > head/lib/Makefile > head/share/mk/bsd.libnames.mk > head/share/mk/src.libnames.mk > > Modified: head/lib/Makefile > > ============================================================================== > --- head/lib/Makefile Fri Aug 28 19:59:02 2020 (r364935) > +++ head/lib/Makefile Fri Aug 28 20:03:54 2020 (r364936) > @@ -71,6 +71,7 @@ SUBDIR= ${SUBDIR_BOOTSTRAP} \ > libmt \ > lib80211 \ > libnetbsd \ > + libnetmap \ > libnv \ > libopenbsd \ > libopie \ > > Added: head/lib/libnetmap/Makefile > > ============================================================================== > --- /dev/null 00:00:00 1970 (empty, because file is newly added) > +++ head/lib/libnetmap/Makefile Fri Aug 28 20:03:54 2020 (r364936) > @@ -0,0 +1,16 @@ > +# > +# $FreeBSD$ > +# > + > +.include > + > +PACKAGE= lib${LIB} > +LIB= netmap > +SRCS= nmctx.c nmport.c \ > + nmctx-pthreads.c nmreq.c > +INCS= libnetmap.h > +#MAN= libnetmap.3 > +CFLAGS+= -I${SRCTOP}/sys/net -I${.CURDIR} > +WARNS?= 2 > + > +.include > > Added: head/lib/libnetmap/libnetmap.h > > ============================================================================== > --- /dev/null 00:00:00 1970 (empty, because file is newly added) > +++ head/lib/libnetmap/libnetmap.h Fri Aug 28 20:03:54 2020 > (r364936) > @@ -0,0 +1,660 @@ > +/*- > + * SPDX-License-Identifier: BSD-2-Clause-FreeBSD > + * > + * Copyright (C) 2018 Universita` di Pisa > + * All rights reserved. > + * > + * Redistribution and use in source and binary forms, with or without > + * modification, are permitted provided that the following conditions > + * are met: > + * > + * 1. Redistributions of source code must retain the above copyright > + * notice, this list of conditions and the following disclaimer. > + * 2. Redistributions in binary form must reproduce the above copyright > + * notice, this list of conditions and the following disclaimer in > the > + * documentation and/or other materials provided with the > distribution. > + * > + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND > + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE > + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR > PURPOSE > + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE > + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR > CONSEQUENTIAL > + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS > + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) > + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, > STRICT > + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY > WAY > + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF > + * SUCH DAMAGE. > + * $FreeBSD$ > + */ > + > +#ifndef LIBNETMAP_H_ > +#define LIBNETMAP_H_ > +/* if thread-safety is not needed, define LIBNETMAP_NOTHREADSAFE before > including > + * this file. > + */ > + > +/* NOTE: we include net/netmap_user.h without defining NETMAP_WITH_LIBS, > which > + * is deprecated. If you still need it, please define NETMAP_WITH_LIBS and > + * include net/netmap_user.h before including this file. > + */ > +#include > + > +struct nmctx; > +struct nmport_d; > +struct nmem_d; > + > +/* > + * A port open specification (portspec for brevity) has the following > syntax > + * (square brackets delimit optional parts): > + * > + * subsystem:vpname[mode][options] > + * > + * The "subsystem" is denoted by a prefix, possibly followed by an > identifier. > + * There can be several kinds of subsystems, each one selected by a > unique > + * prefix. Currently defined subsystems are: > + * > + * netmap (no id allowed) > + * the standard subsystem > + * > + * vale (followed by a possibly empty id) > + * the vpname is connected to a VALE switch > identified by > + * the id (an empty id selects the default switch) > + * > + * The "vpname" has the following syntax: > + * > + * identifier or > + * identifier1{identifier2 or > + * identifier1}identifier2 > + * > + * Identifiers are sequences of alphanumeric characters. The part that > begins > + * with either '{' or '}', when present, denotes a netmap pipe opened in > the > + * same memory region as the subsystem:indentifier1 port. > + * > + * The "mode" can be one of the following: > + * > + * ^ bind all host (sw) ring pairs > + * ^NN bind individual host ring pair > + * * bind host and NIC ring pairs > + * -NN bind individual NIC ring pair > + * @NN open the port in the NN memory region > + * a suffix starting with / and the following flags, > + * in any order: > + * x exclusive access > + * z zero copy monitor (both tx and rx) > + * t monitor tx side (copy monitor) > + * r monitor rx side (copy monitor) > + * R bind only RX ring(s) > + * T bind only TX ring(s) > + * > + * The "options" start at the first '@' character not followed by a > number. > + * Each option starts with '@' and has the following syntax: > + * > + * option (flag option) > + * option=value (single key option) > + * option:key1=value1,key2=value2,... (multi-key option) > + * > + * For multi-key options, the keys can be assigned in any order, but they > + * cannot be assigned more than once. It is not necessary to assign all > the > + * option keys: unmentioned keys will receive default values. Some > multi-key > + * options define a default key and also accept the single-key syntax, by > + * assigning the value to this key. > + * > + * NOTE: Options may be silently ignored if the port is already open by > some > + * other process. > + * > + * The currently available options are (default keys, when defined, are > marked > + * with '*'): > + * > + * share (single-key) > + * open the port in the same memory region used by the > + * given port name (the port name must be given in > + * subsystem:vpname form) > + * > + * conf (multi-key) > + * specify the rings/slots numbers (effective only on > + * ports that are created by the open operation > itself, > + * and ignored otherwise). > + * > + * The keys are: > + * > + * *rings number of tx and rx rings > + * tx-rings number of tx rings > + * rx-rings number of rx rings > + * host-rings number of tx and rx host rings > + * host-tx-rings number of host tx rings > + * host-rx-rings number of host rx rings > + * slots number of slots in each tx and rx > + * ring > + * tx-slots number of slots in each tx ring > + * rx-slots number of slots in each rx ring > + * > + * (more specific keys override the less specific > ones) > + * All keys default to zero if not assigned, and the > + * corresponding value will be chosen by netmap. > + * > + * extmem (multi-key) > + * open the port in the memory region obtained by > + * mmap()ing the given file. > + * > + * The keys are: > + * > + * *file the file to mmap > + * if-num number of pre-allocated netmap_if's > + * if-size size of each netmap_if > + * ring-num number of pre-allocated > netmap_ring's > + * ring-size size of each netmap_ring > + * buf-num number of pre-allocated buffers > + * buf-size size of each buffer > + * > + * file must be assigned. The other keys default to > zero, > + * causing netmap to take the corresponding values > from > + * the priv_{if,ring,buf}_{num,size} sysctls. > + * > + */ > + > + > +/* nmport manipulation */ > + > +/* struct nmport_d - describes a netmap port */ > +struct nmport_d { > + /* see net/netmap.h for the definition of these fields */ > + struct nmreq_header hdr; > + struct nmreq_register reg; > + > + /* all the fields below should be considered read-only */ > + > + /* if the same context is used throughout the program, d1->mem == > + * d2->mem iff d1 and d2 are using the memory region (i.e., zero > + * copy is possible between the two ports) > + */ > + struct nmem_d *mem; > + > + /* the nmctx used when this nmport_d was created */ > + struct nmctx *ctx; > + > + int register_done; /* nmport_register() has been called */ > + int mmap_done; /* nmport_mmap() has been called */ > + /* pointer to the extmem option contained in the hdr options, if > any */ > + struct nmreq_opt_extmem *extmem; > + > + /* the fields below are compatible with nm_open() */ > + int fd; /* "/dev/netmap", -1 if not open */ > + struct netmap_if *nifp; /* pointer to the netmap_if */ > + uint16_t first_tx_ring; > + uint16_t last_tx_ring; > + uint16_t first_rx_ring; > + uint16_t last_rx_ring; > + uint16_t cur_tx_ring; /* used by nmport_inject */ > + uint16_t cur_rx_ring; > + > + /* LIFO list of cleanup functions (used internally) */ > + struct nmport_cleanup_d *clist; > +}; > + > +/* nmport_open - opens a port from a portspec > + * @portspec the port opening specification > + * > + * If successful, the function returns a new nmport_d describing a netmap > + * port, opened according to the port specification, ready to be used for > rx > + * and/or tx. > + * > + * The rings available for tx are in the [first_tx_ring, last_tx_ring] > + * interval, and similarly for rx. One or both intervals may be empty. > + * > + * When done using it, the nmport_d descriptor must be closed using > + * nmport_close(). > + * > + * In case of error, NULL is returned, errno is set to some error, and an > + * error message is sent through the error() method of the current > context. > + */ > +struct nmport_d * nmport_open(const char *portspec); > + > +/* nport_close - close a netmap port > + * @d the port we want to close > + * > + * Undoes the actions performed by the nmport_open that created d, then > + * frees the descriptor. > + */ > +void nmport_close(struct nmport_d *d); > + > +/* nmport_inject - sends a packet > + * @d the port through which we want to send > + * @buf base address of the packet > + * @size its size in bytes > + * > + * Sends a packet using the cur_tx_ring and updates the index > + * to use all available tx rings in turn. Note: the packet is copied. > + * > + * Returns 0 on success an -1 on error. > + */ > +int nmport_inject(struct nmport_d *d, const void *buf, size_t size); > + > +/* > + * the functions below can be used to split the functionality of > + * nmport_open when special features (e.g., extra buffers) are needed > + * > + * The relation among the functions is as follows: > + * > + * |nmport_new > + * |nmport_prepare = | > + * | |nmport_parse > + * nmport_open =| > + * | |nmport_register > + * |nmport_open_desc =| > + * |nmport_mmap > + * > + */ > + > +/* nmport_new - create a new nmport_d > + * > + * Creates a new nmport_d using the malloc() method of the current default > + * context. Returns NULL on error, setting errno to an error value. > + */ > +struct nmport_d *nmport_new(void); > + > +/* nmport_parse - fills the nmport_d netmap-register request > + * @d the nmport to be filled > + * @portspec the port opening specification > + * > + * This function parses the portspec and initizalizes the @d->hdr and > @d->reg > + * fields. It may need to allocate a list of options. If an extmem option > is > + * found, it may also mmap() the corresponding file. > + * > + * It returns 0 on success. On failure it returns -1, sets errno to an > error > + * value and sends an error message to the error() method of the context > used > + * when @d was created. Moreover, *@d is left unchanged. > + */ > +int nmport_parse(struct nmport_d *d, const char *portspec); > + > +/* nmport_register - registers the port with netmap > + * @d the nmport to be registered > + * > + * This function obtains a netmap file descriptor and registers the port > with > + * netmap. The @d->hdr and @d->reg data structures must have been > previously > + * initialized (via nmport_parse() or otherwise). > + * > + * It returns 0 on success. On failure it returns -1, sets errno to an > error > + * value and sends an error message to the error() method of the context > used > + * when @d was created. Moreover, *@d is left unchanged. > + */ > +int nmport_register(struct nmport_d *); > + > +/* nmport_mmap - maps the port resources into the process memory > + * @d the nmport to be mapped > + * > + * The port must have been previously been registered using > nmport_register. > + * > + * Note that if extmem is used (either via an option or by calling an > + * nmport_extmem_* function before nmport_register()), no new mmap() is > issued. > + * > + * It returns 0 on success. On failure it returns -1, sets errno to an > error > + * value and sends an error message to the error() method of the context > used > + * when @d was created. Moreover, *@d is left unchanged. > + */ > +int nmport_mmap(struct nmport_d *); > + > +/* the following functions undo the actions of nmport_new(), > nmport_parse(), > + * nmport_register() and nmport_mmap(), respectively. > + */ > +void nmport_delete(struct nmport_d *); > +void nmport_undo_parse(struct nmport_d *); > +void nmport_undo_register(struct nmport_d *); > +void nmport_undo_mmap(struct nmport_d *); > + > +/* nmport_prepare - create a port descriptor, but do not open it > + * @portspec the port opening specification > + * > + * This functions creates a new nmport_d and initializes it according to > + * @portspec. It is equivalent to nmport_new() followed by nmport_parse(). > + * > + * It returns 0 on success. On failure it returns -1, sets errno to an > error > + * value and sends an error message to the error() method of the context > used > + * when @d was created. Moreover, *@d is left unchanged. > + */ > +struct nmport_d *nmport_prepare(const char *portspec); > + > +/* nmport_open_desc - open an initialized port descriptor > + * @d the descriptor we want to open > + * > + * Registers the port with netmap and maps the rings and buffers into the > + * process memory. It is equivalent to nmport_register() followed by > + * nmport_mmap(). > + * > + * It returns 0 on success. On failure it returns -1, sets errno to an > error > + * value and sends an error message to the error() method of the context > used > + * when @d was created. Moreover, *@d is left unchanged. > + */ > +int nmport_open_desc(struct nmport_d *d); > + > +/* the following functions undo the actions of nmport_prepare() > + * and nmport_open_desc(), respectively. > + */ > +void nmport_undo_prepare(struct nmport_d *); > +void nmport_undo_open_desc(struct nmport_d *); > + > +/* nmport_clone - copy an nmport_d > + * @d the nmport_d we want to copy > + * > + * Copying an nmport_d by hand should be avoided, since adjustments are > needed > + * and some part of the state cannot be easily duplicated. This function > + * creates a copy of @d in a safe way. The returned nmport_d contains > + * nmreq_header and nmreq_register structures equivalent to those > contained in > + * @d, except for the option list, which is ignored. The returned > nmport_d is > + * already nmport_prepare()d, but it must still be nmport_open_desc()ed. > The > + * new nmport_d uses the same nmctx as @d. > + * > + * If extmem was used for @d, then @d cannot be nmport_clone()d until it > has > + * been nmport_register()ed. > + * > + * In case of error, the function returns NULL, sets errno to an error > value > + * and sends an error message to the nmctx error() method. > + */ > +struct nmport_d *nmport_clone(struct nmport_d *); > + > +/* nmport_extmem - use extmem for this port > + * @d the port we want to use the extmem for > + * @base the base address of the extmem region > + * @size the size in bytes of the extmem region > + * > + * the memory that contains the netmap ifs, rings and buffers is usually > + * allocated by netmap and later mmap()ed by the applications. It is > sometimes > + * useful to reverse this process, by having the applications allocate > some > + * memory (through mmap() or otherwise) and then let netmap use it. The > extmem > + * option can be used to implement this latter strategy. The option can be > + * passed through the portspec using the '@extmem:...' syntax, or > + * programmatically by calling nmport_extmem() or > nmport_extmem_from_file() > + * between nmport_parse() and nmport_register() (or between > nmport_prepare() > + * and nmport_open_desc()). > + * > + * It returns 0 on success. On failure it returns -1, sets errno to an > error > + * value and sends an error message to the error() method of the context > used > + * when @d was created. Moreover, *@d is left unchanged. > + */ > +int nmport_extmem(struct nmport_d *d, void *base, size_t size); > + > +/* nmport_extmem_from_file - use the extmem obtained by mapping a file > + * @d the port we want to use the extmem for > + * @fname path of the file we want to map > + * > + * This works like nmport_extmem, but the extmem memory is obtained by > + * mmap()ping @fname. nmport_close() will also automatically munmap() the > file. > + * > + * It returns 0 on success. On failure it returns -1, sets errno to an > error > + * value and sends an error message to the error() method of the context > used > + * when @d was created. Moreover, *@d is left unchanged. > + */ > +int nmport_extmem_from_file(struct nmport_d *d, const char *fname); > + > +/* nmport_extmem_getinfo - opbtai a pointer to the extmem configuration > + * @d the port we want to obtain the pointer from > + * > + * Returns a pointer to the nmreq_pools_info structure containing the > + * configuration of the extmem attached to port @d, or NULL if no extmem > + * is attached. This can be used to set the desired configuration before > + * registering the port, or to read the actual configuration after > + * registration. > + */ > +struct nmreq_pools_info* nmport_extmem_getinfo(struct nmport_d *d); > + > + > +/* enable/disable options > + * > + * These functions can be used to disable options that the application > cannot > + * or doesn't want to handle, or to enable options that require special > support > + * from the application and are, therefore, disabled by default. Disabled > + * options will cause an error if encountered during option parsing. > + * > + * If the option is unknown, nmport_disable_option is a NOP, while > + * nmport_enable_option returns -1 and sets errno to EOPNOTSUPP. > + * > + * These functions are not threadsafe and are meant to be used at the > beginning > + * of the program. > + */ > +void nmport_disable_option(const char *opt); > +int nmport_enable_option(const char *opt); > + > +/* nmreq manipulation > + * > + * nmreq_header_init - initialize an nmreq_header > + * @hdr the nmreq_header to initialize > + * @reqtype the kind of netmap request > + * @body the body of the request > + * > + * Initialize the nr_version, nr_reqtype and nr_body fields of *@hdr. > + * The other fields are set to zero. > + */ > +void nmreq_header_init(struct nmreq_header *hdr, uint16_t reqtype, void > *body); > + > +/* > + * These functions allow for finer grained parsing of portspecs. They > are used > + * internally by nmport_parse(). > + */ > + > +/* nmreq_header_decode - initialize an nmreq_header > + * @ppspec: (in/out) pointer to a pointer to the portspec > + * @hdr: pointer to the nmreq_header to be initialized > + * @ctx: pointer to the nmctx to use (for errors) > + * > + * This function fills the @hdr the nr_name field with the port name > extracted > + * from *@pifname. The other fields of *@hdr are unchanged. The @pifname > is > + * updated to point at the first char past the port name. > + * > + * Returns 0 on success. In case of error, -1 is returned with errno set > to > + * EINVAL, @pifname is unchanged, *@hdr is also unchanged, and an error > message > + * is sent through @ctx->error(). > + */ > +int nmreq_header_decode(const char **ppspec, struct nmreq_header *hdr, > + struct nmctx *ctx); > + > +/* nmreq_regiter_decode - initialize an nmreq_register > + * @pmode: (in/out) pointer to a pointer to an opening mode > + * @reg: pointer to the nmreq_register to be initialized > + * @ctx: pointer to the nmctx to use (for errors) > + * > + * This function fills the nr_mode, nr_ringid, nr_flags and nr_mem_id > fields of > + * the structure pointed by @reg, according to the opening mode specified > by > + * *@pmode. The other fields of *@reg are unchanged. The @pmode is > updated to > + * point at the first char past the opening mode. > + * > + * If a '@' is encountered followed by something which is not a number, > parsing > + * stops (without error) and @pmode is left pointing at the '@' char. The > + * nr_mode, nr_ringid and nr_flags fields are still updated, but > nr_mem_id is > + * not touched and the interpretation of the '@' field is left to the > caller. > + * > + * Returns 0 on success. In case of error, -1 is returned with errno set > to > + * EINVAL, @pmode is unchanged, *@reg is also unchanged, and an error > message > + * is sent through @ctx->error(). > + */ > +int nmreq_register_decode(const char **pmode, struct nmreq_register *reg, > + struct nmctx *ctx); > + > +/* nmreq_options_decode - parse the "options" part of the portspec > + * @opt: pointer to the option list > + * @parsers: list of option parsers > + * @token: token to pass to each parser > + * @ctx: pointer to the nmctx to use (for errors and malloc/free) > + * > + * This function parses each option in @opt. Each option is matched > (based on > + * the "option" prefix) to a corresponding parser in @parsers. The > function > + * checks that the syntax is appropriate for the parser and it assigns > all the > + * keys mentioned in the option. It then passes control to the parser, to > + * interpret the keys values. > + * > + * Returns 0 on success. In case of error, -1 is returned, errno is set > to an > + * error value and a message is sent to @ctx->error(). The effects of > partially > + * interpreted options may not be undone. > + */ > +struct nmreq_opt_parser; > +int nmreq_options_decode(const char *opt, struct nmreq_opt_parser > *parsers, > + void *token, struct nmctx *ctx); > + > +struct nmreq_parse_ctx; > +/* type of the option-parsers callbacks */ > +typedef int (*nmreq_opt_parser_cb)(struct nmreq_parse_ctx *); > + > +#define NMREQ_OPT_MAXKEYS 16 /* max nr of recognized keys per option */ > + > +/* struct nmreq_opt_key - describes an option key */ > +struct nmreq_opt_key { > + const char *key; /* the key name */ > + int id; /* its position in the parse context */ > + unsigned int flags; > +#define NMREQ_OPTK_ALLOWEMPTY (1U << 0) /* =value may be omitted */ > +#define NMREQ_OPTK_MUSTSET (1U << 1) /* the key is mandatory */ > +#define NMREQ_OPTK_DEFAULT (1U << 2) /* this is the default key */ > +}; > + > +/* struct nmreq_opt_parser - describes an option parser */ > +struct nmreq_opt_parser { > + const char *prefix; /* matches one option prefix */ > + nmreq_opt_parser_cb parse; /* the parse callback */ > + int default_key; /* which option is the default if the > + parser is multi-key (-1 if none) */ > + int nr_keys; > + unsigned int flags; > +#define NMREQ_OPTF_DISABLED (1U << 0) > +#define NMREQ_OPTF_ALLOWEMPTY (1U << 1) /* =value can be omitted */ > + > + struct nmreq_opt_parser *next; /* list of options */ > + > + /* recognized keys */ > + struct nmreq_opt_key keys[NMREQ_OPT_MAXKEYS]; > +} __attribute__((aligned(16))); > + > +/* struct nmreq_parse_ctx - the parse context received by the parse > callback */ > +struct nmreq_parse_ctx { > + struct nmctx *ctx; /* the nmctx for errors and malloc/free */ > + void *token; /* the token passed to nmreq_options_parse > */ > + > + /* the value (i.e., the part after the = sign) of each recognized > key > + * is assigned to the corresponding entry in this array, based on > the > + * key id. Unassigned keys are left at NULL. > + */ > + const char *keys[NMREQ_OPT_MAXKEYS]; > +}; > + > +/* nmreq_get_mem_id - get the mem_id of the given port > + * @portname pointer to a pointer to the portname > + * @ctx pointer to the nmctx to use (for errors) > + * > + * *@portname must point to a substem:vpname porname, possibly followed by > + * something else. > + * > + * If successful, returns the mem_id of *@portname and moves @portname > past the > + * subsystem:vpname part of the input. In case of error it returns -1, > sets > + * errno to an error value and sends an error message to ctx->error(). > + */ > +int32_t nmreq_get_mem_id(const char **portname, struct nmctx *ctx); > + > +/* option list manipulation */ > +void nmreq_push_option(struct nmreq_header *, struct nmreq_option *); > +void nmreq_remove_option(struct nmreq_header *, struct nmreq_option *); > +struct nmreq_option *nmreq_find_option(struct nmreq_header *, uint32_t); > +void nmreq_free_options(struct nmreq_header *); > +const char* nmreq_option_name(uint32_t); > +#define nmreq_foreach_option(h_, o_) \ > + for ((o_) = (struct nmreq_option *)((h_)->nr_options);\ > + (o_) != NULL;\ > + (o_) = (struct nmreq_option *)((o_)->nro_next)) > + > +/* nmctx manipulation */ > + > +/* the nmctx serves a few purposes: > + * > + * - maintain a list of all memory regions open by the program, so that > two > + * ports that are using the same region (as identified by the mem_id) > will > + * point to the same nmem_d instance. > + * > + * - allow the user to specify how to lock accesses to the above list, if > + * needed (lock() callback) > + * > + * - allow the user to specify how error messages should be delivered > (error() > + * callback) > + * > + * - select the verbosity of the library (verbose field); if verbose==0, > no > + * errors are sent to the error() callback > + * > + * - allow the user to override the malloc/free functions used by the > library > + * (malloc() and free() callbacks) > + * > + */ > +typedef void (*nmctx_error_cb)(struct nmctx *, const char *); > +typedef void *(*nmctx_malloc_cb)(struct nmctx *,size_t); > +typedef void (*nmctx_free_cb)(struct nmctx *,void *); > +typedef void (*nmctx_lock_cb)(struct nmctx *, int); > + > +struct nmctx { > + int verbose; > + nmctx_error_cb error; > + nmctx_malloc_cb malloc; > + nmctx_free_cb free; > + nmctx_lock_cb lock; > + > + struct nmem_d *mem_descs; > +}; > + > +/* nmctx_get - obtain a pointer to the current default context */ > +struct nmctx *nmctx_get(void); > + > +/* nmctx_set_default - change the default context > + * @ctx pointer to the new context > + * > + * Returns a pointer to the previous default context. > + */ > +struct nmctx *nmctx_set_default(struct nmctx *ctx); > + > +/* internal functions and data structures */ > + > +/* struct nmem_d - describes a memory region currently used */ > +struct nmem_d { > + uint16_t mem_id; /* the region netmap identifier */ > + int refcount; /* how many nmport_d's point here */ > + void *mem; /* memory region base address */ > + size_t size; /* memory region size */ > + int is_extmem; /* was it obtained via extmem? */ > + > + /* pointers for the circular list implementation. > + * The list head is the mem_descs filed in the nmctx > + */ > + struct nmem_d *next; > + struct nmem_d *prev; > +}; > + > +/* a trick to force the inclusion of libpthread only if requested. If > + * LIBNETMAP_NOTHREADSAFE is defined, no pthread symbol is imported. > + * > + * There is no need to actually call this function: the ((used)) > attribute is > + * sufficient to include it in the image. > + */ > +static __attribute__((used)) void libnetmap_init(void) > +{ > +#ifndef LIBNETMAP_NOTHREADSAFE > + extern int nmctx_threadsafe; > + /* dummy assignment to link-in the nmctx-pthread.o object. The > proper > + * inizialization is performed only once in the library constructor > + * defined there. > + */ > + nmctx_threadsafe = 1; > +#endif /* LIBNETMAP_NOTHREADSAFE */ > +} > + > +/* nmctx_set_threadsafe - install a threadsafe default context > + * > + * called by the constructor in nmctx-pthread.o to initialize a lock and > install > + * the lock() callback in the default context. > + */ > +void nmctx_set_threadsafe(void); > + > +/* nmctx_ferror - format and send an error message */ > +void nmctx_ferror(struct nmctx *, const char *, ...); > +/* nmctx_malloc - allocate memory */ > +void *nmctx_malloc(struct nmctx *, size_t); > +/* nmctx_free - free memory allocated via nmctx_malloc */ > +void nmctx_free(struct nmctx *, void *); > +/* nmctx_lock - lock the list of nmem_d */ > +void nmctx_lock(struct nmctx *); > +/* nmctx_unlock - unlock the list of nmem_d */ > +void nmctx_unlock(struct nmctx *); > + > +#endif /* LIBNETMAP_H_ */ > > Added: head/lib/libnetmap/nmctx-pthreads.c > > ============================================================================== > --- /dev/null 00:00:00 1970 (empty, because file is newly added) > +++ head/lib/libnetmap/nmctx-pthreads.c Fri Aug 28 20:03:54 2020 > (r364936) > @@ -0,0 +1,47 @@ > +/* $FreeBSD$ */ > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include "libnetmap.h" > + > +struct nmctx_pthread { > + struct nmctx up; > + pthread_mutex_t mutex; > +}; > + > +static struct nmctx_pthread nmctx_pthreadsafe; > + > +static void > +nmctx_pthread_lock(struct nmctx *ctx, int lock) > +{ > + struct nmctx_pthread *ctxp = > + (struct nmctx_pthread *)ctx; > + if (lock) { > + pthread_mutex_lock(&ctxp->mutex); > + } else { > + pthread_mutex_unlock(&ctxp->mutex); > + } > +} > + > +void __attribute__ ((constructor)) > +nmctx_set_threadsafe(void) > +{ > + struct nmctx *old; > + > + pthread_mutex_init(&nmctx_pthreadsafe.mutex, NULL); > + old = nmctx_set_default(&nmctx_pthreadsafe.up); > + nmctx_pthreadsafe.up = *old; > + nmctx_pthreadsafe.up.lock = nmctx_pthread_lock; > +} > + > +int nmctx_threadsafe; > > Added: head/lib/libnetmap/nmctx.c > > ============================================================================== > --- /dev/null 00:00:00 1970 (empty, because file is newly added) > +++ head/lib/libnetmap/nmctx.c Fri Aug 28 20:03:54 2020 (r364936) > @@ -0,0 +1,111 @@ > +/* $FreeBSD$ */ > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#define LIBNETMAP_NOTHREADSAFE > +#include "libnetmap.h" > + > +static void > +nmctx_default_error(struct nmctx *ctx, const char *errmsg) > +{ > + fprintf(stderr, "%s\n", errmsg); > +} > + > +static void * > +nmctx_default_malloc(struct nmctx *ctx, size_t sz) > +{ > + (void)ctx; > + return malloc(sz); > +} > + > +static void > +nmctx_default_free(struct nmctx *ctx, void *p) > +{ > + (void)ctx; > + free(p); > +} > + > +static struct nmctx nmctx_global = { > + .verbose = 1, > + .error = nmctx_default_error, > + .malloc = nmctx_default_malloc, > + .free = nmctx_default_free, > + .lock = NULL, > +}; > + > +static struct nmctx *nmctx_default = &nmctx_global; > + > +struct nmctx * > +nmctx_get(void) > +{ > + return nmctx_default; > +} > + > +struct nmctx * > +nmctx_set_default(struct nmctx *ctx) > +{ > + struct nmctx *old = nmctx_default; > + nmctx_default = ctx; > + return old; > +} > + > +#define MAXERRMSG 1000 > +void > +nmctx_ferror(struct nmctx *ctx, const char *fmt, ...) > +{ > + char errmsg[MAXERRMSG]; > + va_list ap; > + int rv; > + > + if (!ctx->verbose) > + return; > + > + va_start(ap, fmt); > + rv = vsnprintf(errmsg, MAXERRMSG, fmt, ap); > + va_end(ap); > + > + if (rv > 0) { > + if (rv < MAXERRMSG) { > + ctx->error(ctx, errmsg); > + } else { > + ctx->error(ctx, "error message too long"); > + } > + } else { > + ctx->error(ctx, "internal error"); > + } > +} > + > +void * > +nmctx_malloc(struct nmctx *ctx, size_t sz) > +{ > + return ctx->malloc(ctx, sz); > +} > + > +void > +nmctx_free(struct nmctx *ctx, void *p) > +{ > + ctx->free(ctx, p); > +} > + > +void > +nmctx_lock(struct nmctx *ctx) > +{ > + if (ctx->lock != NULL) > + ctx->lock(ctx, 1); > +} > + > +void > +nmctx_unlock(struct nmctx *ctx) > +{ > + if (ctx->lock != NULL) > + ctx->lock(ctx, 0); > +} > > Added: head/lib/libnetmap/nmport.c > > ============================================================================== > --- /dev/null 00:00:00 1970 (empty, because file is newly added) > +++ head/lib/libnetmap/nmport.c Fri Aug 28 20:03:54 2020 (r364936) > @@ -0,0 +1,810 @@ > +/* $FreeBSD$ */ > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#define LIBNETMAP_NOTHREADSAFE > +#include "libnetmap.h" > + > +struct nmport_cleanup_d { > + struct nmport_cleanup_d *next; > + void (*cleanup)(struct nmport_cleanup_d *, struct nmport_d *); > +}; > + > +static void > +nmport_push_cleanup(struct nmport_d *d, struct nmport_cleanup_d *c) > +{ > + c->next = d->clist; > + d->clist = c; > +} > + > +static void > +nmport_pop_cleanup(struct nmport_d *d) > +{ > + struct nmport_cleanup_d *top; > + > + top = d->clist; > + d->clist = d->clist->next; > + (*top->cleanup)(top, d); > + nmctx_free(d->ctx, top); > +} > + > +void nmport_do_cleanup(struct nmport_d *d) > +{ > + while (d->clist != NULL) { > + nmport_pop_cleanup(d); > + } > +} > + > +static struct nmport_d * > +nmport_new_with_ctx(struct nmctx *ctx) > +{ > + struct nmport_d *d; > + > + /* allocate a descriptor */ > + d = nmctx_malloc(ctx, sizeof(*d)); > + if (d == NULL) { > + nmctx_ferror(ctx, "cannot allocate nmport descriptor"); > + goto out; > + } > + memset(d, 0, sizeof(*d)); > + > + nmreq_header_init(&d->hdr, NETMAP_REQ_REGISTER, &d->reg); > + > + d->ctx = ctx; > + d->fd = -1; > + > +out: > + return d; > +} > + > +struct nmport_d * > +nmport_new(void) > +{ > + struct nmctx *ctx = nmctx_get(); > + return nmport_new_with_ctx(ctx); > +} > + > + > +void > +nmport_delete(struct nmport_d *d) > +{ > + nmctx_free(d->ctx, d); > +} > + > +void > +nmport_extmem_cleanup(struct nmport_cleanup_d *c, struct nmport_d *d) > +{ > + (void)c; > + > + if (d->extmem == NULL) > + return; > + > + nmreq_remove_option(&d->hdr, &d->extmem->nro_opt); > + nmctx_free(d->ctx, d->extmem); > + d->extmem = NULL; > +} > + > + > +int > +nmport_extmem(struct nmport_d *d, void *base, size_t size) > +{ > + struct nmctx *ctx = d->ctx; > + struct nmport_cleanup_d *clnup = NULL; > + > + if (d->register_done) { > + nmctx_ferror(ctx, "%s: cannot set extmem of an already > registered port", d->hdr.nr_name); > + errno = EINVAL; > + return -1; > + } > + > + if (d->extmem != NULL) { > + nmctx_ferror(ctx, "%s: extmem already in use", > d->hdr.nr_name); > + errno = EINVAL; > + return -1; > + } > + > + clnup = (struct nmport_cleanup_d *)nmctx_malloc(ctx, > sizeof(*clnup)); > + if (clnup == NULL) { > + nmctx_ferror(ctx, "failed to allocate cleanup descriptor"); > + errno = ENOMEM; > + return -1; > + } > + > + d->extmem = nmctx_malloc(ctx, sizeof(*d->extmem)); > + if (d->extmem == NULL) { > + nmctx_ferror(ctx, "%s: cannot allocate extmem option", > d->hdr.nr_name); > + nmctx_free(ctx, clnup); > + errno = ENOMEM; > + return -1; > + } > + memset(d->extmem, 0, sizeof(*d->extmem)); > + d->extmem->nro_usrptr = (uintptr_t)base; > + d->extmem->nro_opt.nro_reqtype = NETMAP_REQ_OPT_EXTMEM; > + d->extmem->nro_info.nr_memsize = size; > + nmreq_push_option(&d->hdr, &d->extmem->nro_opt); > + > + clnup->cleanup = nmport_extmem_cleanup; > + nmport_push_cleanup(d, clnup); > + > + return 0; > +} > + > > *** DIFF OUTPUT TRUNCATED AT 1000 LINES *** > From owner-freebsd-current@freebsd.org Sun Sep 20 22:07: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 ED9173F3831; Sun, 20 Sep 2020 22:07:58 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qk1-f177.google.com (mail-qk1-f177.google.com [209.85.222.177]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4BvhXF37xYz4c6X; Sun, 20 Sep 2020 22:07:57 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-qk1-f177.google.com with SMTP id d20so13112299qka.5; Sun, 20 Sep 2020 15:07:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=f2hLBm1lKyRaOQPLtVD4G9y8mKiSxUdgOuYCoQ/Zz+s=; b=bVqkdhWpxjT7aEJdH7LuDadMBESX6p+R+s8CRuCENZi1qwDetAFH6zthU5VWJ9NXHh SVBgqXThcXWT4h6HtHRl50zG8iQ6IVxvr5ZAx6zcXMuB0JX+2XdOcvzvNumfrmtRFrEH qbOD1ceMwFXmLy3hMibwLq9Yp0sD930RHCivYdPsf15pUlscQSA9QRFmkDQe3A1VdNuX k+mRx/mZkybGM6BbzO7IfEZvCzd7yk+RqXAtKzRTnW7G0b61vIUEiKzf5vHkhmjA+lFZ WNEkNev/FFImtXYgk5hSz9dg2acg2c5BfQWZryA3butvCE/DGqxwddNNcnF0W8jOcGi1 OOVA== X-Gm-Message-State: AOAM531EOoNhSnd6NhNjwGkpTOGrT2OwFR7gb41sHZ6F/szPoWx5VBGe vn5XxjJprHkoAVTJ6ODbdse8whnvMGpZip4PAIxN5d43zjOiSA== X-Google-Smtp-Source: ABdhPJwIQBfeWQFmRwG4S+iA+LD0tYF+A2qbidSVNxpVC8+WJEzINyjFHMfBETnqGtQZJfLvgRQ9kDZPu9gz5rqPmWA= X-Received: by 2002:a37:96c7:: with SMTP id y190mr489712qkd.152.1600639674952; Sun, 20 Sep 2020 15:07:54 -0700 (PDT) MIME-Version: 1.0 From: Adrian Chadd Date: Sun, 20 Sep 2020 15:07:43 -0700 Message-ID: Subject: mips32 + gcc9 -- still broken To: freebsd-current , "freebsd-mips@freebsd.org" X-Rspamd-Queue-Id: 4BvhXF37xYz4c6X X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.46 / 15.00]; FROM_NEQ_ENVFROM(0.00)[adrian@freebsd.org,adrianchadd@gmail.com]; MAILMAN_DEST(0.00)[freebsd-current,freebsd-mips]; TO_DN_EQ_ADDR_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; ARC_NA(0.00)[]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-1.01)[-1.011]; NEURAL_HAM_MEDIUM(-0.98)[-0.984]; NEURAL_HAM_SHORT(-0.47)[-0.469]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[209.85.222.177:from]; FORGED_SENDER(0.30)[adrian@freebsd.org,adrianchadd@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.222.177:from]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 20 Sep 2020 22:07:59 -0000 hi! So mips32 and gcc9 is broken, and things have been broken with mips32+gcc for months now. I've been poking slowly at the various build failures and they're getting slowly fixed, but this one deep in linker fun is stumping me: === /usr/local/bin/mips-unknown-freebsd13.0-gcc9 --sysroot=/usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp -B/usr/local/mips-unknown-freebsd13.0/bin/ -O -pipe -fno-common -DATJOB_DIR=\"/var/at/jobs/\" -DLFILE=\"/var/at/jobs/.lockfile\" -DLOADAVG_MX=1.5 -DATSPOOL_DIR=\"/var/at/spool\" -DDAEMON_UID=1 -DDAEMON_GID=1 -DDEFAULT_BATCH_QUEUE=\'E\' -DDEFAULT_AT_QUEUE=\'c\' -DPERM_PATH=\"/var/at/\" -I/usr/home/adrian/work/freebsd/head-embedded/src/usr.bin/at -I/usr/home/adrian/work/freebsd/head-embedded/src/libexec/atrun -DLOGIN_CAP -DPAM -G0 -EB -mabi=32 -msoft-float -march=mips32 -g -std=gnu99 -Wno-format-zero-length -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-error=address -Wno-error=array-bounds -Wno-error=attributes -Wno-error=bool-compare -Wno-error=cast-align -Wno-error=clobbered -Wno-error=deprecated-declarations -Wno-error=enum-compare -Wno-error=extra -Wno-error=inline -Wno-error=logical-not-parentheses -Wno-error=strict-aliasing -Wno-error=uninitialized -Wno-error=unused-but-set-variable -Wno-error=unused-function -Wno-error=unused-value -Wno-error=empty-body -Wno-error=maybe-uninitialized -Wno-error=nonnull-compare -Wno-error=redundant-decls -Wno-error=shift-negative-value -Wno-error=tautological-compare -Wno-error=unused-const-variable -Wno-error=bool-operation -Wno-error=deprecated -Wno-error=expansion-to-defined -Wno-error=format-overflow -Wno-error=format-truncation -Wno-error=implicit-fallthrough -Wno-error=int-in-bool-context -Wno-error=memset-elt-size -Wno-error=noexcept-type -Wno-error=nonnull -Wno-error=pointer-compare -Wno-error=stringop-overflow -Wno-error=aggressive-loop-optimizations -Wno-error=cast-function-type -Wno-error=catch-value -Wno-error=multistatement-macros -Wno-error=restrict -Wno-error=sizeof-pointer-memaccess -Wno-error=stringop-truncation -Wno-error=empty-body -Wno-error=overflow -Wno-address-of-packed-member -EB -mabi=32 -o atrun.full atrun.o gloadavg.o -lpam -lutil /usr/local/bin/mips-unknown-freebsd13.0-ld: /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp/usr/lib/crt1.o: in function `__start': /usr/home/adrian/work/freebsd/head-embedded/src/lib/csu/mips/crt1_c.c:76: undefined reference to `_init_tls' /usr/local/bin/mips-unknown-freebsd13.0-ld: /usr/home/adrian/work/freebsd/head-embedded/src/lib/csu/mips/crt1_c.c:76: undefined reference to `_init_tls' /usr/local/bin/mips-unknown-freebsd13.0-ld: atrun.o: in function `perr': /usr/home/adrian/work/freebsd/head-embedded/src/libexec/atrun/atrun.c:417: undefined reference to `vsyslog' /usr/local/bin/mips-unknown-freebsd13.0-ld: /usr/home/adrian/work/freebsd/head-embedded/src/libexec/atrun/atrun.c:417: undefined reference to `vsyslog' /usr/local/bin/mips-unknown-freebsd13.0-ld: atrun.o: in function `perrx': /usr/home/adrian/work/freebsd/head-embedded/src/libexec/atrun/atrun.c:433: undefined reference to `vsyslog' /usr/local/bin/mips-unknown-freebsd13.0-ld: /usr/home/adrian/work/freebsd/head-embedded/src/libexec/atrun/atrun.c:433: undefined reference to `vsyslog' /usr/local/bin/mips-unknown-freebsd13.0-ld: atrun.o: in function `run_file': /usr/home/adrian/work/freebsd/head-embedded/src/libexec/atrun/atrun.c:348: undefined reference to `waitpid' /usr/local/bin/mips-unknown-freebsd13.0-ld: /usr/home/adrian/work/freebsd/head-embedded/src/libexec/atrun/atrun.c:348: undefined reference to `waitpid' /usr/local/bin/mips-unknown-freebsd13.0-ld: atrun.o: in function `main': /usr/home/adrian/work/freebsd/head-embedded/src/libexec/atrun/atrun.c:478: undefined reference to `openlog' /usr/local/bin/mips-unknown-freebsd13.0-ld: /usr/home/adrian/work/freebsd/head-embedded/src/libexec/atrun/atrun.c:478: undefined reference to `openlog' /usr/local/bin/mips-unknown-freebsd13.0-ld: atrun.o: in function `usage': /usr/home/adrian/work/freebsd/head-embedded/src/libexec/atrun/atrun.c:590: undefined reference to `syslog' /usr/local/bin/mips-unknown-freebsd13.0-ld: /usr/home/adrian/work/freebsd/head-embedded/src/libexec/atrun/atrun.c:590: undefined reference to `syslog' /usr/local/bin/mips-unknown-freebsd13.0-ld: atrun.o: in function `main': /usr/home/adrian/work/freebsd/head-embedded/src/libexec/atrun/atrun.c:532: undefined reference to `time' /usr/local/bin/mips-unknown-freebsd13.0-ld: /usr/home/adrian/work/freebsd/head-embedded/src/libexec/atrun/atrun.c:532: undefined reference to `time' /usr/local/bin/mips-unknown-freebsd13.0-ld: /usr/home/adrian/work/freebsd/head-embedded/src/libexec/atrun/atrun.c:510: undefined reference to `sysctlbyname' /usr/local/bin/mips-unknown-freebsd13.0-ld: /usr/home/adrian/work/freebsd/head-embedded/src/libexec/atrun/atrun.c:510: undefined reference to `sysctlbyname' /usr/local/bin/mips-unknown-freebsd13.0-ld: /usr/home/adrian/work/freebsd/head-embedded/src/libexec/atrun/atrun.c:577: undefined reference to `closelog' /usr/local/bin/mips-unknown-freebsd13.0-ld: /usr/home/adrian/work/freebsd/head-embedded/src/libexec/atrun/atrun.c:580: undefined reference to `closelog' /usr/local/bin/mips-unknown-freebsd13.0-ld: /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp/lib/libc.so.7: undefined reference to `sys_nsig' /usr/local/bin/mips-unknown-freebsd13.0-ld: /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp/lib/libc.so.7: undefined reference to `futx_to_utx' /usr/local/bin/mips-unknown-freebsd13.0-ld: /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp/lib/libc.so.7: undefined reference to `_waitpid' /usr/local/bin/mips-unknown-freebsd13.0-ld: /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp/usr/lib/libpam.so: undefined reference to `sigfillset' /usr/local/bin/mips-unknown-freebsd13.0-ld: /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp/lib/libc.so.7: undefined reference to `_fixtelldir' /usr/local/bin/mips-unknown-freebsd13.0-ld: /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp/usr/lib/libpam.so: undefined reference to `sysconf' /usr/local/bin/mips-unknown-freebsd13.0-ld: /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp/lib/libc.so.7: undefined reference to `_reclaim_telldir' /usr/local/bin/mips-unknown-freebsd13.0-ld: /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp/lib/libc.so.7: undefined reference to `sigismember' /usr/local/bin/mips-unknown-freebsd13.0-ld: /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp/lib/libc.so.7: undefined reference to `sl_init' /usr/local/bin/mips-unknown-freebsd13.0-ld: /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp/lib/libc.so.7: undefined reference to `sysctlnametomib' /usr/local/bin/mips-unknown-freebsd13.0-ld: /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp/lib/libc.so.7: undefined reference to `utx_to_futx' /usr/local/bin/mips-unknown-freebsd13.0-ld: /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp/lib/libc.so.7: undefined reference to `sigdelset' /usr/local/bin/mips-unknown-freebsd13.0-ld: /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp/lib/libc.so.7: undefined reference to `sl_add' /usr/local/bin/mips-unknown-freebsd13.0-ld: /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp/lib/libc.so.7: undefined reference to `sl_free' /usr/local/bin/mips-unknown-freebsd13.0-ld: /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp/usr/lib/libutil.so: undefined reference to `tcsetsid' /usr/local/bin/mips-unknown-freebsd13.0-ld: /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp/usr/lib/libpam.so: undefined reference to `tcsetattr' /usr/local/bin/mips-unknown-freebsd13.0-ld: /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp/usr/lib/libutil.so: undefined reference to `sigaddset' /usr/local/bin/mips-unknown-freebsd13.0-ld: /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp/lib/libc.so.7: undefined reference to `sys_siglist' /usr/local/bin/mips-unknown-freebsd13.0-ld: /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp/usr/lib/libutil.so: undefined reference to `sysctl' /usr/local/bin/mips-unknown-freebsd13.0-ld: /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp/usr/lib/libutil.so: undefined reference to `sigemptyset' /usr/local/bin/mips-unknown-freebsd13.0-ld: /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp/lib/libc.so.7: undefined reference to `__libc_tcdrain' /usr/local/bin/mips-unknown-freebsd13.0-ld: /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp/usr/lib/libutil.so: undefined reference to `sleep' /usr/local/bin/mips-unknown-freebsd13.0-ld: /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp/lib/libc.so.7: undefined reference to `signal' /usr/local/bin/mips-unknown-freebsd13.0-ld: /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp/lib/libc.so.7: undefined reference to `__tls_get_addr' /usr/local/bin/mips-unknown-freebsd13.0-ld: /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp/usr/lib/libpam.so: undefined reference to `tcgetattr' /usr/local/bin/mips-unknown-freebsd13.0-ld: /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp/lib/libc.so.7: undefined reference to `longjmperror' collect2: error: ld returned 1 exit status *** Error code 1 Stop. make[2]: stopped in /usr/home/adrian/work/freebsd/head-embedded/src/libexec/atrun $ === I only get a few hours a weekend and a couple hours each night to poke at FreeBSD stuff, and I'd /really like/ to be focusing on MIPS fixes and WiFi work. I'd appreciate some help in figuring out who broke what and getting it fixed. Thanks! -adrian From owner-freebsd-current@freebsd.org Sun Sep 20 22:37: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 4A2023F41A4 for ; Sun, 20 Sep 2020 22:37:39 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670072.outbound.protection.outlook.com [40.107.67.72]) (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 4BvjBV2VKQz4dbF for ; Sun, 20 Sep 2020 22:37:37 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CY4jc1mlHkbfWSHnvrWVI5ZICqXjZ/wt6A8sR80acVo0qbnRrFVh3YxOg+aE8Y5bAgBtWdq3tB7TxtJoZQafgXQCQS/di2HTr3CgS36kHlW6f3zwotFEpmVYVndWvUVk18DrocD+6s3BccvKEI8WRScy5hOpvCI+XoGory5GuCf50jm474mi7E1mKJhaVlzYmnb2fsl8oy0zEocLOIhPajHvjRO5UIsOFcxxLWtZsD+3Whz6lKctEjpjXeLC3ox7dSHQHDrsbTjGsGSz85lJM/QVR9vf2JGtklImfyW9x7Y1GPJtLQhTwRljgdoWyxY6v9Vku+rlABEYcxHQajyLgA== 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=y8+jwCFXfAfTGaFqN8f87VOI0NQzgo2P0lropZqKfzc=; b=XNNh9N4c9ut2468VjlOWV5mE8D+wlB0uJaZkfeHbVDGXAlkxT0UYjYBAQ4G6rG6DZKmQRfT0uGEnplVPa79KQtIOxFLVfMK/QMztNEz6DM1s56lMBU/IbZHzoHEpfajSGuFcTIt8vNiPNj8tgrGvrjtvb67WXG/Xp2lkCA0BDyb25sqfQmF1nFMIFBxE5ci0d3dnFGckNpCiHijilh0XwmKQVXfgWo4JiEgIbZ4ihgdHm6aJtFUEHrhdhogrQUdaOcJlYo9nwG2b6J9gtVDyP2/9Rt8u/jmQmXztzKz9D9uHGVm7U4cl5Yyig5z4AGsL6GCUa2d7HOJ4kQM5BMwWFA== 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 YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:24::27) by YT1PR01MB2427.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:4::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.15; Sun, 20 Sep 2020 22:37:35 +0000 Received: from YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM ([fe80::687f:d85a:a0a3:bd20]) by YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM ([fe80::687f:d85a:a0a3:bd20%6]) with mapi id 15.20.3391.024; Sun, 20 Sep 2020 22:37:35 +0000 From: Rick Macklem To: Christian Weisgerber , "freebsd-current@freebsd.org" Subject: Re: Plans for git Thread-Topic: Plans for git Thread-Index: AQHWj18oRIlu1/OfAECJ/cABXAec5qlyGhtX Date: Sun, 20 Sep 2020 22:37:35 +0000 Message-ID: References: <20200902045939.GA15897@eureka.lemis.com> <20200902060117.GG53210@home.opsec.eu> <20200902063136.GA47543@troutmask.apl.washington.edu> <20200902164706.GA49777@troutmask.apl.washington.edu> <5c89b4d27281f5dfffc3252a90013b0ac6c763d7.camel@freebsd.org> <5c832482-b2bc-47e4-8762-8f5a886d5f11@www.fastmail.com> <68585ca4-5ca4-40d3-b2f4-67ff3b35b6ae@www.fastmail.com> <0be2ae57d1c58e2091f4cc4484731df0@bsdforge.com> <967D73EA-880E-413D-B748-62A406C46524@FreeBSD.org> <9f89dc553e7d7b0884c2862329bdfeae@bsdforge.com> , 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: e43620cb-6dd2-4a3f-24e3-08d85db5c555 x-ms-traffictypediagnostic: YT1PR01MB2427: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: OfkF0wnjcJah5lEsimaUpopYkjpQm+1tmGrgWBnEmRTDI7rBLoEZmwbdB64HxGGLuyMnEFvQtxAe0083Nyay/KA15IKijfW1mJRxyESn5WQBFAOO2w8aahJ2UV21a9V7kpg9dp+O1C7y0ewMz+wxU0NrTVOph9FeC/ZF64iD6Va+0NHz6k3a6C6E2rt4noQIT89YFAai5cbfgFfUOZzuac835tWhGKZ00iO/nTX18eL2cQ68Z7lPWABrAy8nV2gJ+zSEIqmtYUW0SR6OMGpqY8spt5UAXyJ9IIgsRMkRzO5x03f0s2sOHgndKPvOLoG0VlGezB7qvk5QqTn6FkIt1n7boGZvUIiY2aMN1yAILC98PmpEScCWGPHHZ/ToQaPehlV2UsDScFgPtNSoKco0A2KTeBXjG1y28JJjLOsihcFpSgsNzKH2/mcTYZ03yiUXmiFeOCfLXPo/5WU/iEkKng== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(396003)(39850400004)(136003)(366004)(346002)(376002)(66446008)(66476007)(83380400001)(7696005)(110136005)(186003)(33656002)(6506007)(3480700007)(71200400001)(9686003)(55016002)(7116003)(5660300002)(52536014)(66946007)(8676002)(8936002)(786003)(316002)(64756008)(86362001)(478600001)(91956017)(2906002)(76116006)(966005)(66556008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 3UB3F54z7UfQZMjmpohM4Gq5bAC4dIboXemiWfXl13TrFgYGfy9yu7/rpIJ+F9zSQVkIogd5hf4PF/cOeFNVfkhFjptQVeutEiQeNm1lR24MYIBmhgKAmhpHeLaQmqS98LhLs8WuafitAhBOISV28Cn1uk/OeuXeTMjCaUnj8MwW539GsEWFLEDngPfE/pj+Xp/GTdjBy7S5XhgBMgVnkaUdJIIq1hg7miGjxwc7JQFG2e2TweV9lu4fQ78Kxp8jxv9mSehvSdeunI6g2EuaHrgSTa7kdXg6PDJF3CyGyV986Y2deXqDRPBBYVE5tqLnxiv68QfIs/YVrMfDPG5qNwajyXWYCF3zMKEfwgoTySwQCTgET3LfNrUWaDIC7wfS4aPgtKIiEQx0yRRKrxGuE4goDujuCQhcvz1njzHOl3tGPHQIayvbhJoZVZnrUJl4CkAdUiDKf8AHYDWW4Xu8/bwbHj3Pd7N9oCEk/4uP5Z5g5YZa7Hw5M1g1UflbLsG9q3U9jIpnwVdWX0BOetrZBYGrVDznWl8PRawCcTIYE2/UhwPcoM06EANWzJCWHpmI9HR07o2o2ozeXQX9f5kKj5qPtn8R6pkq1adBIHO61OA1s18BmfhRDpeFejmXiS/341ayqrmDXyr8I6KYJ4R8G9qPVllJEB6VukDGBlQnyj2GiWNO7Vwl7UEcXTJw2ayBolP+JPyt0zHsddu6KfzHIA== 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-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: e43620cb-6dd2-4a3f-24e3-08d85db5c555 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Sep 2020 22:37:35.2631 (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: 909JlsM6pK2D/6SZDR9m0fKB3XFa3CULuD5GfhX18w42efRme1ieHGCHjfgQ1sX08+uFcf8/L3stwYHx5D/f3w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YT1PR01MB2427 X-Rspamd-Queue-Id: 4BvjBV2VKQz4dbF X-Spamd-Bar: ------ X-Spamd-Result: default: False [-6.37 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.985]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector1]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; NEURAL_HAM_LONG(-1.03)[-1.026]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[uoguelph.ca:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; NEURAL_HAM_SHORT(-1.26)[-1.258]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.67.72:from]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; MAILMAN_DEST(0.00)[freebsd-current]; RCVD_IN_DNSWL_LOW(-0.10)[40.107.67.72:from] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 20 Sep 2020 22:37:39 -0000 Christian Weisgerber wrote:=0A= > On 2020-09-19, Zaphod Beeblebrox wrote:=0A= > =0A= > > Hrm. Maybe what I hear others saying, tho, and not entirely being repl= ied=0A= > > to is just a nice concise document of the why. What I hear you saying = is=0A= > > that GIT has momentum and that it's popular... (and I accept that --- i= t is=0A= > > evidently true), but then I hear handwaving about features, but no list= of=0A= > > features that are a clear win/loose.=0A= >=0A= > How about the very basics (that Warner appears to have lost sight=0A= > of)?=0A= >=0A= > Git is a distributed version control system. You clone a repository=0A= > and apart from pulling and pushing changes to another repository,=0A= > all your work happens with the local repository. Subversion has a=0A= > central repository and needs to talk to the server all the time.=0A= > Laptop on a plane? No change of workflow with Git.=0A= Well, I (mostly lurk) on the linux-nfs@vger.kernels.org mailing list,=0A= where the Linux NFS work gets done.=0A= What I see is the following, when someone has an enhancement/change=0A= for the Linux NFS code.=0A= Do I see one diff with all the changes in it...No.=0A= I see anywhere from a few to over 50 email messages, each with=0A= one little piece of the pie, out of git.=0A= =0A= I have no idea how they review this stuff.=0A= If I were stuck doing it, I'd end up creating an unpatched tree, copying it= =0A= and applying all the patches to the copy and then creating a single diff=0A= to look at in phabricator, which does display the changes very nicely.=0A= =0A= So, I hope that a transition to git does not encourage "lots of small=0A= loosely related commits" to the FreeBSD repository.=0A= =0A= Also, I find svnweb useful, mostly to look at the commits done to a=0A= file in temporal (most recent first) order. The global serial revision=0A= number is very nice, but so long as it is easy to see the temporal=0A= ordering of changes, I can live with that.=0A= =0A= > And since it's your repository, you can cheaply create your own=0A= > branches, where you can commit your work and have a versioned history=0A= > of it instead of just a flat diff. I can't overstate the value of=0A= > that. Whether you work on something that will be pushed back=0A= > upstream or just your private changes, it has a full commit history.=0A= I, on the other hand, will have no use for this. I can easily keep track of= =0A= changes I do by naming file.sav, file.sav2,...=0A= I like to carefully merge changes into the repository checkout after I've= =0A= tested them, taking a careful look at the changes as I go.=0A= I find most of the subtle bugs (that wouldn't be detected during normal=0A= testing) during this "code inspection".=0A= --> I think anything that encourages another look at the change before=0A= commit is a good thing.=0A= Put another way, slow and careful is better than quick and easy, imho= .=0A= =0A= I've live with the transition, but to be honest, I know it won't make my=0A= work better or easier, rick=0A= =0A= You can easily revert commits, you can upstream it one by one, you=0A= can upstream it with history.=0A= =0A= When FreeBSD switched from CVS to SVN, there was hope or promise=0A= of lightweight branches, but that never materialized. Developers=0A= still can't have private branches in the FreeBSD repository. For=0A= a while, a lot of development happened in a Perforce repository--a=0A= commerical version control system, whose company had donated a=0A= license--which offered this feature. Nowadays, everybody who does=0A= any but the most trivial development does so in a private Git=0A= repository anyway. It only makes sense to interface this directly=0A= with the FreeBSD repository instead of going through a SVN<>Git=0A= media break.=0A= =0A= > Certainly the only clear things a quick search turns up that seem relevan= t=0A= > is that GIT is GPL2.0 and SVN is Apache2.0. This was enough for LLVM vs= =0A= > GCC and the repository is a core function, but I suppose not a necessary= =0A= > function for forked projects that can't abide, so...=0A= =0A= There is a bit of historical precedent: The original BSD work at=0A= Berkeley was kept in a SCCS repository, a proprietary version control=0A= system at the time.=0A= =0A= And of course the fact that significant FreeBSD development has=0A= effectively happened in Perforce, then in Git for a long time and=0A= is just merged back into the Subversion repository. To put it=0A= bluntly, the people doing the work have voted with their feet years=0A= ago.=0A= =0A= --=0A= Christian "naddy" Weisgerber naddy@mips.inka.de=0A= _______________________________________________=0A= freebsd-current@freebsd.org mailing list=0A= https://lists.freebsd.org/mailman/listinfo/freebsd-current=0A= To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"= =0A= =0A= From owner-freebsd-current@freebsd.org Sun Sep 20 23:34:22 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 C988A3F564D for ; Sun, 20 Sep 2020 23:34:22 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qk1-f169.google.com (mail-qk1-f169.google.com [209.85.222.169]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4BvkRx6XLYz4hGJ for ; Sun, 20 Sep 2020 23:34:21 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-qk1-f169.google.com with SMTP id t138so13276093qka.0 for ; Sun, 20 Sep 2020 16:34:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1d3rSWIPL1a0x9dq6t7TNkgSDC/OWv2iHfaZf+S45ow=; b=X8KzqUTCkboKLjZshAiziUsJkbveXY2+jE7oXA+iP5MKa1iyUGNhOXiAbftP806+B1 L9hOslNhrpDJ4mAuWAq1Z8XqM60qgOf6dQdELB8UHvijgEphx22q3mmRtgtsUW3WK4xB 53/QUjxAe0nH+3H0BqBb7g7OWR9IGZn9qfkWN4S7k8+S5h0i7jV0OT6XWj5Z45Hw1lc+ Z6pbEsS3VzMmeMXM8x3x6WrM/ZmUy6MMjkey7I00x/HJuSnvmf8Td+XchoexoB2nPOJr LI/nVYK8+8oZ7Wt3uU2jeQpHJIz7IxaueSwg6YZhecBIiO4EKhz7qQA4rEYmkc3noQK/ cAUA== X-Gm-Message-State: AOAM5318AfKGB2XhpdnCEsYpKkjTm5qV3ItqgoRlB8XVPzn9+NoHXWI5 +Ch69bWjcRY4GSDAHl7z/3uaVf5+L3qe+6rZm9I= X-Google-Smtp-Source: ABdhPJy/tYEJz59USpGpfdUC7cfe+l2g/fTBBYL1bPBcsjDPIVLxyQTdwSoVEpGPc1UTbErTAgAmpZyKL3C70H0HIsY= X-Received: by 2002:a37:67d2:: with SMTP id b201mr42397783qkc.96.1600644860866; Sun, 20 Sep 2020 16:34:20 -0700 (PDT) MIME-Version: 1.0 References: <20200902045939.GA15897@eureka.lemis.com> <20200902060117.GG53210@home.opsec.eu> <20200902063136.GA47543@troutmask.apl.washington.edu> <20200902164706.GA49777@troutmask.apl.washington.edu> <5c89b4d27281f5dfffc3252a90013b0ac6c763d7.camel@freebsd.org> <5c832482-b2bc-47e4-8762-8f5a886d5f11@www.fastmail.com> <68585ca4-5ca4-40d3-b2f4-67ff3b35b6ae@www.fastmail.com> <0be2ae57d1c58e2091f4cc4484731df0@bsdforge.com> <967D73EA-880E-413D-B748-62A406C46524@FreeBSD.org> <9f89dc553e7d7b0884c2862329bdfeae@bsdforge.com> In-Reply-To: From: Adrian Chadd Date: Sun, 20 Sep 2020 16:34:06 -0700 Message-ID: Subject: Re: Plans for git To: Rick Macklem Cc: Christian Weisgerber , "freebsd-current@freebsd.org" X-Rspamd-Queue-Id: 4BvkRx6XLYz4hGJ X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.27 / 15.00]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2]; TO_DN_EQ_ADDR_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; RCVD_TLS_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.02)[-1.015]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.27)[-1.266]; RCVD_IN_DNSWL_NONE(0.00)[209.85.222.169:from]; NEURAL_HAM_MEDIUM(-0.99)[-0.993]; FORGED_SENDER(0.30)[adrian@freebsd.org,adrianchadd@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.222.169:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; TAGGED_FROM(0.00)[]; FROM_NEQ_ENVFROM(0.00)[adrian@freebsd.org,adrianchadd@gmail.com]; MAILMAN_DEST(0.00)[freebsd-current] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 20 Sep 2020 23:34:22 -0000 On Sun, 20 Sep 2020 at 15:37, Rick Macklem wrote: > Christian Weisgerber wrote: > > On 2020-09-19, Zaphod Beeblebrox wrote: > > > > > Hrm. Maybe what I hear others saying, tho, and not entirely being > replied > > > to is just a nice concise document of the why. What I hear you saying > is > > > that GIT has momentum and that it's popular... (and I accept that --- > it is > > > evidently true), but then I hear handwaving about features, but no > list of > > > features that are a clear win/loose. > > > > How about the very basics (that Warner appears to have lost sight > > of)? > > > > Git is a distributed version control system. You clone a repository > > and apart from pulling and pushing changes to another repository, > > all your work happens with the local repository. Subversion has a > > central repository and needs to talk to the server all the time. > > Laptop on a plane? No change of workflow with Git. > Well, I (mostly lurk) on the linux-nfs@vger.kernels.org mailing list, > where the Linux NFS work gets done. > What I see is the following, when someone has an enhancement/change > for the Linux NFS code. > Do I see one diff with all the changes in it...No. > I see anywhere from a few to over 50 email messages, each with > one little piece of the pie, out of git. > > I have no idea how they review this stuff. > It's done in patchwork.kernel.org. This takes the contents of very specifically correctly formatted git-email contents and wraps up the series as something that can be assigned to patchwork users for review/feedback. All of it goes in and out of email. It's basically using the public Linux email lists as part discussion and part RPC between everyones' git repositories. I think this stuff predates github, where there's a much nicer web flow for doing stuff like this. The linux model works great in a world where you're /truely/ decentralised. I bet that 99% of git users use some web frontend that's integrated into CI and patch review. HTH, -adrian From owner-freebsd-current@freebsd.org Mon Sep 21 00:53: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 11CA73E0798 for ; Mon, 21 Sep 2020 00:53:05 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4BvmBl4WNxz4mTn for ; Mon, 21 Sep 2020 00:53:03 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-il1-x12f.google.com with SMTP id t12so12096333ilh.3 for ; Sun, 20 Sep 2020 17:53:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=rRZwS2PxkFgvhhNTzrdfnUDOeQY8RHR8p0m69FWlo2A=; b=gF5G/aolpo/OxDHavwEf02Iqy7nQNmL+tYO9LQS9Ssfo+fKjoKsu2H0O5LEmcdbb0E OYiI5nhqbPDnEXQi5nqLZelxM93IcycpGF7BVYO1TUL9+aP/+Sc1J9diFvpiECNetM+c 9k58Zd6RH5431iOhfBRkWL5q+10/MsN7bPrL8xnhFR9SxwB+Rj/p5cWnuC9qwMxeUBdC 2a7s1QotG2NFL3tgdOSY4H5qfw7GI49pD905jaYW/TLBYwXQARJB2d5jvLCL2SfCH9No kFwwVE6JtrOd2AqXfPJhCoRDHYI7iRkqyOjTx5EjnqfgFcTfgMNYqVcRROesiByvpACg eSnQ== X-Gm-Message-State: AOAM532Vpw4bB1jjomLKZztP41aq3y6xnPNRNNYFLbJrzmXkmmC8++yC Mb0jpJnHyF0wDrSDnwjUKOHLw62KLRvaUMVMaBpT1tnQnGLbPg== X-Google-Smtp-Source: ABdhPJzfpNFlsPNzd4dUIc9/OTmBJ0UXgpkdSSGfeggJ5u4ygYmA6Z1UqiJLK3ScTH+ZcE/jhVmWxpUhg6m/S0eBYlc= X-Received: by 2002:a92:105:: with SMTP id 5mr36008665ilb.36.1600649581260; Sun, 20 Sep 2020 17:53:01 -0700 (PDT) MIME-Version: 1.0 From: Shawn Webb Date: Mon, 21 Sep 2020 00:52:50 +0000 Message-ID: Subject: iflib/bridge kernel panic To: FreeBSD Current X-Rspamd-Queue-Id: 4BvmBl4WNxz4mTn X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.15 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.97)[-0.974]; R_DKIM_ALLOW(-0.20)[hardenedbsd.org:s=google]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[hardenedbsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.04)[-1.035]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[hardenedbsd.org:+]; NEURAL_HAM_SHORT(-0.64)[-0.642]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::12f:from]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 21 Sep 2020 00:53:05 -0000 >From latest HEAD on a Dell Precision 7550 laptop: https://gist.github.com/lattera/a0803f31f58bcf8ead51ac1ebbc447e2 The last working boot environment was 14 Aug 2020. If I get some time to bisect commits, I'll try to figure out the culprit. Thanks, Shawn Webb (Sorry for the brevity. Only partially working system due to above breakage.) From owner-freebsd-current@freebsd.org Mon Sep 21 01:16: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 647133E1993 for ; Mon, 21 Sep 2020 01:16:35 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-oi1-f171.google.com (mail-oi1-f171.google.com [209.85.167.171]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4Bvmjt2Yvyz4nr4 for ; Mon, 21 Sep 2020 01:16:34 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-oi1-f171.google.com with SMTP id 26so6721370ois.5 for ; Sun, 20 Sep 2020 18:16:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=TJXM5jw+d1dDL+cDHBCB3QbIzhrMIicF0A0Lx5hBnmg=; b=sCTrhOEMC+wdoYf4Z6aQG0MNpy/JQNTM7nrTdZd81K3E8pEF9Jmw0fZqcVJiRLRD2F EAiwrNeli+lQnz3vJ5Ke8YNG4WHFtq+oXT4LiRNop1iEOWdtPCweFTOTRLlN38jSnAfq e8/nOopEzswC50uBqvCyN9t+QBQXPmalufI1DSD/2OTcwrD/JcNWgoia2+xA6e4urCu9 +FkxCjHxy/fMo1p/wo0y5SUMi2p4HzUpTs5943/V9RPG+OCLmxIGzxSd+dvL5TereVof 56yowHL9MDOkkBrbjbX6ltSlOnvClg+wxJ7oO0P88w+o7wMoZSy32Us/UDrF4PPHViHS Itow== X-Gm-Message-State: AOAM531nzsfNvsAmyqsZAlOTqJnb1SSZ0pTJ10M6xL2H8KmX5xo3ct0A Kf14T+E9ZqGYnIYQJWP5vYdHWEfIBCU= X-Google-Smtp-Source: ABdhPJxBML6sH8puYVJfHZtlNgozsZ5qycqmwiJlsDrpiq9qu8wzLIJ+Sja0trZdIekZCKWipIKFCA== X-Received: by 2002:aca:1311:: with SMTP id e17mr15299918oii.43.1600650993019; Sun, 20 Sep 2020 18:16:33 -0700 (PDT) Received: from mail-oi1-f179.google.com (mail-oi1-f179.google.com. [209.85.167.179]) by smtp.gmail.com with ESMTPSA id f194sm6437587oib.44.2020.09.20.18.16.32 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 20 Sep 2020 18:16:32 -0700 (PDT) Received: by mail-oi1-f179.google.com with SMTP id u126so15061014oif.13 for ; Sun, 20 Sep 2020 18:16:32 -0700 (PDT) X-Received: by 2002:aca:843:: with SMTP id 64mr16392417oii.135.1600650992309; Sun, 20 Sep 2020 18:16:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Reply-To: cem@freebsd.org From: Conrad Meyer Date: Sun, 20 Sep 2020 18:16:21 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: iflib/bridge kernel panic To: Shawn Webb Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4Bvmjt2Yvyz4nr4 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.97 / 15.00]; HAS_REPLYTO(0.00)[cem@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; 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)[]; NEURAL_HAM_SHORT(-0.96)[-0.958]; RCPT_COUNT_TWO(0.00)[2]; FORGED_SENDER(0.30)[cem@freebsd.org,csecem@gmail.com]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TAGGED_FROM(0.00)[]; FROM_NEQ_ENVFROM(0.00)[cem@freebsd.org,csecem@gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.996]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.02)[-1.018]; 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)[209.85.167.171:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.167.171:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 21 Sep 2020 01:16:35 -0000 Hi Shawn, Is it possible to reproduce the issue on FreeBSD? The excerpt you've linked to is not on FreeBSD. Conrad On Sun, Sep 20, 2020 at 5:53 PM Shawn Webb wrote: > > From latest HEAD on a Dell Precision 7550 laptop: > > https://gist.github.com/lattera/a0803f31f58bcf8ead51ac1ebbc447e2 > > The last working boot environment was 14 Aug 2020. If I get some time to > bisect commits, I'll try to figure out the culprit. > > Thanks, > > Shawn Webb > > (Sorry for the brevity. Only partially working system due to above > breakage.) > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Mon Sep 21 06:38:42 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 98E8F3E7366; Mon, 21 Sep 2020 06:38:42 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qt1-f181.google.com (mail-qt1-f181.google.com [209.85.160.181]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4BvvsY5RxDz3YKT; Mon, 21 Sep 2020 06:38:41 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-qt1-f181.google.com with SMTP id r8so11345422qtp.13; Sun, 20 Sep 2020 23:38:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=eR1CRB24hVmFUwGNN2cmesZOS3U37MEzwjgPlMBct54=; b=GJ1FyVVaA3pR9mjB6saB+XlTtUYTSNOa0dZCILdpC6ZfUUdb8SNH5XWE4ZlbNdmV2n 8sh4LT0FhbKJQQWcwMX+90n9UyXSH0BBk0k5FG/XJFaB3zBlp73KnyHs/IjuG8tRQClA IZrJh5EKHKUGPDYGa8aK+S/nIJ+ppgI4OegvqOAF33tRBORUZA+kNbqVqVJA5kXeMXt7 sea1hcGMPGMxZpb74Xwz1rWe43+wHFqFa14u/d8V9AQureA1gZixpYhVG2qkX2uo+VYu NWaAhfsovyXS6MQ0P9Rrhno06Ex4xWl1CeP/ANPGkSYF3e9bWDCK7yI4dgyXz2pU+2VQ m71w== X-Gm-Message-State: AOAM5338ZOefp2wiHz0S6XeC0RCo1vS8c5ExgzP1QXOh48ma9gQKrcMK t7ZzxGn49gN++KyiDG18YcUGOJEmWsasufjFRX7Wq7LRElZaFQ== X-Google-Smtp-Source: ABdhPJwojBwdJOK3k4DajA7XMbGeQHhcFDYQ/asLezrIWP5qiA/zbRZXDvvycfSozRbb3nT+1VGdAqGi0sPo84xdT80= X-Received: by 2002:ac8:18da:: with SMTP id o26mr42380513qtk.92.1600670320192; Sun, 20 Sep 2020 23:38:40 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Adrian Chadd Date: Sun, 20 Sep 2020 23:38:27 -0700 Message-ID: Subject: Re: mips32 + gcc9 -- still broken To: freebsd-current , "freebsd-mips@freebsd.org" X-Rspamd-Queue-Id: 4BvvsY5RxDz3YKT X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.23 / 15.00]; ARC_NA(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current,freebsd-mips]; FROM_NEQ_ENVFROM(0.00)[adrian@freebsd.org,adrianchadd@gmail.com]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[freebsd.org]; TO_DN_EQ_ADDR_SOME(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[209.85.160.181:from]; RCVD_TLS_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.997]; NEURAL_HAM_MEDIUM(-0.93)[-0.934]; NEURAL_HAM_SHORT(-0.29)[-0.295]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[209.85.160.181:from]; FORGED_SENDER(0.30)[adrian@freebsd.org,adrianchadd@gmail.com]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 21 Sep 2020 06:38:42 -0000 So, the big list of unknown symbols was my fault! Whoops. i've gotten further using gcc-6.4 by fixing some of the warnings/issues that have crept up. Here's a review for one of them: https://reviews.freebsd.org/D26504 However, now I've hit: /usr/local/bin/mips-unknown-freebsd13.0-ld: /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp/usr/lib/libc++.so.1: undefined reference to `__atomic_fetch_sub_8' /usr/local/bin/mips-unknown-freebsd13.0-ld: /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp/usr/lib/libc++.so.1: undefined reference to `__atomic_load_8' /usr/local/bin/mips-unknown-freebsd13.0-ld: /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp/usr/lib/libc++.so.1: undefined reference to `__atomic_fetch_add_8' .. looks like we need some 64 bit atomics now in mips32 for libc++ / devd. -adrian From owner-freebsd-current@freebsd.org Mon Sep 21 07:22: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 45C7A3E84A9 for ; Mon, 21 Sep 2020 07:22:17 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4Bvwqq621Vz3bNj for ; Mon, 21 Sep 2020 07:22:15 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from outgoing.leidinger.net (p5b165ac1.dip0.t-ipconnect.de [91.22.90.193]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (Client did not present a certificate) by mailgate.Leidinger.net (Postfix) with ESMTPSA id C78A72430B for ; Mon, 21 Sep 2020 09:22:02 +0200 (CEST) Received: from webmail.leidinger.net (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (Client did not present a certificate) by outgoing.leidinger.net (Postfix) with ESMTPS id 40A9A5B0D for ; Mon, 21 Sep 2020 09:22:00 +0200 (CEST) Date: Mon, 21 Sep 2020 09:21:59 +0200 Message-ID: <20200921092159.Horde.yLakOjqLl4pZWCjCuYTfZVh@webmail.leidinger.net> From: Alexander Leidinger To: freebsd-current@freebsd.org Subject: Re: Plans for git References: <202009201400.08KE0PBd028190@gndrsh.dnsmgr.net> <13a965d9-ef02-f876-dd6c-aa872b66d114@nomadlogic.org> In-Reply-To: <13a965d9-ef02-f876-dd6c-aa872b66d114@nomadlogic.org> Accept-Language: de,en Content-Type: multipart/signed; boundary="=_lqTMjdFjtEF4gS35EGxx3ka"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-Rspamd-Queue-Id: 4Bvwqq621Vz3bNj X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.19 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; NEURAL_HAM_MEDIUM(-0.94)[-0.943]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.03)[-1.033]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[leidinger.net:+]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; NEURAL_HAM_SHORT(-0.12)[-0.116]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:34240, ipnet:2a00:1828::/32, country:DE]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current]; RECEIVED_SPAMHAUS_PBL(0.00)[91.22.90.193:received] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 21 Sep 2020 07:22:17 -0000 This message is in MIME format and has been PGP signed. --=_lqTMjdFjtEF4gS35EGxx3ka Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoting Pete Wright (from Sun, 20 Sep 2020=20=20 08:41:13=20-0700): Not responding to Pete directly, but in general to this topic with=20=20 some=20parts of what Pete considers good as something to hook into. >>> making quarterly reports about this for almost a years as well. We put = out >>> calls for people to help with the efforts about the same time. We have >>> tried at every step of the way to be open and honest that this was goin= g to >>> happen. >> All developer centric communications.... I fail to see why it is important to non-developers, which (D)VCS the=20=20 developers=20of the product they use are using. It may be interesting,=20= =20 yes.=20It may have an impact on some (see the announcement of=20=20 deprecation=20of portsnap), but those which put their craftmanship into=20= =20 it,=20are the important ones. Not to tell that we don't need to inform=20= =20 (or=20to let them repeat all the arguments we provided internally=20=20 already),=20but the main use case for the VCS is to have those with=20=20 commit=20privilegues handle version control. I do not go to a lot of in-person meetings, I just follow the internal=20= =20 and=20the official mailinglists, and there was communication for a=20=20 loooong=20time (and no, I do not use git for FreeBSD stuff so far, so=20=20 you=20can not consider myself as someone who is eager to get FreeBSD=20=20 moved=20to git and as such has an interest in it --- but I do understand=20= =20 the=20reasoning and can agree to it). Any FreeBSD committer who tells he=20= =20 was=20not aware of it, has simply not paid attention to it. For any=20=20 non-committer=20see below. > I would argue that quarterly reports are actually one of the few [...] > honestly there has to be *some* responsibility of operators to at=20=20 >=20least make an effort to keep up to date on the status of the various=20= =20 >=20efforts in such a large project.=C2=A0 and as an outsider the idea that= =20=20 >=20comms can only happen on the mailing list isn't the greatest - how=20= =20 >=20am i to know that the idea of one person on the ML carries more=20=20 >=20weight than another, or one persons opinion is the "official" stated=20= =20 >=20opinion of the core group? I agree to that. And I agree that the status reports are a nice way of=20= =20 getting=20some kind of inside-information in a central way. And in my=20=20 opinion=20we gave early enough information about the migration to git.=20= =20 Maybe=20it can be organized, so that some guides for users (again,=20=20 deprecation=20of portsnap and such) are published first via the status=20= =20 reports=20(and other channels), before the switch to the git-repo=20=20 happens.=20We have no other official channel which is suitable for such=20= =20 way-ahead=20announcements IMO (yes, we should send a mail to=20=20 freebsd-announce=20when we switch + an entry in the news section of the=20= =20 website,=20and /maybe/ we should send a mail some weeks before the=20=20 switch=20too, but so far, I do not think this info should have been send=20= =20 to=20freebsd-announce, or be published on the website). In my opinion the people which drive this didn't keep it behind closed=20= =20 curtains,=20and they went step by step more public, as they made=20=20 progress.=20To me it looks like now, that they have something which is=20= =20 presentable=20to the world (and not only to committers), they presented=20= =20 it=20to the world. I do not think we can hold them responsible that we=20= =20 do=20not have "the one official channel" for this (hey... anyone feel=20=20 free=20to create it for the next big change, and document what shall be=20= =20 announced=20how via this channel). Bye, Alexander. --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_lqTMjdFjtEF4gS35EGxx3ka Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJfaFSXAAoJEBINsJsD+NiGCqsQAJASGqa0sHT5JGv8pwP28TIe auHTonQr60IcgdKIZUNl3ImvdzE/T8wUrU1E2quBRxQ+JeZmzFoDNLMImgt7urhY jgk5uI9sHh1Rl2kTgH7IOF8mwhlblhK6ud29LOZ2PEfRMag4h651fVgbue+9z9V/ M0W8UqT2nM4SJzrq2rTK+/CH/Jf9JUMY1yRLxsK1Up93EhQRCuuB7jKj4O6rnDVl DxNi1+MM/i8ORbM9LeCTw5a+gQEdZHPTLstz5vO6Z+FSzvlfkGh/a6CPH7YhrJeV 6dJlu0BgutUgFUBqnL8ojuw9LmkCc6WjR9kn2FY+vU+5oMRxdYql4zAyOVhBPqxO li9wfkz/8jB8i0mGbzi67XScnO7iYQ+r8ABW0laCWHSDfdpDb35q2dkuHv5M9Fp3 ft/zx/z7Wx/2R8J77CcWmME4L6ViE51W7Ix1135mcLlCVZolcX5MpkhGPexrtJR9 lZjogKkxtGmmFQIOAx5hHTndYjT2gGvfG57HKn48lFPVx4IS4cXjdei7Rznw9c8z gojpSaWpaNFvP8xqsbHLl8BRYgP1xqF1mDJvdOK/BhtZkosnLa6yMogYNYuR+MLA ADOD9RNlFBBVFQPZkKb50qgvkh770IIJpfS2c3IIk31NO+00CxMMV4jew9PRxdm4 jWRla214i0uCqnjQjP+Q =xOA2 -----END PGP SIGNATURE----- --=_lqTMjdFjtEF4gS35EGxx3ka-- From owner-freebsd-current@freebsd.org Mon Sep 21 07:43: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 93D903E918F; Mon, 21 Sep 2020 07:43:05 +0000 (UTC) (envelope-from arichardson.kde@gmail.com) Received: from mail-ej1-f46.google.com (mail-ej1-f46.google.com [209.85.218.46]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4BvxHr2lz2z3cdx; Mon, 21 Sep 2020 07:43:04 +0000 (UTC) (envelope-from arichardson.kde@gmail.com) Received: by mail-ej1-f46.google.com with SMTP id p9so16305001ejf.6; Mon, 21 Sep 2020 00:43:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RUOEmwn95QbJNL9wkB7JKdUyz2lAtuoZE830wg4gYUE=; b=JKrVMAyMQGX5JlIFUV1Xr82ocqAjBFDq+hoeDXkRAb79OAKuu2pzHOikI+OMTYlsIk 6c7npwZ7Cx2e1tbu6rO3ynuZx0JEpyh94AhTNyAnnz03jQvgMbayo+ODAgxhzkV6QPAn Kn0fG9bxOJQEFjSEtyMEJQz18lUqjRHhHh2G3OeevslVWfcg9pP080PbzTL7GP28qjrY Es8rV3zAsil3nFa5XoLoc4ZnlDLOKW1dEAt8B7rCiUkfLCJxLC9bVsfYkPxoxErr/pI3 SIBGyV64DX0diurx9ZcP/GIzyDSuOzTxi8WUwKbys5ItHccIFVPC/jTNl3aIs56EZqLn /XLQ== X-Gm-Message-State: AOAM532pDHcrqSCA+xFbu99bLmYBVsty9kRWtbavZayfaZ0+Bf+n9SCF dSQIIL6cpc+xhi7ZJ5msoJSQq4XyWVLs/w== X-Google-Smtp-Source: ABdhPJwcWBlXcmnmReqxFih/K6rQ10S9WuRAQQ+pcvGzD6UXMBjfvRca9JsosEh3lAuZpDpsCcTlAw== X-Received: by 2002:a17:906:4a07:: with SMTP id w7mr48302259eju.366.1600674182968; Mon, 21 Sep 2020 00:43:02 -0700 (PDT) Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com. [209.85.128.41]) by smtp.gmail.com with ESMTPSA id f21sm8064012edw.83.2020.09.21.00.43.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Sep 2020 00:43:02 -0700 (PDT) Received: by mail-wm1-f41.google.com with SMTP id y15so11471912wmi.0; Mon, 21 Sep 2020 00:43:02 -0700 (PDT) X-Received: by 2002:a1c:4b04:: with SMTP id y4mr28414427wma.111.1600674182409; Mon, 21 Sep 2020 00:43:02 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alexander Richardson Date: Mon, 21 Sep 2020 08:42:49 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: mips32 + gcc9 -- still broken To: Adrian Chadd Cc: freebsd-current , freebsd-mips@freebsd.org X-Rspamd-Queue-Id: 4BvxHr2lz2z3cdx X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.30 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MIME_TRACE(0.00)[0:+,1:+,2:~]; DMARC_NA(0.00)[freebsd.org]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.995]; RCVD_COUNT_THREE(0.00)[4]; RWL_MAILSPIKE_GOOD(0.00)[209.85.218.46:from]; NEURAL_HAM_SHORT(-0.34)[-0.338]; RCVD_IN_DNSWL_NONE(0.00)[209.85.218.46:from]; NEURAL_HAM_MEDIUM(-0.97)[-0.966]; FORGED_SENDER(0.30)[arichardson@freebsd.org,arichardsonkde@gmail.com]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[arichardson@freebsd.org,arichardsonkde@gmail.com]; TAGGED_FROM(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current,freebsd-mips] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 21 Sep 2020 07:43:05 -0000 On Mon, 21 Sep 2020, 07:38 Adrian Chadd, wrote: > So, the big list of unknown symbols was my fault! Whoops. > > i've gotten further using gcc-6.4 by fixing some of the warnings/issues > that have crept up. > > Here's a review for one of them: > > https://reviews.freebsd.org/D26504 > > However, now I've hit: > > /usr/local/bin/mips-unknown-freebsd13.0-ld: > > /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp/usr/lib/libc++.so.1: > undefined reference to `__atomic_fetch_sub_8' > /usr/local/bin/mips-unknown-freebsd13.0-ld: > > /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp/usr/lib/libc++.so.1: > undefined reference to `__atomic_load_8' > /usr/local/bin/mips-unknown-freebsd13.0-ld: > > /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp/usr/lib/libc++.so.1: > undefined reference to `__atomic_fetch_add_8' > > .. looks like we need some 64 bit atomics now in mips32 for libc++ / devd > Those are now provided by compiler-rt when using clang. With GCC you'll have to link libatomic. I had a quick look at the code in libc++ that uses the 64-bit atomics a few weeks ago and I believe it's the futex fallback code. The best solution would probably be to port it to use umtx but for MIPS32 it might be fine to use a 32 bit atomic instead. Alex > From owner-freebsd-current@freebsd.org Mon Sep 21 07:57:47 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 67F3A3E9B19 for ; Mon, 21 Sep 2020 07:57:47 +0000 (UTC) (envelope-from kp@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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4Bvxcq28CYz3dfL; Mon, 21 Sep 2020 07:57:47 +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 1338A2E35A; Mon, 21 Sep 2020 07:57:47 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: by venus.codepro.be (Postfix, authenticated sender kp) id 0CA8811991; Mon, 21 Sep 2020 09:57:44 +0200 (CEST) From: "Kristof Provost" To: "Shawn Webb" Cc: "FreeBSD Current" Subject: Re: iflib/bridge kernel panic Date: Mon, 21 Sep 2020 09:57:40 +0200 X-Mailer: MailMate (1.13.2r5673) Message-ID: <58CADEBB-64FD-414E-AB19-E4F8D3CABCA5@FreeBSD.org> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 21 Sep 2020 07:57:47 -0000 On 21 Sep 2020, at 2:52, Shawn Webb wrote: >> From latest HEAD on a Dell Precision 7550 laptop: > > https://gist.github.com/lattera/a0803f31f58bcf8ead51ac1ebbc447e2 > > The last working boot environment was 14 Aug 2020. If I get some time to > bisect commits, I'll try to figure out the culprit. > Try https://reviews.freebsd.org/D26418 Best regards, Kristof From owner-freebsd-current@freebsd.org Mon Sep 21 12:16: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 B76553F034D for ; Mon, 21 Sep 2020 12:16:32 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qk1-x741.google.com (mail-qk1-x741.google.com [IPv6:2607:f8b0:4864:20::741]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4Bw3MN1PYqz4Ckp for ; Mon, 21 Sep 2020 12:16:31 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qk1-x741.google.com with SMTP id f142so14613736qke.13 for ; Mon, 21 Sep 2020 05:16:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=Rw9Gf5xYiNPhq8LTZ+rCOgD5/rYC82FQXp6QiNV5J0Y=; b=RznYZFcVEImGZ44zpdQ3dVjnf1TPkPWAcPn332g5OLdQmbnExoTyEc1FpPq6sALUFr OAAzSHpKgn44dLRGcYslv0vUmof6AxAl+lkOoDbOsXmDXzmlHP6X0WGXjl3+8ow7grv0 zjhyUM1kBRnTYxN5XMudPpVYjy4wfaxp2hZQMDNDkX5irNj1SQb8LsZu3t8FDu6QWal2 IiyqIaCRhvpvCHDLZAzmCDVAC21SeoYBgJyOseELPbBV9QCWmaKyNn5+JsJ3CvDdvVHQ S+/l2m8yaRK6RxIxZwHAnGKg+7ogd4PevrRuCw94EAdIc+51ZSAZyNc7gADwvUYIYY4k RYkg== X-Gm-Message-State: AOAM532u4Co5AmCD49rXFsoVYSvdfU8iojp8Kyb2JcTTvM02xYr9eqEm PpR31somY0xg/DgeouBRs7e/+g== X-Google-Smtp-Source: ABdhPJzrdxHJDpOe2j6fWUBeA3NULG59FcExviMfmmZCZCtHke5TI9DG9lvsIgY4FPL6mRsBxZ0R2w== X-Received: by 2002:a37:4cc9:: with SMTP id z192mr18406683qka.364.1600690591091; Mon, 21 Sep 2020 05:16:31 -0700 (PDT) Received: from mutt-hbsd (75-148-2-186-WashingtonDC.hfc.comcastbusiness.net. [75.148.2.186]) by smtp.gmail.com with ESMTPSA id c13sm9663303qtq.5.2020.09.21.05.16.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 21 Sep 2020 05:16:30 -0700 (PDT) Date: Mon, 21 Sep 2020 08:16:27 -0400 From: Shawn Webb To: Kristof Provost Cc: FreeBSD Current Subject: Re: iflib/bridge kernel panic Message-ID: <20200921121627.3dovpumnl6xub3kn@mutt-hbsd> X-Operating-System: FreeBSD mutt-hbsd 13.0-CURRENT-HBSD FreeBSD 13.0-CURRENT-HBSD X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0xFF2E67A277F8E1FA References: <58CADEBB-64FD-414E-AB19-E4F8D3CABCA5@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="mv567ducpuubc3ie" Content-Disposition: inline In-Reply-To: <58CADEBB-64FD-414E-AB19-E4F8D3CABCA5@FreeBSD.org> X-Rspamd-Queue-Id: 4Bw3MN1PYqz4Ckp X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.81 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[hardenedbsd.org:s=google]; NEURAL_HAM_MEDIUM(-0.98)[-0.984]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; NEURAL_HAM_LONG(-1.02)[-1.021]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[hardenedbsd.org]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[hardenedbsd.org:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::741:from]; NEURAL_HAM_SHORT(-0.71)[-0.706]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 21 Sep 2020 12:16:32 -0000 --mv567ducpuubc3ie Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 21, 2020 at 09:57:40AM +0200, Kristof Provost wrote: > On 21 Sep 2020, at 2:52, Shawn Webb wrote: > >> From latest HEAD on a Dell Precision 7550 laptop: > > > > https://gist.github.com/lattera/a0803f31f58bcf8ead51ac1ebbc447e2 > > > > The last working boot environment was 14 Aug 2020. If I get some time to > > bisect commits, I'll try to figure out the culprit. > > > Try https://reviews.freebsd.org/D26418 That seems to fix the kernel panic. dmesg gets spammed with a freak ton of these LOR messages now: =3D=3D=3D=3D BEGIN LOG 01 =3D=3D=3D=3D Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] Sleeping on "e1000_delay" with = the following non-sleepable locks held: Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] exclusive sleep mutex if_bridge= (if_bridge) r =3D 0 (0xfffff8001ea07218) locked @ /usr/src/sys/net/if_brid= ge.c:827 Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] stack backtrace: Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] #0 0xffffffff80c6c4a1 at witnes= s_debugger+0x71 Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] #1 0xffffffff80c6d5bd at witnes= s_warn+0x40d Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] #2 0xffffffff80c09b8b at _sleep= +0x5b Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] #3 0xffffffff80c0a38e at pause_= sbt+0xfe Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] #4 0xffffffff80652b2d at e1000_= write_phy_reg_mdic+0xed Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] #5 0xffffffff80656bde at __e100= 0_write_phy_reg_hv+0x1ce Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] #6 0xffffffff80640ea9 at e1000_= lv_jumbo_workaround_ich8lan+0x799 Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] #7 0xffffffff8062329e at em_if_= init+0x151e Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] #8 0xffffffff80d347a9 at iflib_= init_locked+0x2d9 Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] #9 0xffffffff80d36b08 at iflib_= if_ioctl+0x1b8 Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] #10 0xffffffff83c582ac at bridg= e_set_ifcap+0x8c Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] #11 0xffffffff83c544c8 at bridg= e_ioctl_add+0x4c8 Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] #12 0xffffffff83c560ff at bridg= e_ioctl+0x2df Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] #13 0xffffffff80d9f1a1 at in_co= ntrol+0x341 Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] #14 0xffffffff80d16266 at ifioc= tl+0x766 Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] #15 0xffffffff80c715a0 at kern_= ioctl+0x290 Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] #16 0xffffffff80c71267 at sys_i= octl+0x127 Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] #17 0xffffffff8122bf4c at amd64= _syscall+0x14c =3D=3D=3D=3D END LOG 01 =3D=3D=3D=3D =3D=3D=3D=3D BEGIN LOG 02 =3D=3D=3D=3D Sep 21 08:08:28 hbsd-laptop-02 kernel: [29] lock order reversal: (sleepable= after non-sleepable) Sep 21 08:08:28 hbsd-laptop-02 kernel: [29] 1st 0xfffff800374616a0 ure0 (u= re0, sleep mutex) @ /usr/src/sys/dev/usb/usb_request.c:714 Sep 21 08:08:28 hbsd-laptop-02 kernel: [29] 2nd 0xffffffff81eb1ab8 sysctl = lock (sysctl lock, sleepable rm) @ /usr/src/sys/kern/kern_sysctl.c:837 Sep 21 08:08:28 hbsd-laptop-02 kernel: [29] lock order ure0 -> sysctl lock = attempted at: Sep 21 08:08:28 hbsd-laptop-02 kernel: [29] #0 0xffffffff80c6c1dc at witnes= s_checkorder+0xdcc Sep 21 08:08:28 hbsd-laptop-02 kernel: [29] #1 0xffffffff80bf76bb at _rm_wl= ock_debug+0x6b Sep 21 08:08:28 hbsd-laptop-02 kernel: [29] #2 0xffffffff80c0c7a6 at sysctl= _add_oid+0x46 Sep 21 08:08:28 hbsd-laptop-02 kernel: [29] #3 0xffffffff83c64ea1 at ure_at= tach_post+0x1a91 Sep 21 08:08:28 hbsd-laptop-02 kernel: [29] #4 0xffffffff83c6a1af at ue_att= ach_post_task+0x2f Sep 21 08:08:28 hbsd-laptop-02 kernel: [29] #5 0xffffffff80a2b749 at usb_pr= ocess+0xf9 Sep 21 08:08:28 hbsd-laptop-02 kernel: [29] #6 0xffffffff80bb9fe5 at fork_e= xit+0x85 Sep 21 08:08:28 hbsd-laptop-02 kernel: [29] #7 0xffffffff81200a9e at fork_t= rampoline+0xe =3D=3D=3D=3D END LOG 02 =3D=3D=3D=3D At work, I have two ethernet interfaces: the onboard em0 and a usb ethernet= dongle. Thanks, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Sha= wn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --mv567ducpuubc3ie Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAl9omZgACgkQ/y5nonf4 4foACA//VxJhoEI6+Xl1rzpn3tkP3SwYPnrtk3cuxZsUJSHT0/jqZqiw5BGs/v7n qNx9Gs7/yf5uesGVRqB695F5e6EcE+MR8IlN+462dqCnUEga3gfwjWZ5XQrxklmv gS79tfAlkTIe3iZhdMbEEOIL7UhrB89hL01tzPSqQ6b0FNAlxBn0ML6us6qOuv7h JLX4VIcZBESoN3oR/UrDz2XyjI1T8JwVzy06PhqwMtcP3fgFpw9S714kbuzsyoR9 SSEj4B6LU6hBNZmRvfY0QXDSpvq/CGRZievdXH+yzqyDdMVjucyYHZQqKCZog8Me XZwK1YbNoe40qTybPr6VzMydXMNFhNitVaYQb3JSlYOPMfaCtOGQAgIXqEkxfEl/ A/LawNfop/js1nIeD+ZaYm6pzMIE43+VtQdcnZjC91w7k7AKmlQrHEgOcG/qDxBO kCtwnrtZ5vArflGC7PQuj2LlzJXIu4l5DAfkJ1NnNvuZCXLdLTysSL7iy/gfKKYw 9N4f5YZStrW4nYKl0V6lr03/sk0bRLkmth2KtEW8ub6einll2b5ZJxbgpqvNAZI4 gF2bpSSj6zppNFMtx6UgO+yV4unbk5cNp61GxpIvOoK1jSqc4XK7NWiw+Qg5Ae6E TKtDOWEXwSLEjIoDUq8Wv1Xgh9ayVzB/t99OSPPg7GDIlRd5sXk= =FvwT -----END PGP SIGNATURE----- --mv567ducpuubc3ie-- From owner-freebsd-current@freebsd.org Mon Sep 21 14:49:10 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 B197D3F38AD; Mon, 21 Sep 2020 14:49:10 +0000 (UTC) (envelope-from chardon.frederic@gmail.com) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4Bw6lT5b2Kz4LSP; Mon, 21 Sep 2020 14:49:09 +0000 (UTC) (envelope-from chardon.frederic@gmail.com) Received: by mail-io1-xd30.google.com with SMTP id m17so15688787ioo.1; Mon, 21 Sep 2020 07:49:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=bccWvwPLdytfvuXL+hyCpeH1HrSLp39CfHL56e70DHM=; b=dM1hZYYMM5+bdLuGLXSZOJiAgGpcHZNNm6SNqQzvR2huMhGL+KERtl0G9k+n52Bm0G lIdUsgZlvJy76f8PeNWlUnHbMqKV/41jnW722XnOI81Xx7xeI63CUN4Wuzh46iuxaHpP /WGeyOSswIq8O2OXoIk4m205/N38Hpiu05DCTopdUdOxQ5sGsomoyXrChgw3oEzBLKKe Wapclmf7qMW+GjpS6RrUm3PsgGJSwKcyBfVl6Wemf+qQmBa02zn+4i1msMukvoDFXerJ 9/+rphjscbLes68PXYbMBAbEhb3IS34g4fTrmzZ3C3redGVLBLZ1dIyRf+Bs3uTsAyFH 4XZw== X-Gm-Message-State: AOAM530qlCh2NsVE2M8P5+lqJWabTvb/Xsx3SwfkqZ9TGqx9qoqzC6GO 7DrTkGwAGRn9AW1yWnI//yUqYx1U79zMLewETK7yf+4x6b6fA6cg X-Google-Smtp-Source: ABdhPJxvH9yzDLKpd6iEXyLmi8Z33UL4NSltfGM+IgC/eHIkgnxt33wkA7vGsPjrsS22j3v9mKUxfecpIEF6W5H3r+8= X-Received: by 2002:a02:1004:: with SMTP id 4mr299147jay.127.1600699748359; Mon, 21 Sep 2020 07:49:08 -0700 (PDT) MIME-Version: 1.0 References: <1AFD8BB9-F598-451A-A1D9-16D550402E3E@FreeBSD.org> In-Reply-To: <1AFD8BB9-F598-451A-A1D9-16D550402E3E@FreeBSD.org> From: Frederic Chardon Date: Mon, 21 Sep 2020 16:48:57 +0200 Message-ID: Subject: Re: objcopy "text file busy" build failure with populated /usr/obj To: Mark Murray Cc: freebsd-arm , freebsd-current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4Bw6lT5b2Kz4LSP X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.47 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.984]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.03)[-1.027]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; 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)[2607:f8b0:4864:20::d30:from]; NEURAL_HAM_SHORT(-0.46)[-0.462]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm,freebsd-current]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 21 Sep 2020 14:49:10 -0000 Le dim. 20 sept. 2020 =C3=A0 16:59, Mark Murray a =C3= =A9crit : > > Hi * > > I've been getting these build failures for a while (weeks/months). The ma= chine is a MacchiatoBin DoubleShot (arm64, Quad core). with SATA disks and = zfs filesystem. If I empty out /usr/obj, then the build works, but takes a = few hours. If I do a no-clean build with /obj/obj populated with he content= s of a previous build, and /usr/src with updated ("svn update") sources, th= en the below nearly always happens early in the rebuild. It is in "stage 4.= 4: building everything" that this happens. The build is parallel (-j8), and= I have manually de-threaded the output. > > The generated command-line from the logfile is: > > cd /usr/src; _PARALLEL_SUBDIR_OK=3D1 MACHINE_ARCH=3Daarch64 MACHINE=3Dar= m64 CPUTYPE=3Dcortex-a72 CC=3D"/usr/local/bin/ccache cc -target aarch64-un= known-freebsd13.0 --sysroot=3D/usr/obj/usr/src/arm64.aarch64/tmp -B/usr/obj= /usr/src/arm64.aarch64/tmp/usr/bin" CXX=3D"/usr/local/bin/ccache c++ -targ= et aarch64-unknown-freebsd13.0 --sysroot=3D/usr/obj/usr/src/arm64.aarch64/t= mp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin" CPP=3D"cpp -target aarch6= 4-unknown-freebsd13.0 --sysroot=3D/usr/obj/usr/src/arm64.aarch64/tmp -B/usr= /obj/usr/src/arm64.aarch64/tmp/usr/bin" AS=3D"as" AR=3D"ar" LD=3D"ld" LLVM= _LINK=3D"" NM=3Dnm OBJCOPY=3D"objcopy" RANLIB=3Dranlib STRINGS=3D SIZE= =3D"size" STRIPBIN=3D"strip" INSTALL=3D"install -U" PATH=3D/usr/obj/usr/s= rc/arm64.aarch64/tmp/bin:/usr/obj/usr/src/arm64.aarch64/tmp/usr/sbin:/usr/o= bj/usr/src/arm64.aarch64/tmp/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/leg= acy/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/bin:/usr/obj/usr= /src/arm64.aarch64/tmp/legacy/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy= /usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin SYSROOT=3D/usr/obj/usr/src/arm= 64.aarch64/tmp make -f Makefile.inc1 BWPHASE=3Deverything DESTDIR=3D/usr= /obj/usr/src/arm64.aarch64/tmp all > > Anyone else seeing this? > > objcopy --strip-debug --add-gnu-debuglink=3Dobjcopy.debug objcopy.full o= bjcopy > objcopy: open objcopy failed: Text file busy > --- all_subdir_usr.bin/objcopy --- > *** [objcopy] Error code 1 > > make[4]: stopped in /usr/src/usr.bin/objcopy > > M > -- Hi I got the same on amd64 with a meta mode build, on zfs as well. Oddly (or not), it happens only if I make buildworld as a normal user, but not as root. A second make buildworld always succeed. From owner-freebsd-current@freebsd.org Mon Sep 21 18:57:55 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 0C3733F92BC for ; Mon, 21 Sep 2020 18:57:55 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from gmailer.gwdg.de (gmailer.gwdg.de [134.76.11.17]) (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 4BwDGV14FGz4gFt for ; Mon, 21 Sep 2020 18:57:53 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from excmbx-03.um.gwdg.de ([134.76.9.218] helo=email.gwdg.de) by mailer.gwdg.de with esmtp (GWDG Mailer) (envelope-from ) id 1kKR0Z-0008Gd-JY; Mon, 21 Sep 2020 20:57:51 +0200 Received: from krabat.raven.hur (10.250.9.199) by EXCMBX-03.um.gwdg.de (134.76.9.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521) id 15.1.2044.4; Mon, 21 Sep 2020 20:57:51 +0200 Subject: Re: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X From: Rainer Hurling To: Konstantin Belousov CC: Hans Petter Selasky , monochrome , Reply-To: References: <69ff9432-fc8f-b0ab-8ad2-8e3daa77f8e1@twcny.rr.com> <1a88773b-d2fa-a790-c7e2-868d3884ba8b@twcny.rr.com> <865D6BF0-9F1E-4125-81D3-FB9A369FED8D@gwdg.de> <88af31d4-9ed9-172a-d48f-1780f19841e3@twcny.rr.com> <11d27d41-029a-d7f5-eccc-0ba3a3fcfe97@gwdg.de> <2bbfb4b3-92e9-b3ca-9c31-6c513cee2f2d@gwdg.de> <20200920093814.GD94807@kib.kiev.ua> <0249197f-29f6-4df4-eb63-ca786aaea39d@gwdg.de> <20200920195526.GH94807@kib.kiev.ua> <20200920200735.GJ94807@kib.kiev.ua> <1621df05-35a9-92b9-ffee-d93c17110d87@gwdg.de> Message-ID: <2673660d-3a6e-97c9-82a2-17b5ab8b987b@gwdg.de> Date: Mon, 21 Sep 2020 20:57:46 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.3.0 MIME-Version: 1.0 In-Reply-To: <1621df05-35a9-92b9-ffee-d93c17110d87@gwdg.de> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.250.9.199] X-ClientProxiedBy: EXCMBX-04.um.gwdg.de (134.76.9.219) To EXCMBX-03.um.gwdg.de (134.76.9.218) X-Virus-Scanned: (clean) by clamav X-Rspamd-Queue-Id: 4BwDGV14FGz4gFt X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.51 / 15.00]; HAS_REPLYTO(0.00)[rhurlin@freebsd.org]; HAS_XOIP(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:134.76.10.0/23]; RCVD_COUNT_THREE(0.00)[3]; RCVD_IN_DNSWL_MED(-0.20)[134.76.11.17:from]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:680, ipnet:134.76.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[rhurlin]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_MEDIUM(-1.00)[-1.003]; NEURAL_HAM_LONG(-1.04)[-1.040]; MIME_GOOD(-0.10)[text/plain]; REPLYTO_DOM_NEQ_FROM_DOM(0.00)[]; DMARC_NA(0.00)[gwdg.de]; NEURAL_SPAM_SHORT(0.03)[0.034]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RWL_MAILSPIKE_VERYGOOD(0.00)[134.76.11.17:from]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 21 Sep 2020 18:57:55 -0000 On 20.09.20 22:35, Rainer Hurling wrote: > On 20.09.20 22:07, Konstantin Belousov wrote: >> On Sun, Sep 20, 2020 at 10:55:26PM +0300, Konstantin Belousov wrote: >>> On Sun, Sep 20, 2020 at 03:11:26PM +0200, Rainer Hurling wrote: >>>> Am 20.09.20 um 11:38 schrieb Konstantin Belousov: >>>>> On Sun, Sep 20, 2020 at 10:26:11AM +0200, Rainer Hurling wrote: >>>>>> Am 20.09.20 um 10:20 schrieb Hans Petter Selasky: >>>>>>> On 2020-09-20 10:05, Rainer Hurling wrote: >>>>>>>> Hi monochrome, >>>>>>>> >>>>>>>> back to keyboard, it tried newest CURRENT (r365920) on my box and even >>>>>>>> with newest sources the error occurs. >>>>>>>> >>>>>>>> After looking around somewhat more, I found some hints about Virtualbox >>>>>>>> kernel module having problems with r365488. Unfortunately, I am not able >>>>>>>> to find the thread again :( >>>>>>>> >>>>>>>> What seems to help as a workaround is to disable the loading of >>>>>>>> VirtualBox in /boot/loader.conf >>>>>>>> >>>>>>>> #vboxdrv_load="YES" >>>>>>>> >>>>>>>> and in /etc/rc.conf >>>>>>>> >>>>>>>> #vboxnet_enable="YES" >>>>>>>> #vboxguest_enable="YES" >>>>>>>> >>>>>>>> >>>>>>>> So probably, this page fault is not restricted to AMD Ryzen? >>>>>>>> >>>>>>> >>>>>>> Possibly you need to rebuild that kernel module. Maybe the FreeBSD >>>>>>> version was not bumped correctly. >>>>>>> >>>>>>> --HPS >>>>>>> >>>>>> >>>>>> Thanks for the hint. But I did rebuild all kernel modules before >>>>>> rebooting, in my case vbox*.ko, nvidia*.ko. >>>>> >>>>> Provide backtrace of the panic. >>>>> >>>> >>>> Hi Konstantin, >>>> >>>> Thanks for your response. >>>> >>>> After trying several ways to produce a core dump or a working kdb prompt >>>> without success, all I can offer is the following screen contents. I >>>> built a GENERIC kernel with debugging enabled, enable loading of vboxdrv >>>> via /boot/loader.conf and /etc/rc.conf as described above: >>>> >>>> >>>> [..snip..] >>>> procfs registered >>>> modulte_register_init: MOD_LOAD (tmpfs, 0xffffffff80caa060, >>>> 0xffffffff82520a70) error 17 >>>> Timecounters tick every 1.000 msec >>>> lo0: bpf attached >>>> vlan: initialized, using hash tables with chaining >>>> >>>> >>>> Fatal trap 12: page fault while in kernel mode >>>> cpuid = 31; apic id = 1f >>>> fault virtual address = 0x0 >>>> fault code = supervisor read data, page not present >>>> instruction pointer = 0x20:0xffffffff80ea889b >>>> stack pointer = 0x20:0xffffffff826017e0 >>>> frame pointer = 0x20:0xffffffff826017e0 >>>> code segment = base 0x0, limit 0xfffff, type 0x1b >>>> = DPL 0, pres 1, long 1, def32 0, gran 1 >>>> processor eflags = interrupt enabled, resume, IOPL = 0 >>>> current process = 0 (swapper) >>>> trap number = 12 >>>> panic: page fault >>>> cpuid = 31 >>>> time = 1 >>>> KDB: stack backtrace: >>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >>>> 0xffffffff82601490 >>>> vpanic() at vpanic+0x182/frame 0xffffffff826014e0 >>>> panic() at panic+0x43/frame 0xffffffff82601540 >>>> trap_fatal() at trap_fatal+0x387/frame 0xffffffff826015a0 >>>> trap_pfault() at trap_pfault+0x97/frame 0xffffffff82601600 >>>> calltrap() at calltrap+0x8/frame 0xffffffff82601710 >>>> --- trap 0xc, rip = 0xffffffff80ea889b, rsp = 0xffffffff826017e0, rbp = >>>> 0xffffffff826017e0 --- >>>> phys_pager_getpages() at phys_pager_getpages+0xb/frame 0xffffffff826017e0 >>>> vm_pager_get_pages() at vm_pager_get_pages+0x4f/frame 0xffffffff82601830 >>>> vm_fault() at vm_fault+0x5d6/frame 0xffffffff82601940 >>>> vm_map_wire_locked() at vm_map_wire_locked+0x3a6/framw 0xffffffff826019f0 >>>> vm_map_wire() at vm_map_wire+0x6b/frame 0xffffffff82601a20 >>>> rtR0MemObjFreeBSDAllocHelper() at >>>> rtR0MemObjFreeBSDAllocHelper+0xdc/frame 0xffffffff82601a70 >>>> rtR0MemObjNativeAllocCont() at rtR0MemObjNativeAllocCont+0x50/frame >>>> 0xffffffff82601ac0 >>>> supdrvGipCreate() at supdrvGipCreate+0x97/frame 0xffffffff82601b60 >>>> supdrvInitDevExt() at supdrvInitDevExt+0x19a/frame 0xffffffff82601bd0 >>>> VBoxDrvFreeBSDModuleEvent() at VBoxDrvFreeBSDModuleEvent+0x46/frame >>>> 0xffffffff82601bf0 >>>> module_register_init() at module_register_init+0xbd/frame 0xffffffff82601c20 >>>> mi_startup() at mi_startup+0xec/frame 0xffffffff82601c70 >>>> btext() at btext+0x2c >>>> KDB: enter: panic >>>> [ thread pid 0 tid 100000 ] >>>> Stopped at kdb_enter+0x37: movq $0,0x10b5796(%rip9 >>>> db> >>>> >>>> >>>> The system freezes at this point, no core dump is generated ;) This >>>> does not happen without loading VBoxDrv. >>>> >>>> At least, the screen dump shows VBoxDrvFreeBSDModuleEvent(). I hope, >>>> this is of some help. >>>> >>> Yes it seems to be enough for me to see where the possible issue is. >>> Try this patch, I did not even compiled it. Probably you need to put >>> it into ports/emulators/virtualbox-ose-kmod/files with the name ending >>> with .patch. >> This seems to be wrong, name should _start_ with the prefix 'patch-'. > > Many thanks for the patch! > > Putting it into emulators/virtualbox-ose-kmod/files/ as > patch-src_VBox_Runtime_r0drv_freebsd_memobj-r0drv-freebsd.c does not > patch the sources, probably because emobj-r0drv-freebsd.c was already > patched from the main port (virtualbox-ose). > > Patching manually, build and install the kernel module seems to work fine. > > Unfortunaly, after rebooting the same page fault occurs :( > > >>> >>> --- src/VBox/Runtime/r0drv/freebsd/memobj-r0drv-freebsd.c.xxx 2020-09-20 19:40:07.471956776 +0000 >>> +++ src/VBox/Runtime/r0drv/freebsd/memobj-r0drv-freebsd.c 2020-09-20 19:46:03.606966773 +0000 >>> @@ -323,7 +323,8 @@ >>> size_t cPages = atop(pMemFreeBSD->Core.cb); >>> int rc; >>> >>> - pMemFreeBSD->pObject = vm_object_allocate(OBJT_PHYS, cPages); >>> + pMemFreeBSD->pObject = vm_pager_allocate(OBJT_PHYS, NULL, >>> + pMemFreeBSD->Core.cb, VM_PROT_ALL, 0, curthread->td_ucred); >>> >>> /* No additional object reference for auto-deallocation upon unmapping. */ >>> #if __FreeBSD_version >= 1000055 >>> @@ -457,7 +458,8 @@ >>> return VERR_NO_MEMORY; >>> } >>> >>> - pMemFreeBSD->pObject = vm_object_allocate(OBJT_PHYS, atop(cb)); >>> + pMemFreeBSD->pObject = vm_pager_allocate(OBJT_PHYS, NULL, cb, VM_PROT_ALL, >>> + 0, curthread->td_ucred); >>> >>> if (PhysHighest != NIL_RTHCPHYS) >>> VmPhysAddrHigh = PhysHighest; >>> I tried a second time with the changes of your patch. This time, I patched files/patch-src_VBox_Runtime_r0drv_freebsd_memobj-r0drv-freebsd.c in emulators/virtualbox-ose (the main port). After rebuilding virtualbox-ose-kmod and virtualbox-ose and rebooting, I got some more info (lines at the beginning, numbered #6 to #13; lines #1 to #5 are outside of the frozen screen) and afterwards slightly different messages: [..snip..] #6 0xffffffff8255f756 at rtR0MemObjFreeBSDAllocHelper+0x96 #7 0xffffffff8255f8e0 at rtR0MemObjNativeAllocCont+0x50 #8 0xffffffff8253c7b7 at supdrvGipCreate+0x97 #9 0xffffffff8253519a at supdrvInitDevExt+0x19a #10 0xffffffff825450f6 at VBoxDrvFreeBSDModuleEvent+0x46 #11 0xffffffff80bb41fd at module_register_init+0xbd #12 0xffffffff80b6985c at mi_startup+0xec #13 0xffffffff8037002c at btext+0x2c Fatal trap 12: page fault while in kernel mode cpuid = 31; apic id = 1f fault virtual address = 0x25407efa fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff80ec0b63 stack pointer = 0x28:0xffffffff826018b0 frame pointer = 0x28:0xffffffff82601940 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) trap number = 12 panic: page fault cpuid = 31 time = 1 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffffff82601560 vpanic() at vpanic+0x182/frame 0xffffffff826015b0 panic() at panic+0x43/frame 0xffffffff82601610 trap_fatal() at trap_fatal+0x387/frame 0xffffffff82601670 trap_pfault() at trap_pfault+0x97/frame 0xffffffff826016d0 trap() at trap+0x2ab/frame 0xffffffff826017e0 calltrap() at calltrap+0x8/frame 0xffffffff826017e0 --- trap 0xc, rip = 0xffffffff80ec0b63, rsp = 0xffffffff826018b0, rbp = 0xffffffff82601940 --- vm_map_insert() at vm_map_insert+0x2f3/framw 0xffffffff82601940 vm_map_find() at vm_map_find+0x4a4/frame 0xffffffff82601a00 rtR0MemObjFreeBSDAllocHelper() at rtR0MemObjFreeBSDAllocHelper+0x96/frame 0xffffffff82601a70 rtR0MemObjNativeAllocCont() at rtR0MemObjNativeAllocCont+0x50/frame 0xffffffff82601ac0 supdrvGipCreate() at supdrvGipCreate+0x97/frame 0xffffffff82601b60 supdrvInitDevExt() at supdrvInitDevExt+0x19a/frame 0xffffffff82601bd0 VBoxDrvFreeBSDModuleEvent() at VBoxDrvFreeBSDModuleEvent+0x46/frame 0xffffffff82601bf0 module_register_init() at module_register_init+0xbd/frame 0xffffffff82601c20 mi_startup() at mi_startup+0xec/frame 0xffffffff82601c70 btext() at btext+0x2c KDB: enter: panic [ thread pid 0 tid 100000 ] Stopped at kdb_enter+0x37: movq $0,0x10b5616(%rip) db> Perhaps this gives some more insight into the problem? I can't assess, sorry. From owner-freebsd-current@freebsd.org Mon Sep 21 19:50: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 7EDE13FA716 for ; Mon, 21 Sep 2020 19:50:15 +0000 (UTC) (envelope-from news@mips.inka.de) Received: from mail.inka.de (mail.inka.de [IPv6:2a04:c9c7:0:1073:217:a4ff:fe3b:e77c]) (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) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BwFQs70Ftz3VpQ for ; Mon, 21 Sep 2020 19:50:13 +0000 (UTC) (envelope-from news@mips.inka.de) Received: from mips.inka.de (news@[127.0.0.1]) by mail.inka.de with uucp (rmailwrap 0.5) id 1kKRp6-00EaJa-T8; Mon, 21 Sep 2020 21:50:04 +0200 Received: from lorvorc.mips.inka.de (localhost [127.0.0.1]) by lorvorc.mips.inka.de (8.16.1/8.16.1) with ESMTP id 08LJnXLo020398 for ; Mon, 21 Sep 2020 21:49:33 +0200 (CEST) (envelope-from news@lorvorc.mips.inka.de) Received: (from news@localhost) by lorvorc.mips.inka.de (8.16.1/8.16.1/Submit) id 08LJnX5L020397 for freebsd-current@freebsd.org; Mon, 21 Sep 2020 21:49:33 +0200 (CEST) (envelope-from news) To: freebsd-current@freebsd.org From: Christian Weisgerber Newsgroups: list.freebsd.current Subject: Re: Plans for git Date: Mon, 21 Sep 2020 19:49:33 -0000 (UTC) Message-ID: References: <202009201400.08KE0PBd028190@gndrsh.dnsmgr.net> <13a965d9-ef02-f876-dd6c-aa872b66d114@nomadlogic.org> <20200921092159.Horde.yLakOjqLl4pZWCjCuYTfZVh@webmail.leidinger.net> User-Agent: slrn/1.0.3 (FreeBSD) X-Rspamd-Queue-Id: 4BwFQs70Ftz3VpQ X-Spamd-Bar: ++ X-Spamd-Result: default: False [2.27 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[news]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.55)[0.552]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[inka.de]; NEURAL_SPAM_MEDIUM(0.02)[0.019]; NEURAL_SPAM_LONG(0.50)[0.498]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[naddy@mips.inka.de,news@mips.inka.de]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:202113, ipnet:2a04:c9c7::/32, country:DE]; FROM_NEQ_ENVFROM(0.00)[naddy@mips.inka.de,news@mips.inka.de]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 21 Sep 2020 19:50:15 -0000 On 2020-09-21, Alexander Leidinger wrote: > In my opinion the people which drive this didn't keep it behind > closed curtains, and they went step by step more public, as they > made progress. To me it looks like now, that they have something > which is presentable to the world (and not only to committers), > they presented it to the world. Since I am one of the sad people who managed to miss all this public information, where can we find a summary of what's planned for the switch? -- Christian "naddy" Weisgerber naddy@mips.inka.de From owner-freebsd-current@freebsd.org Mon Sep 21 20:04:14 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 7EF073FAD78 for ; Mon, 21 Sep 2020 20:04:14 +0000 (UTC) (envelope-from rollingbits@gmail.com) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4BwFky1hdNz3Y9c for ; Mon, 21 Sep 2020 20:04:07 +0000 (UTC) (envelope-from rollingbits@gmail.com) Received: by mail-qt1-x82c.google.com with SMTP id 19so13565744qtp.1 for ; Mon, 21 Sep 2020 13:04:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=x5gO+LNV2WLZTzhKZlvEN/JvqGwkKc13tuM+54ekeXY=; b=P02xMhFgTEKRm4CsOZPnhqdK1sswLITuGlhSb763Awr5O3rR4cE6arVl4tehxsBI6H JvLEe/L7DFUJXMShrb5t0jY5yEwWLInVv5dFPQzrHyXAN5AGtSx7FzR5z/YAqxvn+/rZ xsdttGUW2m+Q5GzPK2upz/DTPCO29NcOMBdSTQnf0k+6tP3CS44U2oadDWwskZy2jPfc poOJA8UWMgGqnllz8v5W8BDI/ZTEXAHW5IOhxzXC8/SKhBUEO6OgVtPOEcjFUftXlZTG fYIUQkFu6rPNBCuUKDsUfXNn8C24zBEjHdFne16pPNzviCDgeS2uImnEJt+1AQD9gLCw RIug== X-Gm-Message-State: AOAM5332lmAsUDw6VdiIrSxGBcL3U5+nEeZfc9l92tuPeoH6SFOdvyJO Ga0E8wm5W+fJJ87UJoL5LWSyWAIzuxA= X-Google-Smtp-Source: ABdhPJwjF/zAGozFkr3+eXxuC8gt4Kij1KhBK+R8qgSUsaGbLmpU9b9dP4eXzarmbcWSZ1AjIEdGXw== X-Received: by 2002:ac8:5205:: with SMTP id r5mr1174628qtn.371.1600718643704; Mon, 21 Sep 2020 13:04:03 -0700 (PDT) Received: from localhost.localdomain ([2804:389:204c:6247:b11f:5748:9278:e946]) by smtp.gmail.com with ESMTPSA id e9sm10206880qkb.8.2020.09.21.13.04.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Sep 2020 13:04:03 -0700 (PDT) From: =?utf-8?Q?Lucas_Nali_de_Magalh=C3=A3es?= Mime-Version: 1.0 (1.0) Subject: Re: Plans for git Date: Mon, 21 Sep 2020 17:04:01 -0300 Message-Id: References: <20200921092159.Horde.yLakOjqLl4pZWCjCuYTfZVh@webmail.leidinger.net> Cc: freebsd-current@freebsd.org In-Reply-To: <20200921092159.Horde.yLakOjqLl4pZWCjCuYTfZVh@webmail.leidinger.net> To: Alexander Leidinger X-Mailer: iPhone Mail (18A373) X-Rspamd-Queue-Id: 4BwFky1hdNz3Y9c X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.17 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MV_CASE(0.50)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.29)[-0.291]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; R_MIXED_CHARSET(0.62)[subject]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.005]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::82c:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 21 Sep 2020 20:04:14 -0000 > On Sep 21, 2020, at 4:22 AM, Alexander Leidinger = wrote: >=20 > =EF=BB=BFQuoting Pete Wright (from Sun, 20 Sep 2020 0= 8:41:13 -0700): >=20 > Not responding to Pete directly, but in general to this topic with some pa= rts of what Pete considers good as something to hook into. >=20 >>>> making quarterly reports about this for almost a years as well. We put o= ut >>>> calls for people to help with the efforts about the same time. We have >>>> tried at every step of the way to be open and honest that this was goin= g to >>>> happen. >>> All developer centric communications.... >=20 > I fail to see why it is important to non-developers, which (D)VCS the deve= lopers of the product they use are using. (=E2=80=A6) I'm speaking only for myself but a change in (D)VCS used by FreeBSD changes t= he workflow I use when I use FreeBSD here internally. --=20 rollingbits =E2=80=94 =F0=9F=93=A7 rollingbits@gmail.com =F0=9F=93=A7 rollin= gbits@terra.com.br =F0=9F=93=A7 rollingbits@yahoo.com =F0=9F=93=A7 rollingbi= ts@globo.com =F0=9F=93=A7 rollingbits@icloud.com From owner-freebsd-current@freebsd.org Mon Sep 21 20:19: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 C54143FB6F6 for ; Mon, 21 Sep 2020 20:19:19 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from mail.nomadlogic.org (mail.nomadlogic.org [174.136.98.114]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.nomadlogic.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BwG4Q3NFKz3byT for ; Mon, 21 Sep 2020 20:19:18 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from [192.168.1.160] (cpe-23-243-161-111.socal.res.rr.com [23.243.161.111]) by mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id 47c7e7a2 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Mon, 21 Sep 2020 20:19:15 +0000 (UTC) Subject: Re: Plans for git To: Christian Weisgerber , freebsd-current@freebsd.org References: <202009201400.08KE0PBd028190@gndrsh.dnsmgr.net> <13a965d9-ef02-f876-dd6c-aa872b66d114@nomadlogic.org> <20200921092159.Horde.yLakOjqLl4pZWCjCuYTfZVh@webmail.leidinger.net> From: Pete Wright Message-ID: <37d9eb3b-642d-f324-3da3-03d198f5b5f1@nomadlogic.org> Date: Mon, 21 Sep 2020 13:19:15 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.2.2 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: 4BwG4Q3NFKz3byT X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.43 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.04)[-1.045]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[nomadlogic.org]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.11)[-0.106]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-0.98)[-0.984]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:25795, ipnet:174.136.96.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-current]; RECEIVED_SPAMHAUS_PBL(0.00)[23.243.161.111:received] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 21 Sep 2020 20:19:19 -0000 On 9/21/20 12:49 PM, Christian Weisgerber wrote: > On 2020-09-21, Alexander Leidinger wrote: > >> In my opinion the people which drive this didn't keep it behind >> closed curtains, and they went step by step more public, as they >> made progress. To me it looks like now, that they have something >> which is presentable to the world (and not only to committers), >> they presented it to the world. > Since I am one of the sad people who managed to miss all this public > information, where can we find a summary of what's planned for the > switch? > I believe the most detailed report on this was in the 2020-04 quarterly status report: https://www.freebsd.org/news/status/report-2020-04-2020-06.html#Git-Migration-Working-Group before this, work was mentioned in previous updates as part of the core teams status update.  there is also the freebsd-git@ mailing list here: https://lists.freebsd.org/pipermail/freebsd-git/ i don't subscribe to that list personally but i have checked the archives periodically when i have questions that pop up. hope this helps, -pete -- Pete Wright pete@nomadlogic.org @nomadlogicLA From owner-freebsd-current@freebsd.org Mon Sep 21 20:38: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 EF6A73FC4CA for ; Mon, 21 Sep 2020 20:38:40 +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 4BwGVm07Dgz3d60 for ; Mon, 21 Sep 2020 20:38:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: p4NRyOsVM1lNoNulVtF.IaApdxg_W5gCJ3B4F4wRStg.SIObeaeWIU4J54tim_L uD9ZWzBTOSgchCz3mKraj8BrdIXZnq07q9Hoxj7_NeWyYybgcCb5WC1CMpvKMhjcIuJLGI66tDy4 WqeTJsBskk.fMw0J4KdiLcVqt_NQh4uw9NCvWjlRShpW7uWykVFWVpEHhy8eIrHmxgzizIjqRCrd GBXQFt0xXgjRCS1UAas61SRRTkbyVEOA8gwmWwUMl41duxjb5jpM1q81FhqqbORWiDYe5Le6mZHp YSCtVVdIULZeAkr3dGIFLLfara1B.jYVVjgjQBC52A.IXK1sbcfCKp4ObKXhCE9KlPHAw8o0bUR8 XEcwQyXS49VgOs9tdmOWMegOuMlyC8sJl1TzuH.WWddNrJeo.GbZdr4Ts2zcko0EUbHMjbN_bVE3 LUBFNtufaEIh1N6QYZ7HVhwNkZGgMD8989l_W5LhL0FUgeYGU2lGTUdVwcLryHxc3hQir7IT2WFe EP0n2aw0bvjs_kitgctimojupHVZI7GjBb0EufjzrCaeJOIuQZ846ubiucFoHsIWFNm8nrSjDQMN SNJW39S9JdDP6PEh6wO5HTtjPqrUshJ7fxI6xe.xslkGkZMKrDEKXdQiLNs2wpdK.PYzHMZMzQo8 Cxr5pmKFa4.6ciMEy4qWE8L0piyiclPfg1OrZEMzs6X8jnkLtI8NAnbHfTnfpw7NT6Pbv_M5NoMG nvozKqgHAsADGpkzyH6sAzf8beExlrVPS6QmP0bQY9AaX_rNKPNY0ntUL4pVTotE8RX3hl29rQRO A0c2_BVETv2Az25vyjqDWvsKbpES9fcirqJuK42bbTsQ1RkJQu81m8ylD2yikMa2DYJvbytYSIcN .F9nhCsOaopzo2cywBplW6VMzlniFnwfJYjyykC.XipsdI33KY2v.eyEZSICCK4lNF5f6xFv7SSx P.w3yXwRejgFjm.BnT1L2stIMv9CaFXJPTvP2xLgR6_yL5lfv0kzMzWWZKUxV3js_Z2sy7Dgfr97 easyjEBhWmGY6R3Bd2_i3a1UM4Z0OsDaKUaNDjz6rx1O5.NwQrkGgiQUO_lHTCacy9z_fi4yYgSi G13S562Vddv6bLN12RcYGx3Cdp.._1nVVQcJdg.lFW.DYW_vaSdEiEzNTzHr.YQRKKyXsKKGhhZC 2Pkv68Z0ZY8LH.itX35mVuwhsYAQy2RY1qQCSqVqh40_qSoyafz5t0cdFe9LnfjUqAAMyz0llwKs CsoroznjbCVsyr7PGik4iHj7gHLhgKagUTvUNvkFimaWBqXb9e6weuLNtfEv6JZqatUoekMBbh21 zG2o0xLpxYucdJtnCP.AZiAqmqCx.0N_Pd2g.cI2GdAkM1.x7e7g7fJfWPgdgHzLrFWJnToW2Ehv LB.tfUpBUckJUknFll2wu8debrgZBJfs5_HFxH1J.SJXeA7fpfFYuhpW6p.rgu29sWhK.6XHB2dn 4255II_QpZBDBiorMXYvpiJiRG8DhUFLVcDPw3Ffv3QOJ4JWWT9grRd3ckTqWhKBXGetRv4YmX0O L3CwONXwtb8oMG6751Vp4 Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Mon, 21 Sep 2020 20:38:38 +0000 Received: by smtp418.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 11fc2baa759dbd6fc689ffb90a3f374e; Mon, 21 Sep 2020 20:38:35 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Subject: Odd diff -qr / /mnt "Only in " results Message-Id: <71A94120-99D0-4089-A790-0DEF28A1E091@yahoo.com> Date: Mon, 21 Sep 2020 13:38:33 -0700 To: FreeBSD Current X-Mailer: Apple Mail (2.3608.120.23.2.1) References: <71A94120-99D0-4089-A790-0DEF28A1E091.ref@yahoo.com> X-Rspamd-Queue-Id: 4BwGVm07Dgz3d60 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.74 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.24)[-0.236]; 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/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.979]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.02)[-1.022]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.205:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.205:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 21 Sep 2020 20:38:41 -0000 Context: head -r365932 (on a Rock64). But this could well not be new. First a look at the / context and then the /mnt/ : # ls -laT / total 225 drwxr-xr-x 24 root wheel 512 Sep 21 02:20:37 2020 . drwxr-xr-x 24 root wheel 512 Sep 21 02:20:37 2020 .. -rw-r--r-- 2 root wheel 1083 Jul 8 23:53:07 2020 .cshrc drwxr-xr-x 2 root wheel 512 Jan 31 19:57:35 2017 .libs -rw-r--r-- 1 root wheel 1349 Sep 15 18:45:26 2019 .profile -rw------- 1 root wheel 1024 Dec 31 16:00:41 2009 .rnd drwxrwxr-x 2 root operator 512 Aug 8 19:02:22 2020 .snap -r--r--r-- 1 root wheel 6170 Feb 1 04:48:34 2020 COPYRIGHT drwxr-xr-x 2 root wheel 1024 Sep 21 01:56:39 2020 bin drwxr-xr-x 24 root wheel 1536 Sep 21 01:58:43 2020 boot dr-xr-xr-x 18 root wheel 512 Sep 21 02:20:24 2020 dev -rw------- 1 root wheel 4096 Sep 21 02:20:37 2020 entropy drwxr-xr-x 27 root wheel 2560 Sep 21 01:58:16 2020 etc drwxr-xr-x 5 root wheel 2048 Sep 21 01:56:39 2020 lib drwxr-xr-x 3 root wheel 512 Sep 21 01:56:38 2020 libexec drwx------ 2 root wheel 98816 Jul 24 21:28:53 2020 lost+found drwxr-xr-x 2 root wheel 512 Mar 30 05:23:44 2020 media drwxr-xr-x 6 root wheel 512 Sep 21 01:49:57 2020 microsd_ufs drwxr-xr-x 23 root wheel 512 Mar 30 05:23:44 2020 mnt drwxr-xr-x 2 root wheel 512 Mar 30 05:23:44 2020 net dr-xr-xr-x 2 root wheel 512 Mar 30 05:23:44 2020 proc drwxr-xr-x 2 root wheel 2560 Sep 21 01:56:38 2020 rescue drwxr-xr-x 17 root wheel 2560 Mar 30 05:23:44 2020 root drwxr-xr-x 2 root wheel 2560 Sep 21 01:56:38 2020 sbin lrwxr-xr-x 1 root wheel 11 May 1 19:22:54 2018 sys -> usr/src/sys drwxrwxrwt 59 root wheel 3584 Sep 21 04:16:21 2020 tmp drwxr-xr-x 1 root wheel 16384 Dec 31 16:00:00 1979 usb_efi drwxr-xr-x 16 root wheel 512 Mar 30 05:23:44 2020 usr drwxr-xr-x 26 root wheel 512 Sep 21 02:20:36 2020 var drwxr-xr-x 3 root wheel 512 Sep 18 13:04:15 2018 wrkdirs # ls -laT /mnt total 120 drwxr-xr-x 23 root wheel 512 Mar 30 05:23:44 2020 . drwxr-xr-x 24 root wheel 512 Sep 21 02:20:37 2020 .. -rw-r--r-- 2 root wheel 1083 Jul 16 16:41:10 2020 .cshrc drwxr-xr-x 2 root wheel 512 Jan 31 19:57:35 2017 .libs -rw-r--r-- 1 root wheel 1349 Sep 15 18:45:26 2019 .profile -rw------- 1 root wheel 1024 Dec 31 16:00:41 2009 .rnd drwxrwxr-x 2 root operator 512 Mar 14 19:02:19 2020 .snap -r--r--r-- 1 root wheel 6170 Feb 1 04:48:34 2020 COPYRIGHT drwxr-xr-x 2 root wheel 1024 Sep 21 03:32:17 2020 bin drwxr-xr-x 13 root wheel 1024 Sep 21 03:32:17 2020 boot dr-xr-xr-x 2 root wheel 512 Mar 30 05:23:44 2020 dev -rw------- 1 root wheel 4096 Sep 13 14:02:57 2020 entropy drwxr-xr-x 27 root wheel 2560 Sep 21 03:36:49 2020 etc drwxr-xr-x 5 root wheel 2048 Sep 21 03:32:16 2020 lib drwxr-xr-x 3 root wheel 512 Sep 21 03:32:16 2020 libexec drwx------ 2 root wheel 512 Mar 17 16:16:42 2020 lost+found drwxr-xr-x 2 root wheel 512 Mar 30 05:23:44 2020 media drwxr-xr-x 2 root wheel 512 Mar 17 16:16:08 2020 microsd_ufs drwxr-xr-x 2 root wheel 512 Mar 30 05:23:44 2020 mnt drwxr-xr-x 2 root wheel 512 Mar 30 05:23:44 2020 net dr-xr-xr-x 2 root wheel 512 Mar 30 05:23:44 2020 proc drwxr-xr-x 2 root wheel 2560 Sep 21 03:32:16 2020 rescue drwxr-x--- 18 root wheel 2048 Mar 30 05:23:44 2020 root drwxr-xr-x 2 root wheel 2560 Sep 21 03:32:13 2020 sbin lrwxr-xr-x 1 root wheel 11 May 1 19:22:54 2018 sys -> usr/src/sys drwxrwxrwt 60 root wheel 5120 Mar 30 05:23:44 2020 tmp drwxr-xr-x 16 root wheel 512 Mar 30 05:23:44 2020 usr drwxr-xr-x 26 root wheel 512 Mar 30 05:23:44 2020 var drwxr-xr-x 3 root wheel 512 Sep 18 13:04:15 2018 wrkdirs # df -m Filesystem 1M-blocks Used Avail Capacity Mounted on /dev/gpt/Rock64root 195378 105474 74273 59% / devfs 0 0 0 100% /dev /dev/label/Rock64root 109101 362 100010 0% /microsd_ufs /dev/msdosfs/RPI4EFIFS 99 7 92 8% /usb_efi /dev/gpt/PINE642Groot 195378 76731 103016 43% /mnt But when I do the "diff -qr / /mnt" I get the following "Only in " notices: Only in /mnt: .cshrc Only in /mnt: .libs Only in /mnt: .profile Only in /mnt: .rnd Only in /mnt: .snap Only in /mnt: COPYRIGHT Only in /mnt: bin Only in /mnt: boot Only in /mnt: dev Only in /mnt: entropy Only in /mnt: etc Only in /mnt: lib Only in /mnt: libexec Only in /mnt: lost+found Only in /mnt: media Only in /mnt: microsd_ufs Only in /mnt: mnt Only in /mnt: net Only in /mnt: proc Only in /mnt: rescue Only in /mnt: sbin Only in /mnt: sys Only in /mnt: tmp Only in /mnt: usr Only in /mnt: var Only in /mnt: wrkdirs It still does the diff's inside the likes of /usr/ and /mnt/usr/ . This is not something that I normally do so I've no clue what range of versions do this. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Mon Sep 21 20:55: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 B99DF3FCA23 for ; Mon, 21 Sep 2020 20:55:16 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4BwGsv68qNz3f7B; Mon, 21 Sep 2020 20:55:15 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: by sdaoden.eu (Postfix, from userid 1000) id 57F4616057; Mon, 21 Sep 2020 22:55:07 +0200 (CEST) Date: Mon, 21 Sep 2020 22:54:30 +0200 From: Steffen Nurpmeso To: Lev Serebryakov Cc: Bakul Shah , Warner Losh , Zaphod Beeblebrox , Chris , Kristof Provost , FreeBSD Current Subject: Re: Plans for git Message-ID: <20200921205430.Q-2F-%steffen@sdaoden.eu> In-Reply-To: <23e7fc1c-6769-ceaf-4089-46e5cc575c20@FreeBSD.org> References: <20200902063136.GA47543@troutmask.apl.washington.edu> <20200902164706.GA49777@troutmask.apl.washington.edu> <5c89b4d27281f5dfffc3252a90013b0ac6c763d7.camel@freebsd.org> <5c832482-b2bc-47e4-8762-8f5a886d5f11@www.fastmail.com> <68585ca4-5ca4-40d3-b2f4-67ff3b35b6ae@www.fastmail.com> <0be2ae57d1c58e2091f4cc4484731df0@bsdforge.com> <967D73EA-880E-413D-B748-62A406C46524@FreeBSD.org> <9f89dc553e7d7b0884c2862329bdfeae@bsdforge.com> <23e7fc1c-6769-ceaf-4089-46e5cc575c20@FreeBSD.org> Mail-Followup-To: Lev Serebryakov , Bakul Shah , Warner Losh , Zaphod Beeblebrox , Chris , Kristof Provost , FreeBSD Current User-Agent: s-nail v14.9.19 OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. X-Rspamd-Queue-Id: 4BwGsv68qNz3f7B X-Spamd-Bar: - X-Spamd-Result: default: False [-2.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.02)[-1.017]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; NEURAL_HAM_LONG(-1.07)[-1.069]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sdaoden.eu]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.61)[-0.614]; RCPT_COUNT_SEVEN(0.00)[7]; MID_CONTAINS_FROM(1.00)[]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15987, ipnet:217.144.128.0/20, country:DE]; FREEMAIL_CC(0.00)[iitbombay.org,bsdimp.com,gmail.com,bsdforge.com,freebsd.org]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 21 Sep 2020 20:55:16 -0000 Lev Serebryakov wrote in <23e7fc1c-6769-ceaf-4089-46e5cc575c20@FreeBSD.org>: |On 19.09.2020 19:05, Bakul Shah wrote: |>> These are the main ones. The three down sides are lack of $FreeBSD$ \ |>> support |>> and tags in general. |> |> Can a git hook be used for this? | |git filters could be used for that, problem is it should be local config\ |uration. You could not configure filters in clones automatically :-( I do not think you can do that. Once i switched to git (2011 or a bit before) i even looked around for this, because i have been educated by BSD and used such tags everywhere, and found a thread with the Linus from where the elks live regarding this topic. I guess that $SHA-1$ git (supported by git by then) is the outcome of this thread, offered as a compromise. That mail thread exists. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From owner-freebsd-current@freebsd.org Mon Sep 21 21:31:03 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 3A5EC3FD592 for ; Mon, 21 Sep 2020 21:31:03 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4BwHgB1RHcz3gFm for ; Mon, 21 Sep 2020 21:31:01 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x72b.google.com with SMTP id v123so16843758qkd.9 for ; Mon, 21 Sep 2020 14:31:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=YMX5JebvYpkA3HZBqG1D/ChNhY21t4NwYuEfDIcuprY=; b=uBRzyPpD8btsmLOVNHZqAS8ENAGXh6ZjQJ8DwWrlk0b3KEQ7AUZxGCUMd/LRTogjmb 4lVt1aoXcvMEdUsJpRtmvMRPghZAqjzkc1z56BxY0l4TbAbO16o1d9DJYxhGnu76lyhh MfSYrI1ag6HiskckIVubh8GGJTCA+rdXm6LeC5AAnGH1pa7oLjCtXU1jOvcjd8bK1yXW iRz5+exBIPGBdVrybDnadIqTPyJE5Guh9NcUnoec//uhbv2XzqQ12EkvUgIZW073wKVk bwyz/uHbNGZMSImIGtuXVfBhMuXzICQBFsoN9CS76xByXBxUHAJMY9jl6XPcnnelGBVv YU5A== X-Gm-Message-State: AOAM531f+Cq140jAL3sWuCsseKDRX8OIvkym3v48y9IV9YH9McITX16i MhhZa48XPR5g9v/XC7IaGMTdrzVdQI1W6PO/1s6zYA== X-Google-Smtp-Source: ABdhPJw9lzPZCDCyrhGZ4XMninlUVtrq4qSVtg+cT5vjWlMEHY5Y4KtH6OrDrP4Dh5pEYSN2+2sUNMz+Ur3usZlI04o= X-Received: by 2002:ae9:f70d:: with SMTP id s13mr1896793qkg.215.1600723860672; Mon, 21 Sep 2020 14:31:00 -0700 (PDT) MIME-Version: 1.0 References: <20200902063136.GA47543@troutmask.apl.washington.edu> <20200902164706.GA49777@troutmask.apl.washington.edu> <5c89b4d27281f5dfffc3252a90013b0ac6c763d7.camel@freebsd.org> <5c832482-b2bc-47e4-8762-8f5a886d5f11@www.fastmail.com> <68585ca4-5ca4-40d3-b2f4-67ff3b35b6ae@www.fastmail.com> <0be2ae57d1c58e2091f4cc4484731df0@bsdforge.com> <967D73EA-880E-413D-B748-62A406C46524@FreeBSD.org> <9f89dc553e7d7b0884c2862329bdfeae@bsdforge.com> <23e7fc1c-6769-ceaf-4089-46e5cc575c20@FreeBSD.org> <20200921205430.Q-2F-%steffen@sdaoden.eu> In-Reply-To: <20200921205430.Q-2F-%steffen@sdaoden.eu> From: Warner Losh Date: Mon, 21 Sep 2020 15:30:49 -0600 Message-ID: Subject: Re: Plans for git To: Lev Serebryakov , Bakul Shah , Warner Losh , Zaphod Beeblebrox , Chris , Kristof Provost , FreeBSD Current X-Rspamd-Queue-Id: 4BwHgB1RHcz3gFm X-Spamd-Bar: / X-Spamd-Result: default: False [-0.80 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-0.80)[-0.804]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.98)[0.979]; NEURAL_HAM_LONG(-0.97)[-0.971]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCPT_COUNT_SEVEN(0.00)[7]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::72b:from]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_TO(0.00)[freebsd.org,iitbombay.org,bsdimp.com,gmail.com,bsdforge.com]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; MAILMAN_DEST(0.00)[freebsd-current] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 21 Sep 2020 21:31:03 -0000 On Mon, Sep 21, 2020 at 2:55 PM Steffen Nurpmeso wrote: > Lev Serebryakov wrote in > <23e7fc1c-6769-ceaf-4089-46e5cc575c20@FreeBSD.org>: > |On 19.09.2020 19:05, Bakul Shah wrote: > |>> These are the main ones. The three down sides are lack of $FreeBSD$ \ > |>> support > |>> and tags in general. > |> > |> Can a git hook be used for this? > | > |git filters could be used for that, problem is it should be local config\ > |uration. You could not configure filters in clones automatically :-( > > I do not think you can do that. Once i switched to git (2011 or > a bit before) i even looked around for this, because i have been > educated by BSD and used such tags everywhere, and found a thread > with the Linus from where the elks live regarding this topic. > I guess that $SHA-1$ git (supported by git by then) is the outcome > of this thread, offered as a compromise. That mail thread exists. > It's documented to be the hash of the blob, not the hash of the commit., which makes it basically useless for our purposes... Warner From owner-freebsd-current@freebsd.org Mon Sep 21 21:55:10 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 143B83FE205 for ; Mon, 21 Sep 2020 21:55:10 +0000 (UTC) (envelope-from news@mips.inka.de) Received: from mail.inka.de (mail.inka.de [IPv6:2a04:c9c7:0:1073:217:a4ff:fe3b:e77c]) (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) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BwJC02DbDz3yfb for ; Mon, 21 Sep 2020 21:55:07 +0000 (UTC) (envelope-from news@mips.inka.de) Received: from mips.inka.de (news@[127.0.0.1]) by mail.inka.de with uucp (rmailwrap 0.5) id 1kKTm5-00EcrR-8x; Mon, 21 Sep 2020 23:55:05 +0200 Received: from lorvorc.mips.inka.de (localhost [127.0.0.1]) by lorvorc.mips.inka.de (8.16.1/8.16.1) with ESMTP id 08LLt0rc023240 for ; Mon, 21 Sep 2020 23:55:00 +0200 (CEST) (envelope-from news@lorvorc.mips.inka.de) Received: (from news@localhost) by lorvorc.mips.inka.de (8.16.1/8.16.1/Submit) id 08LLt0cN023239 for freebsd-current@freebsd.org; Mon, 21 Sep 2020 23:55:00 +0200 (CEST) (envelope-from news) To: freebsd-current@freebsd.org From: Christian Weisgerber Newsgroups: list.freebsd.current Subject: Re: Plans for git Date: Mon, 21 Sep 2020 21:55:00 -0000 (UTC) Message-ID: References: <202009201400.08KE0PBd028190@gndrsh.dnsmgr.net> <13a965d9-ef02-f876-dd6c-aa872b66d114@nomadlogic.org> <20200921092159.Horde.yLakOjqLl4pZWCjCuYTfZVh@webmail.leidinger.net> <37d9eb3b-642d-f324-3da3-03d198f5b5f1@nomadlogic.org> User-Agent: slrn/1.0.3 (FreeBSD) X-Rspamd-Queue-Id: 4BwJC02DbDz3yfb X-Spamd-Bar: ++ X-Spamd-Result: default: False [2.02 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[news]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.37)[0.366]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[inka.de]; NEURAL_SPAM_MEDIUM(0.02)[0.023]; NEURAL_SPAM_LONG(0.43)[0.433]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[naddy@mips.inka.de,news@mips.inka.de]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:202113, ipnet:2a04:c9c7::/32, country:DE]; FROM_NEQ_ENVFROM(0.00)[naddy@mips.inka.de,news@mips.inka.de]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 21 Sep 2020 21:55:10 -0000 On 2020-09-21, Pete Wright wrote: > I believe the most detailed report on this was in the 2020-04 quarterly > status report: > https://www.freebsd.org/news/status/report-2020-04-2020-06.html#Git-Migration-Working-Group I saw that at the time. It basically says that the conversion of the repository is feasible. > there is also the freebsd-git@ mailing list here: > https://lists.freebsd.org/pipermail/freebsd-git/ Well, I was asking for a summary. For instance, I don't know if the Git migration is merely a switch of the version control system or what other changes will be layered on top of it as a matter of course, e.g. will the development infrastructure move to GitHub? Don't answer that, just point me to the information. -- Christian "naddy" Weisgerber naddy@mips.inka.de From owner-freebsd-current@freebsd.org Mon Sep 21 22:13: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 AB6943FE837 for ; Mon, 21 Sep 2020 22:13:48 +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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BwJcW4JGTz40sX; Mon, 21 Sep 2020 22:13:47 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 08LMDURk080129 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 22 Sep 2020 01:13:33 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 08LMDURk080129 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 08LMDTMO080128; Tue, 22 Sep 2020 01:13:29 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 22 Sep 2020 01:13:29 +0300 From: Konstantin Belousov To: rhurlin@freebsd.org Cc: Hans Petter Selasky , monochrome , freebsd-current@freebsd.org Subject: Re: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X Message-ID: <20200921221329.GD2570@kib.kiev.ua> References: <88af31d4-9ed9-172a-d48f-1780f19841e3@twcny.rr.com> <11d27d41-029a-d7f5-eccc-0ba3a3fcfe97@gwdg.de> <2bbfb4b3-92e9-b3ca-9c31-6c513cee2f2d@gwdg.de> <20200920093814.GD94807@kib.kiev.ua> <0249197f-29f6-4df4-eb63-ca786aaea39d@gwdg.de> <20200920195526.GH94807@kib.kiev.ua> <20200920200735.GJ94807@kib.kiev.ua> <1621df05-35a9-92b9-ffee-d93c17110d87@gwdg.de> <2673660d-3a6e-97c9-82a2-17b5ab8b987b@gwdg.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2673660d-3a6e-97c9-82a2-17b5ab8b987b@gwdg.de> 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: 4BwJcW4JGTz40sX X-Spamd-Bar: / X-Spamd-Result: default: False [-0.50 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.03)[-0.034]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_HAM_LONG(-0.83)[-0.831]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; NEURAL_SPAM_SHORT(0.36)[0.365]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MIME_TRACE(0.00)[0:+]; MAILMAN_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 21 Sep 2020 22:13:48 -0000 On Mon, Sep 21, 2020 at 08:57:46PM +0200, Rainer Hurling wrote: > Fatal trap 12: page fault while in kernel mode > cpuid = 31; apic id = 1f > fault virtual address = 0x25407efa This address is very suspicious. I cannot claim it as the fact, but most likely cause for such garbage pointer value is mismatched ABI between kernel and module. In other words, the module was built against headers from different kernel. > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff80ec0b63 > stack pointer = 0x28:0xffffffff826018b0 > frame pointer = 0x28:0xffffffff82601940 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 0 (swapper) > trap number = 12 > panic: page fault > cpuid = 31 > time = 1 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > 0xffffffff82601560 > vpanic() at vpanic+0x182/frame 0xffffffff826015b0 > panic() at panic+0x43/frame 0xffffffff82601610 > trap_fatal() at trap_fatal+0x387/frame 0xffffffff82601670 > trap_pfault() at trap_pfault+0x97/frame 0xffffffff826016d0 > trap() at trap+0x2ab/frame 0xffffffff826017e0 > calltrap() at calltrap+0x8/frame 0xffffffff826017e0 > --- trap 0xc, rip = 0xffffffff80ec0b63, rsp = 0xffffffff826018b0, rbp = > 0xffffffff82601940 --- > vm_map_insert() at vm_map_insert+0x2f3/framw 0xffffffff82601940 > vm_map_find() at vm_map_find+0x4a4/frame 0xffffffff82601a00 > rtR0MemObjFreeBSDAllocHelper() at > rtR0MemObjFreeBSDAllocHelper+0x96/frame 0xffffffff82601a70 > rtR0MemObjNativeAllocCont() at rtR0MemObjNativeAllocCont+0x50/frame > 0xffffffff82601ac0 > supdrvGipCreate() at supdrvGipCreate+0x97/frame 0xffffffff82601b60 > supdrvInitDevExt() at supdrvInitDevExt+0x19a/frame 0xffffffff82601bd0 > VBoxDrvFreeBSDModuleEvent() at VBoxDrvFreeBSDModuleEvent+0x46/frame > 0xffffffff82601bf0 > module_register_init() at module_register_init+0xbd/frame 0xffffffff82601c20 > mi_startup() at mi_startup+0xec/frame 0xffffffff82601c70 > btext() at btext+0x2c > KDB: enter: panic > [ thread pid 0 tid 100000 ] > Stopped at kdb_enter+0x37: movq $0,0x10b5616(%rip) > db> > > > Perhaps this gives some more insight into the problem? I can't assess, > sorry. From owner-freebsd-current@freebsd.org Mon Sep 21 22:31: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 7E3BA3FF0B9 for ; Mon, 21 Sep 2020 22:31:39 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4BwK163ZNrz42rM; Mon, 21 Sep 2020 22:31:38 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: by sdaoden.eu (Postfix, from userid 1000) id C86F816057; Tue, 22 Sep 2020 00:31:36 +0200 (CEST) Date: Tue, 22 Sep 2020 00:31:36 +0200 From: Steffen Nurpmeso To: Warner Losh Cc: Lev Serebryakov , Bakul Shah , Zaphod Beeblebrox , Chris , Kristof Provost , FreeBSD Current Subject: Re: Plans for git Message-ID: <20200921223136.SxZL3%steffen@sdaoden.eu> In-Reply-To: References: <20200902063136.GA47543@troutmask.apl.washington.edu> <20200902164706.GA49777@troutmask.apl.washington.edu> <5c89b4d27281f5dfffc3252a90013b0ac6c763d7.camel@freebsd.org> <5c832482-b2bc-47e4-8762-8f5a886d5f11@www.fastmail.com> <68585ca4-5ca4-40d3-b2f4-67ff3b35b6ae@www.fastmail.com> <0be2ae57d1c58e2091f4cc4484731df0@bsdforge.com> <967D73EA-880E-413D-B748-62A406C46524@FreeBSD.org> <9f89dc553e7d7b0884c2862329bdfeae@bsdforge.com> <23e7fc1c-6769-ceaf-4089-46e5cc575c20@FreeBSD.org> <20200921205430.Q-2F-%steffen@sdaoden.eu> Mail-Followup-To: Warner Losh , Lev Serebryakov , Bakul Shah , Zaphod Beeblebrox , Chris , Kristof Provost , FreeBSD Current User-Agent: s-nail v14.9.19 OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. X-Rspamd-Queue-Id: 4BwK163ZNrz42rM X-Spamd-Bar: - X-Spamd-Result: default: False [-1.43 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.01)[-1.013]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+a:c]; NEURAL_HAM_LONG(-1.07)[-1.072]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sdaoden.eu]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.04)[-0.042]; RCPT_COUNT_SEVEN(0.00)[7]; MID_CONTAINS_FROM(1.00)[]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15987, ipnet:217.144.128.0/20, country:DE]; FREEMAIL_CC(0.00)[freebsd.org,iitbombay.org,gmail.com,bsdforge.com]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 21 Sep 2020 22:31:39 -0000 Warner Losh wrote in : |On Mon, Sep 21, 2020 at 2:55 PM Steffen Nurpmeso \ |wrote: |> Lev Serebryakov wrote in |> <23e7fc1c-6769-ceaf-4089-46e5cc575c20@FreeBSD.org>: |>|On 19.09.2020 19:05, Bakul Shah wrote: |>|>> These are the main ones. The three down sides are lack of $FreeBSD$ \ |>|>> support |>|>> and tags in general. |>|> |>|> Can a git hook be used for this? |>| |>|git filters could be used for that, problem is it should be local config\ |>|uration. You could not configure filters in clones automatically :-( |> |> I do not think you can do that. Once i switched to git (2011 or |> a bit before) i even looked around for this, because i have been |> educated by BSD and used such tags everywhere, and found a thread |> with the Linus from where the elks live regarding this topic. |> I guess that $SHA-1$ git (supported by git by then) is the outcome |> of this thread, offered as a compromise. That mail thread exists. |> | |It's documented to be the hash of the blob, not the hash of the commit., |which makes it basically useless for our purposes... Never used that. Even if it requires additional tooling and/or the repository, whereas the BSD way is that you can take such a freely licensed file, include it somewhere, and strings(1) etc. still gives you an immediately human graspable output. I mean, if the project agrees by policy then of course the master copy at freebsd.org can expand such things when commits are merged. There are now also many more hooks available, in fact i have no idea of what i am talking about ^_^ --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From owner-freebsd-current@freebsd.org Mon Sep 21 22:36: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 1E28F3FF657 for ; Mon, 21 Sep 2020 22:36:48 +0000 (UTC) (envelope-from doctorwhoguy@gmail.com) Received: from mail-ej1-x642.google.com (mail-ej1-x642.google.com [IPv6:2a00:1450:4864:20::642]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4BwK732Y4Gz43V2 for ; Mon, 21 Sep 2020 22:36:47 +0000 (UTC) (envelope-from doctorwhoguy@gmail.com) Received: by mail-ej1-x642.google.com with SMTP id q13so20013629ejo.9 for ; Mon, 21 Sep 2020 15:36:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=YDV+ZXBN3TAmLITFa5iVYLSxA8RZVNzPoOK3x+qN1SM=; b=hypV91VretvZhYnC4QKDGF1DC0eeYVZM8X2pIAoSeqpoCflFdgUiAVHSNRSGHBDLZH 1qb5iCu71JRXoW5r/ZMYlNVK451L1iEFSmYeZzTbE+ATMFQYEuzvC55q30Qv8cYwh9Ur ObHBHHQEWcTMLLse0FUUNar37+zJ7tUe7pB9f0KpL4gTLdnde9x1gqvSMHY5nEWQ1dPz /0TWmlARUUUwRy7C/X4q7kMa+bB9r0A34r/Kh/e9EThLOvMGwoqTYCmOSwtC1Zz2MhJQ ztT92iE8LFlvlFVgSEVUbKqXsIKbPZ61J3MXq3RVD2q+xa8NUG/L0hDsezOjUfvMGwyY EMkA== X-Gm-Message-State: AOAM533aZkguO/oH0gHaHVSKAdk3hz73O7y94PLkOuw4FZDBMBWEdZVO 19flCKls7OjGKccwtsoT0M4hplTitrdGTjLAkrj5aZC3plY= X-Google-Smtp-Source: ABdhPJxpI5CiITqSLPHeU/jijkZj3MYw0v1m+HQS4jlQW+HMZqPBlZPy9hITYhbQ4dbTOoYP8njx8XGnIfqcSbvBel4= X-Received: by 2002:a17:906:6411:: with SMTP id d17mr1707367ejm.93.1600727805125; Mon, 21 Sep 2020 15:36:45 -0700 (PDT) MIME-Version: 1.0 From: Patrick McMunn Date: Mon, 21 Sep 2020 17:36:33 -0500 Message-ID: Subject: Can't forward X11 apps over ssh since migrating to 13-CURRENT To: freebsd-current@freebsd.org X-Rspamd-Queue-Id: 4BwK732Y4Gz43V2 X-Spamd-Bar: / X-Spamd-Result: default: False [-0.96 / 15.00]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; TO_DN_NONE(0.00)[]; URI_COUNT_ODD(1.00)[1]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.01)[-0.008]; 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]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.94)[-0.943]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.01)[-1.005]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::642:from]; HTTP_TO_IP(1.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 21 Sep 2020 22:36:48 -0000 I don't know if it's just coincidental or if it's because of some change in 13-CURRENT, but I recently migrated from 12.1-STABLE, and now I am unable to forward X11 apps over ssh. The only app I was accustomed to running this way was Handbrake. It worked fine before, but now i get this: $ ghb Unable to init server: Could not connect to 127.0.0.1: Connection refused (ghb:87219): Gtk-WARNING **: 13:12:41.281: cannot open display: I have tried other apps like Wireshark and even xclock just to see, but they won't work either. Has anyone else had problems with X11 forwarding on 13-CURRENT? If it's working for everyone else, at least I can know it's probably not 13-CURRENT's fault, and I need to look elsewhere for the cause. And yes, my sshd_config has it enabled. It worked fine before, and I made sure to keep the same config. From owner-freebsd-current@freebsd.org Mon Sep 21 22:48: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 C23C4421004 for ; Mon, 21 Sep 2020 22:48:58 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4BwKP56Vbcz44XC for ; Mon, 21 Sep 2020 22:48:57 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: by mail-ej1-x62f.google.com with SMTP id o8so20056267ejb.10 for ; Mon, 21 Sep 2020 15:48:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=7dTVMDHmlIjn449q1/ozCR4vO8isRH0k9yhuPwnFOYM=; b=gV8FSPAKBULhVqAr0Ue7e/I5JuZhKpPFvd+zs+rv1Aw9hbEWrvMAO3szAPTEr/832d naopx+hXZ9276n+G38rYafxBvCA/RNajkflfEUZIWxeVMQILECcsvvlLSY0z6R6/FUEQ LDhkjZY9Lq6R23MkKAibieeeJ0dsQBFO9i8j8R4AMd5Kjdevt1SP/arh7FkeblzZZXar MrtVjm2zOoKhPKDgvSF/4d3HsNAsTwP2c5ggsATfPOUas68RLFjw6mbOzCbAB42YUGa/ HeEyIg2A6PR1B0xJO4bwAmWnzoVBp0VdrD1abSEgZM1abEt9qNjpkf660+Of4RNCwPCb r9Yw== X-Gm-Message-State: AOAM532sGYnj/ZCi0mzUjYGm3eoa4WUhHKsF0738yR33+rRg1pjYJS8g ld7tazDG9G9LoKU9WHDy1G2nxO8KJeHt4GGhnlov/UUcIH9bXw== X-Google-Smtp-Source: ABdhPJwRdCkhPjzAH4jiIBgMwmBhNJrjOX6SdLaMZjlmM+WSouyCOkrCuune+rhXOan8NhHONAg+NszjPNO2Dp+59B4= X-Received: by 2002:a17:906:724b:: with SMTP id n11mr1812356ejk.328.1600728536468; Mon, 21 Sep 2020 15:48:56 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a54:2348:0:0:0:0:0 with HTTP; Mon, 21 Sep 2020 15:48:56 -0700 (PDT) In-Reply-To: References: From: grarpamp Date: Mon, 21 Sep 2020 18:48:56 -0400 Message-ID: Subject: Re: Can't forward X11 apps over ssh since migrating to 13-CURRENT To: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4BwKP56Vbcz44XC X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.28 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.984]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; RCVD_TLS_ALL(0.00)[]; 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)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.003]; 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)[2a00:1450:4864:20::62f:from]; NEURAL_HAM_SHORT(-0.30)[-0.295]; 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]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-current]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 21 Sep 2020 22:48:58 -0000 Possibly check ForwardX11Timeout . From owner-freebsd-current@freebsd.org Mon Sep 21 23:16: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 D0B26421A40 for ; Mon, 21 Sep 2020 23:16:50 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-55.consmr.mail.gq1.yahoo.com (sonic315-55.consmr.mail.gq1.yahoo.com [98.137.65.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 4BwL1F6qvgz46TP for ; Mon, 21 Sep 2020 23:16:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: L3mQgUkVM1nbJh7cRUT2SHDcJ_1ZJ7zSyKWWobEDMyjAJ2kKj9KIKvMcQgwFjhN 9IOWqrGdGzQMRfRHfC1sxR43VhfIZJtpHjoKWdTS0J0Mll8eAVBNl4a8iC7qse1itTibLsM7htDT QsWi9VUwPkngc48mnhXpIEvEYQ70yZLDFK5UiWTNnFSocvCI9PyJl1qM24fV31KqMLZ6mm.NdDFl BSyr3y1XpqFoJOlU8.o5ejgwPWAdAqoLO4QU9LYQCyLQqPz9rB68aoI9DYzo1waGB4b8F4JaYSIe _cEeH964qHn4Nqr7pQhMWjx9DliPxkf3VpYmxIWllmWbdlLaWnMYUbWODShkmXwDgtd1MsJHYBk0 kYFQyTv2VhuqP8.HdK7R0PkloECoIetNR1fRTmmsa7xygyXCUw.gFb5Xlaq1.5TwM9wers8PN6Xq V5usnEHU0Sb3L6yhT__sP42obAPa_9SuG8U1XAYnznSfu.58W9Gb4x7gTxroxVNrCckSChHUuEf4 QhGvlkcmPb0D_9WAseVbMYVjtv28CKr3dsJKjqTuIg4vf3bZyjZssuSVQXZkGs1oWfsBIkKxUXnS EvNVtuIU_EKa6u.PW1alE9oLFctpmpZ_TDQH58Qz6uMJtHqt2f5fMwES.GF30DuvTgWZsYmdEeya T8zJRMvl_KMX9GibVEotBkCuWbDFDZEEvs51XJoaNvP.HaeK8bTv5lEkjBrnsFti6OcmTMNt.JPD qVPNKctH3ZlQZTEOV7Vvz0U8bRL0Db.JI8LjUubtDygQVkxEcoKVwdXB6xg41NvohXrN7MJFH.qO Sv54nNbZMPIzU0umnatdbDmebnqqG08xA3Y1Z7Irhiwt67qdxWkbjr3xc0gTU5GhYLmzzie2rsdV Tzf_mfqT3X1S.vKoYmaEgVpxUIs3RzL6tWGleRSbhSCxNEfOjtjYGVTdu9s2AAoSLJerZLzbJft6 3uxAgADoUfbI9ksfk4Vg3AIbFi2YFlXtunGzHZyTM2eXW1BXNpRBYbSdZUL121UVIwEsLpkFd38H Oav9KH5w_tb.xaKiOpgvdHk4DwyL9s9ItLEWiiTvqMfDKh1vgzWrO.f_vauhlKiKcnCeZ4vRz35W QgIIu0p4uFhyPboUc6jHWtPF9WY.zSfyN3qthlMQAbzFt.zwvi.o7T6D2ndOjLMzzwieAMOLtynC UETfryjMawngdUNpvMEezM1WAIn8AfV4Cmz_k54M8TXuHWuhHb0QsCfgqMYrBwfbA_bc2AYacsao PuTkqYKSaEli7HUWEAFmB.KXw81lBGUyjhYPLOPv72ixix03cppNTbJMPhLTX3xATtK4XvVDPmS3 7QOVP_wN.ciMDXI9tgOrCrvkmH6yCy9UEIPv6XxL_4yUqfmXeFpGtjhKTCPLqCDvsRsbgg67TACx zqedVJLE0A4P0J.1syGhhK7U943h_bNpZsNxUU0iRjTJn08bnZyOCtcH4_CyMuIm308TSW3ENijr onkh11EehPXDqSOP1Xm.wOKxlSJTumvSmiWHNxX2sUjERUCUtiKly9t5iBJg- Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Mon, 21 Sep 2020 23:16:47 +0000 Received: by smtp413.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 06fc43210638eb70aef612bfcb64855d; Mon, 21 Sep 2020 23:16:43 +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.4 \(3608.120.23.2.1\)) Subject: Re: Odd diff -qr / /mnt "Only in " results Date: Mon, 21 Sep 2020 16:16:41 -0700 References: <71A94120-99D0-4089-A790-0DEF28A1E091@yahoo.com> To: FreeBSD Current In-Reply-To: <71A94120-99D0-4089-A790-0DEF28A1E091@yahoo.com> Message-Id: X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Rspamd-Queue-Id: 4BwL1F6qvgz46TP X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.11 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.61)[-0.608]; 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/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.979]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.02)[-1.022]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.31:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.31:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 21 Sep 2020 23:16:50 -0000 On 2020-Sep-21, at 13:38, Mark Millard wrote: > Context: head -r365932 (on a Rock64). But this could well not > be new. >=20 > First a look at the / context and then the /mnt/ : >=20 > # ls -laT / > total 225 > drwxr-xr-x 24 root wheel 512 Sep 21 02:20:37 2020 . > drwxr-xr-x 24 root wheel 512 Sep 21 02:20:37 2020 .. > -rw-r--r-- 2 root wheel 1083 Jul 8 23:53:07 2020 .cshrc > drwxr-xr-x 2 root wheel 512 Jan 31 19:57:35 2017 .libs > -rw-r--r-- 1 root wheel 1349 Sep 15 18:45:26 2019 .profile > -rw------- 1 root wheel 1024 Dec 31 16:00:41 2009 .rnd > drwxrwxr-x 2 root operator 512 Aug 8 19:02:22 2020 .snap > -r--r--r-- 1 root wheel 6170 Feb 1 04:48:34 2020 COPYRIGHT > drwxr-xr-x 2 root wheel 1024 Sep 21 01:56:39 2020 bin > drwxr-xr-x 24 root wheel 1536 Sep 21 01:58:43 2020 boot > dr-xr-xr-x 18 root wheel 512 Sep 21 02:20:24 2020 dev > -rw------- 1 root wheel 4096 Sep 21 02:20:37 2020 entropy > drwxr-xr-x 27 root wheel 2560 Sep 21 01:58:16 2020 etc > drwxr-xr-x 5 root wheel 2048 Sep 21 01:56:39 2020 lib > drwxr-xr-x 3 root wheel 512 Sep 21 01:56:38 2020 libexec > drwx------ 2 root wheel 98816 Jul 24 21:28:53 2020 lost+found > drwxr-xr-x 2 root wheel 512 Mar 30 05:23:44 2020 media > drwxr-xr-x 6 root wheel 512 Sep 21 01:49:57 2020 microsd_ufs > drwxr-xr-x 23 root wheel 512 Mar 30 05:23:44 2020 mnt > drwxr-xr-x 2 root wheel 512 Mar 30 05:23:44 2020 net > dr-xr-xr-x 2 root wheel 512 Mar 30 05:23:44 2020 proc > drwxr-xr-x 2 root wheel 2560 Sep 21 01:56:38 2020 rescue > drwxr-xr-x 17 root wheel 2560 Mar 30 05:23:44 2020 root > drwxr-xr-x 2 root wheel 2560 Sep 21 01:56:38 2020 sbin > lrwxr-xr-x 1 root wheel 11 May 1 19:22:54 2018 sys -> = usr/src/sys > drwxrwxrwt 59 root wheel 3584 Sep 21 04:16:21 2020 tmp > drwxr-xr-x 1 root wheel 16384 Dec 31 16:00:00 1979 usb_efi > drwxr-xr-x 16 root wheel 512 Mar 30 05:23:44 2020 usr > drwxr-xr-x 26 root wheel 512 Sep 21 02:20:36 2020 var > drwxr-xr-x 3 root wheel 512 Sep 18 13:04:15 2018 wrkdirs >=20 > # ls -laT /mnt > total 120 > drwxr-xr-x 23 root wheel 512 Mar 30 05:23:44 2020 . > drwxr-xr-x 24 root wheel 512 Sep 21 02:20:37 2020 .. > -rw-r--r-- 2 root wheel 1083 Jul 16 16:41:10 2020 .cshrc > drwxr-xr-x 2 root wheel 512 Jan 31 19:57:35 2017 .libs > -rw-r--r-- 1 root wheel 1349 Sep 15 18:45:26 2019 .profile > -rw------- 1 root wheel 1024 Dec 31 16:00:41 2009 .rnd > drwxrwxr-x 2 root operator 512 Mar 14 19:02:19 2020 .snap > -r--r--r-- 1 root wheel 6170 Feb 1 04:48:34 2020 COPYRIGHT > drwxr-xr-x 2 root wheel 1024 Sep 21 03:32:17 2020 bin > drwxr-xr-x 13 root wheel 1024 Sep 21 03:32:17 2020 boot > dr-xr-xr-x 2 root wheel 512 Mar 30 05:23:44 2020 dev > -rw------- 1 root wheel 4096 Sep 13 14:02:57 2020 entropy > drwxr-xr-x 27 root wheel 2560 Sep 21 03:36:49 2020 etc > drwxr-xr-x 5 root wheel 2048 Sep 21 03:32:16 2020 lib > drwxr-xr-x 3 root wheel 512 Sep 21 03:32:16 2020 libexec > drwx------ 2 root wheel 512 Mar 17 16:16:42 2020 lost+found > drwxr-xr-x 2 root wheel 512 Mar 30 05:23:44 2020 media > drwxr-xr-x 2 root wheel 512 Mar 17 16:16:08 2020 microsd_ufs > drwxr-xr-x 2 root wheel 512 Mar 30 05:23:44 2020 mnt > drwxr-xr-x 2 root wheel 512 Mar 30 05:23:44 2020 net > dr-xr-xr-x 2 root wheel 512 Mar 30 05:23:44 2020 proc > drwxr-xr-x 2 root wheel 2560 Sep 21 03:32:16 2020 rescue > drwxr-x--- 18 root wheel 2048 Mar 30 05:23:44 2020 root > drwxr-xr-x 2 root wheel 2560 Sep 21 03:32:13 2020 sbin > lrwxr-xr-x 1 root wheel 11 May 1 19:22:54 2018 sys -> = usr/src/sys > drwxrwxrwt 60 root wheel 5120 Mar 30 05:23:44 2020 tmp > drwxr-xr-x 16 root wheel 512 Mar 30 05:23:44 2020 usr > drwxr-xr-x 26 root wheel 512 Mar 30 05:23:44 2020 var > drwxr-xr-x 3 root wheel 512 Sep 18 13:04:15 2018 wrkdirs >=20 > # df -m > Filesystem 1M-blocks Used Avail Capacity Mounted on > /dev/gpt/Rock64root 195378 105474 74273 59% / > devfs 0 0 0 100% /dev > /dev/label/Rock64root 109101 362 100010 0% /microsd_ufs > /dev/msdosfs/RPI4EFIFS 99 7 92 8% /usb_efi > /dev/gpt/PINE642Groot 195378 76731 103016 43% /mnt >=20 >=20 > But when I do the "diff -qr / /mnt" I get the following "Only in " > notices: >=20 > Only in /mnt: .cshrc > Only in /mnt: .libs > Only in /mnt: .profile > Only in /mnt: .rnd > Only in /mnt: .snap > Only in /mnt: COPYRIGHT > Only in /mnt: bin > Only in /mnt: boot > Only in /mnt: dev > Only in /mnt: entropy > Only in /mnt: etc > Only in /mnt: lib > Only in /mnt: libexec > Only in /mnt: lost+found > Only in /mnt: media > Only in /mnt: microsd_ufs > Only in /mnt: mnt > Only in /mnt: net > Only in /mnt: proc > Only in /mnt: rescue > Only in /mnt: sbin > Only in /mnt: sys > Only in /mnt: tmp > Only in /mnt: usr > Only in /mnt: var > Only in /mnt: wrkdirs >=20 > It still does the diff's inside the likes of /usr/ and /mnt/usr/ . Well, after the complete diff I went looking in places that I had expected a few differences to show (but did not). I found some files with differences. So it appears that at least some of those "Only in " notices did result in lack of comparisons in the areas reported. > This is not something that I normally do so I've no clue what range > of versions do this. >=20 =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 Sep 22 00:03: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 66C1B42298B for ; Tue, 22 Sep 2020 00:03:54 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-8.consmr.mail.gq1.yahoo.com (sonic308-8.consmr.mail.gq1.yahoo.com [98.137.68.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BwM3Y1mHPz48td for ; Tue, 22 Sep 2020 00:03:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: ufYmyL0VM1l46LHXyxgSzsTWwAtcnzYQ6RuBR8GSWwpXMFCX.Bb4sbs1nEGwisa IFbq8ch3lIpiQnJB9uzBjY93m9.eBYr48ytpnYMURpYfh9LAMK9HU0X7gj1fgNyIxlkMFL0cVL6k bOjvgX7.j1_IX4w94dui78kYG6M7dKH28uk34DDLJ8O9XTUM6ioAk9iaDJCqzEtNXCK63GNS.YEu HaeKTe6DZ5jisllep.idw0fanxatPt2Fe198jkBdB_ImvDkwe5VMiLac5wLhnZkkA6t6ZX_V5MR1 gN71XGR1wVoUZ3_HaQ7n5FwFotH0u3DUwS2Q6fFSsAP2FS1xpZqwwsfxzl7kQXa2IYMgOUlwOuZq wUd2ffIAxTFVmK7t0pwD0eXQkkak.PjoxNGfzfdplV_pkKQ3evjT0He2dyGyd5.V_GLJ8d5tJVLB fQAsyhI00LRoKB5e6rPZUgkHLN_7XW8qvpnsyt0wRwcfD.uBs88RP4Va32al6N5ycy.30x0Qnt5u L3W85B3aAVzlTbVpZgKsM0nQoO_3aRUSvNtaNXuwcdreTpliSq4LAhpUzQmte_CGT6uAALC1wfnq g5U7bCQwKTym5KVYFzbQyrE_JMFWyOVPlq.CIG8qTfvmHGF6Gj8MDNm_tq6BtaYtf.0L1g46HWeE .aRqTetxa4C0GYLWu1X84zS2EV2wN03NvhZyDnPXXFfVLAvsUjawqfZOZYLqTq96yAqKV9gH39D2 0UTLhm91.KO3ybPlhdxyEk9wHdVsefunH.DsohPG40HIHGRUE47cjzGIXH1tSF1DstJ45fm.U3mt _kyJ1ELnvz7sMkPI1g_gu50_7Y8p7T3O76XGik6S.AQx9K912KrlJ6JyojCHy5Np_SHR5DZvwDsO Zx3cwjb1Ls.kZq_fdNh1V3L9kMHZuPe8x9W0yHiPX5njCrNghQlYxsYP2Qmw7JadvWE1MHEt6w9v jEaizpJ2nB.cYYWdJZ88umTwoVLcgu3tOBDRBlLredQ6K8YLG3hVVRPrFVjeQqO69TpiQISlcZRx AB_Qyn_4RrK8X9fnvHatjdn7N09eBSJUmmw_Dw8_nV1VoaSqtXRypgLaettaRwXYkkAj7qKoehiA 9J_QCpVV6QmX6XlXqJQQnPsDLcfhVxWr9iM.E30Q1XeZsdW1GFlYMYJYYl_YH8PS1B4JqwspFYBe x.33oMh.f0HrIZyitL44s365b6JDF0QcIxeZcIJupNyYmlu6LQu8nkubd3Pe0VVflH1AhFfT8.kZ dJtk.E_3ya9NWVMIgypKtFNeun0laj0Wn1U8goiyDuY9qaaETDP47QPvI7GVKwejvYcQVJFTQwg2 u4s_WquhwEgH1vGliKkfU_a99XjSOcDvpoL2vIcMRjXlfmaFT66NUj1DSxzPjnNbff024.mM_QWi XbqfigS8J1kYqsQ7aWps_xSViXLTuIU4L5Ft8BKQuXNZNiTLFaOAAOSMnl03ugXsnzlZl0zxu0Hn qy7UY3X60C7QGk2duJO.iOJLfyTp9aOCeFHDMk6MZ2_2X22S8SM_VsiCfRBRx3tT16LY6pDL67ct fm5rKtGhhvg7K6xl5K2o- Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Tue, 22 Sep 2020 00:03:50 +0000 Received: by smtp414.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 10ded6455a6c10dc09a37ba4b3bfdadb; Tue, 22 Sep 2020 00:03:47 +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.4 \(3608.120.23.2.1\)) Subject: Re: Odd diff -qr / /mnt "Only in " results Date: Mon, 21 Sep 2020 17:03:46 -0700 References: <71A94120-99D0-4089-A790-0DEF28A1E091@yahoo.com> To: FreeBSD Current In-Reply-To: Message-Id: <17427EED-594B-4FD6-B124-61CC1A7BA396@yahoo.com> X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Rspamd-Queue-Id: 4BwM3Y1mHPz48td X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.11 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.61)[-0.608]; 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/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.978]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.02)[-1.022]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.32:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.32:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 22 Sep 2020 00:03:54 -0000 On 2020-Sep-21, at 16:16, Mark Millard wrote: > On 2020-Sep-21, at 13:38, Mark Millard wrote: >=20 >> Context: head -r365932 (on a Rock64). But this could well not >> be new. >>=20 >> First a look at the / context and then the /mnt/ : >>=20 >> # ls -laT / >> total 225 >> drwxr-xr-x 24 root wheel 512 Sep 21 02:20:37 2020 . >> drwxr-xr-x 24 root wheel 512 Sep 21 02:20:37 2020 .. >> -rw-r--r-- 2 root wheel 1083 Jul 8 23:53:07 2020 .cshrc >> drwxr-xr-x 2 root wheel 512 Jan 31 19:57:35 2017 .libs >> -rw-r--r-- 1 root wheel 1349 Sep 15 18:45:26 2019 .profile >> -rw------- 1 root wheel 1024 Dec 31 16:00:41 2009 .rnd >> drwxrwxr-x 2 root operator 512 Aug 8 19:02:22 2020 .snap >> -r--r--r-- 1 root wheel 6170 Feb 1 04:48:34 2020 COPYRIGHT >> drwxr-xr-x 2 root wheel 1024 Sep 21 01:56:39 2020 bin >> drwxr-xr-x 24 root wheel 1536 Sep 21 01:58:43 2020 boot >> dr-xr-xr-x 18 root wheel 512 Sep 21 02:20:24 2020 dev >> -rw------- 1 root wheel 4096 Sep 21 02:20:37 2020 entropy >> drwxr-xr-x 27 root wheel 2560 Sep 21 01:58:16 2020 etc >> drwxr-xr-x 5 root wheel 2048 Sep 21 01:56:39 2020 lib >> drwxr-xr-x 3 root wheel 512 Sep 21 01:56:38 2020 libexec >> drwx------ 2 root wheel 98816 Jul 24 21:28:53 2020 lost+found >> drwxr-xr-x 2 root wheel 512 Mar 30 05:23:44 2020 media >> drwxr-xr-x 6 root wheel 512 Sep 21 01:49:57 2020 microsd_ufs >> drwxr-xr-x 23 root wheel 512 Mar 30 05:23:44 2020 mnt >> drwxr-xr-x 2 root wheel 512 Mar 30 05:23:44 2020 net >> dr-xr-xr-x 2 root wheel 512 Mar 30 05:23:44 2020 proc >> drwxr-xr-x 2 root wheel 2560 Sep 21 01:56:38 2020 rescue >> drwxr-xr-x 17 root wheel 2560 Mar 30 05:23:44 2020 root >> drwxr-xr-x 2 root wheel 2560 Sep 21 01:56:38 2020 sbin >> lrwxr-xr-x 1 root wheel 11 May 1 19:22:54 2018 sys -> = usr/src/sys >> drwxrwxrwt 59 root wheel 3584 Sep 21 04:16:21 2020 tmp >> drwxr-xr-x 1 root wheel 16384 Dec 31 16:00:00 1979 usb_efi >> drwxr-xr-x 16 root wheel 512 Mar 30 05:23:44 2020 usr >> drwxr-xr-x 26 root wheel 512 Sep 21 02:20:36 2020 var >> drwxr-xr-x 3 root wheel 512 Sep 18 13:04:15 2018 wrkdirs >>=20 >> # ls -laT /mnt >> total 120 >> drwxr-xr-x 23 root wheel 512 Mar 30 05:23:44 2020 . >> drwxr-xr-x 24 root wheel 512 Sep 21 02:20:37 2020 .. >> -rw-r--r-- 2 root wheel 1083 Jul 16 16:41:10 2020 .cshrc >> drwxr-xr-x 2 root wheel 512 Jan 31 19:57:35 2017 .libs >> -rw-r--r-- 1 root wheel 1349 Sep 15 18:45:26 2019 .profile >> -rw------- 1 root wheel 1024 Dec 31 16:00:41 2009 .rnd >> drwxrwxr-x 2 root operator 512 Mar 14 19:02:19 2020 .snap >> -r--r--r-- 1 root wheel 6170 Feb 1 04:48:34 2020 COPYRIGHT >> drwxr-xr-x 2 root wheel 1024 Sep 21 03:32:17 2020 bin >> drwxr-xr-x 13 root wheel 1024 Sep 21 03:32:17 2020 boot >> dr-xr-xr-x 2 root wheel 512 Mar 30 05:23:44 2020 dev >> -rw------- 1 root wheel 4096 Sep 13 14:02:57 2020 entropy >> drwxr-xr-x 27 root wheel 2560 Sep 21 03:36:49 2020 etc >> drwxr-xr-x 5 root wheel 2048 Sep 21 03:32:16 2020 lib >> drwxr-xr-x 3 root wheel 512 Sep 21 03:32:16 2020 libexec >> drwx------ 2 root wheel 512 Mar 17 16:16:42 2020 lost+found >> drwxr-xr-x 2 root wheel 512 Mar 30 05:23:44 2020 media >> drwxr-xr-x 2 root wheel 512 Mar 17 16:16:08 2020 microsd_ufs >> drwxr-xr-x 2 root wheel 512 Mar 30 05:23:44 2020 mnt >> drwxr-xr-x 2 root wheel 512 Mar 30 05:23:44 2020 net >> dr-xr-xr-x 2 root wheel 512 Mar 30 05:23:44 2020 proc >> drwxr-xr-x 2 root wheel 2560 Sep 21 03:32:16 2020 rescue >> drwxr-x--- 18 root wheel 2048 Mar 30 05:23:44 2020 root >> drwxr-xr-x 2 root wheel 2560 Sep 21 03:32:13 2020 sbin >> lrwxr-xr-x 1 root wheel 11 May 1 19:22:54 2018 sys -> = usr/src/sys >> drwxrwxrwt 60 root wheel 5120 Mar 30 05:23:44 2020 tmp >> drwxr-xr-x 16 root wheel 512 Mar 30 05:23:44 2020 usr >> drwxr-xr-x 26 root wheel 512 Mar 30 05:23:44 2020 var >> drwxr-xr-x 3 root wheel 512 Sep 18 13:04:15 2018 wrkdirs >>=20 >> # df -m >> Filesystem 1M-blocks Used Avail Capacity Mounted on >> /dev/gpt/Rock64root 195378 105474 74273 59% / >> devfs 0 0 0 100% /dev >> /dev/label/Rock64root 109101 362 100010 0% /microsd_ufs >> /dev/msdosfs/RPI4EFIFS 99 7 92 8% /usb_efi >> /dev/gpt/PINE642Groot 195378 76731 103016 43% /mnt >>=20 >>=20 >> But when I do the "diff -qr / /mnt" I get the following "Only in " >> notices: >>=20 >> Only in /mnt: .cshrc >> Only in /mnt: .libs >> Only in /mnt: .profile >> Only in /mnt: .rnd >> Only in /mnt: .snap >> Only in /mnt: COPYRIGHT >> Only in /mnt: bin >> Only in /mnt: boot >> Only in /mnt: dev >> Only in /mnt: entropy >> Only in /mnt: etc >> Only in /mnt: lib >> Only in /mnt: libexec >> Only in /mnt: lost+found >> Only in /mnt: media >> Only in /mnt: microsd_ufs >> Only in /mnt: mnt >> Only in /mnt: net >> Only in /mnt: proc >> Only in /mnt: rescue >> Only in /mnt: sbin >> Only in /mnt: sys >> Only in /mnt: tmp >> Only in /mnt: usr >> Only in /mnt: var >> Only in /mnt: wrkdirs >>=20 >> It still does the diff's inside the likes of /usr/ and /mnt/usr/ . >=20 > Well, after the complete diff I went looking in places that I > had expected a few differences to show (but did not). I found > some files with differences. >=20 > So it appears that at least some of those "Only in " notices > did result in lack of comparisons in the areas reported. >=20 >> This is not something that I normally do so I've no clue what range >> of versions do this. >>=20 >=20 >=20 Bad interpretation on my part: The "Only in" /mnt notices are from diffing /mnt and /mnt/mnt . I did not notice at the time. I've still not figured out how I ended up finding more different files than reported by the global diff. For now, presume more operator errors, I guess. =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 Sep 22 02:31: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 5CD99426E18 for ; Tue, 22 Sep 2020 02:31:34 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670084.outbound.protection.outlook.com [40.107.67.84]) (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 4BwQKx0k06z4Lmm for ; Tue, 22 Sep 2020 02:31:32 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Bxs2xg3DKz2eQNNTBHw290XSzYyaR7iNS6k90HbmQM5/Ol4iDxCCDWXOfeJWgZkJ/jWFvH+3wGqm/1FXePC3SDE5U44NzbL+aMXWSQz8HPIZWNatqAUE//0XdX4tKk3x/uF666D8jXdSNaNRKCuaegfozJ/D8hOM877DTY/u5d/MN6ewuqDhg9At3lP8RIomvrCzHAzZtPrY8XLMdfPQOHUxUfJtd1GbdHLxwEivMMIZ+28dc4ew2i6WEFzQ6jnwrdJJHIfFOurcWHLnddE7x5UpDZGbD80UXZC/oLZ+ZFGtNRzwGl2g8wW5OxkG6aMO1YnbExh5wsEsb5IxMik7Rg== 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=isNBfjZHj8ZqpRY3lr9RvToaoLg+zVBGBGmT1wpXUnA=; b=O3ajP2SE2FyFscgAY9xlSLcwwoTegbgcDN/Pbcke8vnScTfrCQw37fDFtIeq8f/fZcFAFQSBOG6n25Kft091oPjafaWEZyoBEcOGnZN9GWAUwk9+VGzuZ3HknfICTuwSnD/exCBC0JP+YLbo7Blp1EhjtjjQUh7ZrpWwe1HTtDgJB52r2++yJfhZxQJZ5cN+OOhZNmwlGtbqsmtjei9MNS/1kyBtWPLGtBq1qUswvgC4v/yFV2MdZXDkhTysT58CRk7Escsm6+GTgPrf5jDNEsxSptPcPzRuQm8Dlo5xaSc2gmwpUhrRlyZsd6FPW3+Kcy1QzmNhtzExjBsCJrhSFg== 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 YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:24::27) by YT1PR01MB2697.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:1::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.17; Tue, 22 Sep 2020 02:31:30 +0000 Received: from YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM ([fe80::687f:d85a:a0a3:bd20]) by YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM ([fe80::687f:d85a:a0a3:bd20%6]) with mapi id 15.20.3391.024; Tue, 22 Sep 2020 02:31:29 +0000 From: Rick Macklem To: "freebsd-current@freebsd.org" Subject: review of mountd.c change Thread-Topic: review of mountd.c change Thread-Index: AQHWkIf27YuiSKWc+0CU83aib72v2w== Date: Tue, 22 Sep 2020 02:31:29 +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: 2b517b68-e791-4002-c069-08d85e9f9d02 x-ms-traffictypediagnostic: YT1PR01MB2697: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: HP584GE51PnoJPusfu40HmZAZJVcbmCEFWcW08n3IFPmq8QhVuriXZ5czPP8feHy36zxIKJXQ2/daFqeNOrh+n9pPXrupd4aZIMvHfhrLPPCIOL0GjbCbxWWxaZ1QTuMsAZta0vwI4+Bj6NlCXIvKie/5zUQH6fUydSBP2gQb5IWHGzXOxAKIs8HFyNI6hOg6q4frlTXtbkTCE9rmohPcYO462uThXK14zOiVMyU6bFyDd76O+ieANk7aMpacv6fv3Y0zV2DxuRyD3ISm2g6L8GrN3KtYQGMoMR8T1oJeLCAyyJSWbmbR8ZF8a/w2rI9zuvMSgEsLTf9dtmMzb+OgP6f+cmg/qKjUIUVmv1zWNGbn38KgViu5bbKlb/Z/abb x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(39860400002)(366004)(136003)(346002)(376002)(396003)(76116006)(66946007)(66476007)(66556008)(64756008)(66446008)(186003)(91956017)(8936002)(52536014)(4744005)(8676002)(786003)(5660300002)(316002)(9686003)(71200400001)(6506007)(7696005)(55016002)(2906002)(33656002)(86362001)(478600001)(6916009)(3480700007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: N0Qq9vcqnLh40eGdyyfO1J73NXnSr4dcwJgxlXVuHRVLgjWyfEZ7KYMPhd/agEDNYJOeTUm0PCmdmyW9e/KAF2y6F9Waq+1NQdbiCRmeB2hEm4OjeQNCZ3PccBsV1aDDss8YkIRfT8TQxKyRC8kBBgW99RPep9EJZcamN7Nj2QBroEOLYSoVNKosWIbUwcrwRUL81SRb/tF6/O/YQ/60A9NWtXXpFbW2agrkVhm34Y7HIq9qWNWW9qYSs1eVnOeDvJLxPmd/qmQfUx/s+yadNqVXeTQgcUAiMBErnEBCHmfmV1ZI8Qbii2zRqOeYqCcbL2PCxoMwTW1w7+6BDc/gpKfKN9Vz3a0Bkr1PpiItVaShmIwIU2T/LR9ZNQLIS9qkz+ibOW7XZ9rUnk8ORAXxzMYxkoYd2WKSbL11ltjdXX/kSrEWn3VS86aFkTdaac4ulpfqVGjiN/mhnALtY/k5Ti51l0r/Zzle9iPbiKwSP6pKZ0IeXyVqrv/SDHAikBEejAdnhMUmxzOSJfGJiUorz4bcRRqw4JWMrBzHuAD4rtjxMIIrcos3jnIozYqZjvUdeaLG6kyXt0VGnP0dVfjmLd45F2WgkS1WbHEuTwJOlb2RLU8ZquvEk/ZH7gNvrVEeqRIOx0FShLTYiWyAtGqlcNWqdfOubEMaTi8XCfR8J9Eo6ttiNX+pK6lafirpeTghhverdV/kB/jLbv0owSIhXg== 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-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 2b517b68-e791-4002-c069-08d85e9f9d02 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Sep 2020 02:31:29.9199 (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: 0F7Usq7aqcZSmldcNXr/cYK5TLT6AqSIMB+oUP8BP1Zjq4yF00qfBlvNHKixdOuzyR0kd2jbiQftZnfINqyb0g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YT1PR01MB2697 X-Rspamd-Queue-Id: 4BwQKx0k06z4Lmm X-Spamd-Bar: ------ X-Spamd-Result: default: False [-6.01 / 15.00]; NEURAL_HAM_MEDIUM(-0.98)[-0.979]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector1]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.03)[-1.032]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[uoguelph.ca:+]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; RCVD_IN_DNSWL_NONE(0.00)[40.107.67.84:from]; NEURAL_HAM_SHORT(-1.00)[-0.997]; TO_DN_EQ_ADDR_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; MAILMAN_DEST(0.00)[freebsd-current]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.67.84:from] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 22 Sep 2020 02:31:34 -0000 Hi,=0A= =0A= I just put a patch up in phabricator (D26521) which avoids always=0A= malloc()'ng a large MAX_NGROUPS sized groups list by having a=0A= small one in the structure and then only malloc()'ng when a large=0A= groups list is needed.=0A= =0A= I've listed kib@ and freqlabs@ as reviewers, but anyone else is=0A= welcome to review it.=0A= =0A= The review is probably about the technique I used.=0A= (Alternately, the could just always malloc() the groups array the=0A= correct size instead of using the SMALLNGROUPS one or malloc()'ng.)=0A= =0A= Thanks in advance to anyone that reviews it, rick=0A= From owner-freebsd-current@freebsd.org Tue Sep 22 03:40:02 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 A0F9F3DBA88 for ; Tue, 22 Sep 2020 03:40:02 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (midget.dons.net.au [IPv6:2403:5800:5101:0:ea:1cff:fefa:f00]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "dons.net.au", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BwRrw1lwwz4SKb for ; Tue, 22 Sep 2020 03:39:59 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (localhost [127.0.0.1]) by midget.dons.net.au (8.15.2/8.15.2) with ESMTPS id 08M3daid098130 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Tue, 22 Sep 2020 13:09:44 +0930 (ACST) (envelope-from darius@dons.net.au) Received: (from mailnull@localhost) by midget.dons.net.au (8.15.2/8.15.2/Submit) id 08M3dIwj098120 for ; Tue, 22 Sep 2020 13:09:18 +0930 (ACST) (envelope-from darius@dons.net.au) X-MIMEDefang-Relay-be813b1f1da6d6b27d681222cb70cc4f5b642383: 2001:44b8:1d2:8900:e4c7:daac:1045:76ef Received: from [IPv6:2001:44b8:1d2:8900:e4c7:daac:1045:76ef] ([IPv6:2001:44b8:1d2:8900:e4c7:daac:1045:76ef] [2001:44b8:1d2:8900:e4c7:daac:1045:76ef]) by midget.dons.net.au (envelope-sender ) (MIMEDefang) with ESMTP id 08M3dDr5098114; Tue, 22 Sep 2020 13:09:18 +0930 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Subject: Re: Can't forward X11 apps over ssh since migrating to 13-CURRENT From: "O'Connor, Daniel" In-Reply-To: Date: Tue, 22 Sep 2020 13:09:13 +0930 Cc: freebsd-current@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <56CFC7AB-8544-456F-891F-83F3BFDA6F80@dons.net.au> References: To: Patrick McMunn X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Spam-Score: 0.1 () No, score=0.1 required=5.0 tests=HELO_MISC_IP, HELO_NO_DOMAIN, T_SPF_PERMERROR autolearn=unavailable autolearn_force=no version=3.4.2 X-Scanned-By: MIMEDefang 2.83 on 10.0.2.1 X-Rspamd-Queue-Id: 4BwRrw1lwwz4SKb X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.68 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.991]; R_DKIM_ALLOW(-0.20)[dons.net.au:s=default]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-1.02)[-1.020]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[dons.net.au:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[dons.net.au,quarantine]; NEURAL_HAM_SHORT(-1.17)[-1.171]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:4764, ipnet:2403:5800:5000::/36, country:AU]; MID_RHS_MATCH_FROM(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 22 Sep 2020 03:40:02 -0000 > On 22 Sep 2020, at 08:06, Patrick McMunn wrote: > I don't know if it's just coincidental or if it's because of some change in > 13-CURRENT, but I recently migrated from 12.1-STABLE, and now I am unable > to forward X11 apps over ssh. The only app I was accustomed to running this > way was Handbrake. It worked fine before, but now i get this: > > $ ghb > Unable to init server: Could not connect to 127.0.0.1: Connection refused > > (ghb:87219): Gtk-WARNING **: 13:12:41.281: cannot open display: > > I have tried other apps like Wireshark and even xclock just to see, but > they won't work either. Has anyone else had problems with X11 forwarding on > 13-CURRENT? If it's working for everyone else, at least I can know it's > probably not 13-CURRENT's fault, and I need to look elsewhere for the > cause. And yes, my sshd_config has it enabled. It worked fine before, and I > made sure to keep the same config. What is the value of DISPLAY? (ie echo $DISPLAY) Is sshd listening on that port? eg.. [test 3:36] ~> echo $DISPLAY localhost:11.0 [test 3:36] ~> sockstat|grep 6011 radar sshd 5414 8 tcp6 ::1:6011 *:* radar sshd 5414 9 tcp4 127.0.0.1:6011 *:* -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum From owner-freebsd-current@freebsd.org Tue Sep 22 05:06: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 8CEB73DD90F for ; Tue, 22 Sep 2020 05:06:52 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from gmailer.gwdg.de (gmailer.gwdg.de [134.76.11.17]) (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 4BwTn81XHvz4Wdg for ; Tue, 22 Sep 2020 05:06:51 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from excmbx-03.um.gwdg.de ([134.76.9.218] helo=email.gwdg.de) by mailer.gwdg.de with esmtp (GWDG Mailer) (envelope-from ) id 1kKaVu-0006E7-L9; Tue, 22 Sep 2020 07:06:50 +0200 Received: from pc028.nfv.nw-fva.de (10.250.9.199) by EXCMBX-03.um.gwdg.de (134.76.9.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521) id 15.1.2044.4; Tue, 22 Sep 2020 07:06:50 +0200 Subject: Re: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X To: Konstantin Belousov CC: Hans Petter Selasky , monochrome , References: <88af31d4-9ed9-172a-d48f-1780f19841e3@twcny.rr.com> <11d27d41-029a-d7f5-eccc-0ba3a3fcfe97@gwdg.de> <2bbfb4b3-92e9-b3ca-9c31-6c513cee2f2d@gwdg.de> <20200920093814.GD94807@kib.kiev.ua> <0249197f-29f6-4df4-eb63-ca786aaea39d@gwdg.de> <20200920195526.GH94807@kib.kiev.ua> <20200920200735.GJ94807@kib.kiev.ua> <1621df05-35a9-92b9-ffee-d93c17110d87@gwdg.de> <2673660d-3a6e-97c9-82a2-17b5ab8b987b@gwdg.de> <20200921221329.GD2570@kib.kiev.ua> Reply-To: From: Rainer Hurling Message-ID: <14418f1d-4b3a-7c4d-4cdd-030a00d86383@gwdg.de> Date: Tue, 22 Sep 2020 07:06:50 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <20200921221329.GD2570@kib.kiev.ua> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.250.9.199] X-ClientProxiedBy: EXCMBX-03.um.gwdg.de (134.76.9.218) To EXCMBX-03.um.gwdg.de (134.76.9.218) X-Virus-Scanned: (clean) by clamav X-Rspamd-Queue-Id: 4BwTn81XHvz4Wdg X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.37 / 15.00]; HAS_REPLYTO(0.00)[rhurlin@freebsd.org]; HAS_XOIP(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:134.76.10.0/23:c]; RCVD_COUNT_THREE(0.00)[3]; RCVD_IN_DNSWL_MED(-0.20)[134.76.11.17:from]; NEURAL_HAM_SHORT(-0.82)[-0.822]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:680, ipnet:134.76.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.003]; FREEFALL_USER(0.00)[rhurlin]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-1.04)[-1.040]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; REPLYTO_DOM_NEQ_FROM_DOM(0.00)[]; DMARC_NA(0.00)[gwdg.de]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RWL_MAILSPIKE_VERYGOOD(0.00)[134.76.11.17:from]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 22 Sep 2020 05:06:52 -0000 Am 22.09.20 um 00:13 schrieb Konstantin Belousov: > On Mon, Sep 21, 2020 at 08:57:46PM +0200, Rainer Hurling wrote: >> Fatal trap 12: page fault while in kernel mode >> cpuid = 31; apic id = 1f >> fault virtual address = 0x25407efa > This address is very suspicious. > > I cannot claim it as the fact, but most likely cause for such garbage > pointer value is mismatched ABI between kernel and module. In other > words, the module was built against headers from different kernel. Hmm, thanks for the pointer. I will double check this evening and reporting back. Normally, this module should have been built and installed with the kernel build. > >> fault code = supervisor read data, page not present >> instruction pointer = 0x20:0xffffffff80ec0b63 >> stack pointer = 0x28:0xffffffff826018b0 >> frame pointer = 0x28:0xffffffff82601940 >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, long 1, def32 0, gran 1 >> processor eflags = interrupt enabled, resume, IOPL = 0 >> current process = 0 (swapper) >> trap number = 12 >> panic: page fault >> cpuid = 31 >> time = 1 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >> 0xffffffff82601560 >> vpanic() at vpanic+0x182/frame 0xffffffff826015b0 >> panic() at panic+0x43/frame 0xffffffff82601610 >> trap_fatal() at trap_fatal+0x387/frame 0xffffffff82601670 >> trap_pfault() at trap_pfault+0x97/frame 0xffffffff826016d0 >> trap() at trap+0x2ab/frame 0xffffffff826017e0 >> calltrap() at calltrap+0x8/frame 0xffffffff826017e0 >> --- trap 0xc, rip = 0xffffffff80ec0b63, rsp = 0xffffffff826018b0, rbp = >> 0xffffffff82601940 --- >> vm_map_insert() at vm_map_insert+0x2f3/framw 0xffffffff82601940 >> vm_map_find() at vm_map_find+0x4a4/frame 0xffffffff82601a00 >> rtR0MemObjFreeBSDAllocHelper() at >> rtR0MemObjFreeBSDAllocHelper+0x96/frame 0xffffffff82601a70 >> rtR0MemObjNativeAllocCont() at rtR0MemObjNativeAllocCont+0x50/frame >> 0xffffffff82601ac0 >> supdrvGipCreate() at supdrvGipCreate+0x97/frame 0xffffffff82601b60 >> supdrvInitDevExt() at supdrvInitDevExt+0x19a/frame 0xffffffff82601bd0 >> VBoxDrvFreeBSDModuleEvent() at VBoxDrvFreeBSDModuleEvent+0x46/frame >> 0xffffffff82601bf0 >> module_register_init() at module_register_init+0xbd/frame 0xffffffff82601c20 >> mi_startup() at mi_startup+0xec/frame 0xffffffff82601c70 >> btext() at btext+0x2c >> KDB: enter: panic >> [ thread pid 0 tid 100000 ] >> Stopped at kdb_enter+0x37: movq $0,0x10b5616(%rip) >> db> >> >> >> Perhaps this gives some more insight into the problem? I can't assess, >> sorry. From owner-freebsd-current@freebsd.org Tue Sep 22 05:52: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 329ED3DE55F for ; Tue, 22 Sep 2020 05:52:01 +0000 (UTC) (envelope-from monochrome@twcny.rr.com) Received: from p-impout001.msg.pkvw.co.charter.net (p-impout001aa.msg.pkvw.co.charter.net [47.43.26.132]) (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 4BwVnC30wyz4YYC; Tue, 22 Sep 2020 05:51:58 +0000 (UTC) (envelope-from monochrome@twcny.rr.com) Received: from [192.168.13.11] ([45.47.33.158]) by cmsmtp with ESMTP id KbDSkyj8EWFOUKbDTkaBC6; Tue, 22 Sep 2020 05:51:52 +0000 X-Authority-Analysis: v=2.3 cv=NuGvjPVJ c=1 sm=1 tr=0 a=VvwePSPmDFBOGFNvGtd2Cw==:117 a=VvwePSPmDFBOGFNvGtd2Cw==:17 a=IkcTkHD0fZMA:10 a=_kq-PPg25ud80-7JMrEA:9 a=ucZR-qGt2UFPk7du:21 a=vYD2f5G4Qr07huJk:21 a=QEXdDO2ut3YA:10 Subject: Re: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X To: rhurlin@freebsd.org, Konstantin Belousov Cc: Hans Petter Selasky , freebsd-current@freebsd.org References: <88af31d4-9ed9-172a-d48f-1780f19841e3@twcny.rr.com> <11d27d41-029a-d7f5-eccc-0ba3a3fcfe97@gwdg.de> <2bbfb4b3-92e9-b3ca-9c31-6c513cee2f2d@gwdg.de> <20200920093814.GD94807@kib.kiev.ua> <0249197f-29f6-4df4-eb63-ca786aaea39d@gwdg.de> <20200920195526.GH94807@kib.kiev.ua> <20200920200735.GJ94807@kib.kiev.ua> <1621df05-35a9-92b9-ffee-d93c17110d87@gwdg.de> <2673660d-3a6e-97c9-82a2-17b5ab8b987b@gwdg.de> <20200921221329.GD2570@kib.kiev.ua> <14418f1d-4b3a-7c4d-4cdd-030a00d86383@gwdg.de> From: monochrome Message-ID: <5f318192-78a4-70bb-93e6-608efbc37b09@twcny.rr.com> Date: Tue, 22 Sep 2020 01:51:50 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.3.0 MIME-Version: 1.0 In-Reply-To: <14418f1d-4b3a-7c4d-4cdd-030a00d86383@gwdg.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfG5vIjtBxXSmebmvWDcBh9+RkYOt11FN2BFB2JfllbWfToPSBPtA1sYoc5sAM90/rJZqtWe6P5+dDSKrB4RoIL6a4l/gOzQXVQXEK222pHFBJBJC1V9J dUB1XWXyEpcOTmUJRS+2rRx4cwz7I0o+wWmcl/5nrFMBmtclEmyJdtbFO+FtYmYR14zINEb5WBvQ0MQeIrt5izUkhe9IdtS80TUxB6C4jGa+3oTMMjc7Zzi6 K9dFJ6qMje7ZbAMvs7pOvJ4makwdGvn4+8SViMnBcyw= X-Rspamd-Queue-Id: 4BwVnC30wyz4YYC X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.02 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:47.43.26.0/24]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[rr.com]; NEURAL_HAM_LONG(-1.04)[-1.037]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.70)[-0.699]; NEURAL_HAM_MEDIUM(-0.98)[-0.980]; FREEMAIL_TO(0.00)[freebsd.org,gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:40294, ipnet:47.43.24.0/21, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-current]; RECEIVED_SPAMHAUS_PBL(0.00)[45.47.33.158:received] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 22 Sep 2020 05:52:01 -0000 Rainer, I'm all up and running and clean with the latest again, if it still doesn't work after your next try, send me your step-by-step to patch and i'll try it here. I'm using ryzen video so I have to disable stuff to even see the fault messages. On 9/22/20 1:06 AM, Rainer Hurling wrote: > Am 22.09.20 um 00:13 schrieb Konstantin Belousov: >> On Mon, Sep 21, 2020 at 08:57:46PM +0200, Rainer Hurling wrote: >>> Fatal trap 12: page fault while in kernel mode >>> cpuid = 31; apic id = 1f >>> fault virtual address   = 0x25407efa >> This address is very suspicious. >> >> I cannot claim it as the fact, but most likely cause for such garbage >> pointer value is mismatched ABI between kernel and module.  In other >> words, the module was built against headers from different kernel. > > Hmm, thanks for the pointer. I will double check this evening and > reporting back. > > Normally, this module should have been built and installed with the > kernel build. > >> >>> fault code              = supervisor read data, page not present >>> instruction pointer     = 0x20:0xffffffff80ec0b63 >>> stack pointer           = 0x28:0xffffffff826018b0 >>> frame pointer           = 0x28:0xffffffff82601940 >>> code segment            = base 0x0, limit 0xfffff, type 0x1b >>>                          = DPL 0, pres 1, long 1, def32 0, gran 1 >>> processor eflags        = interrupt enabled, resume, IOPL = 0 >>> current process         = 0 (swapper) >>> trap number             = 12 >>> panic: page fault >>> cpuid = 31 >>> time = 1 >>> KDB: stack backtrace: >>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >>> 0xffffffff82601560 >>> vpanic() at vpanic+0x182/frame 0xffffffff826015b0 >>> panic() at panic+0x43/frame 0xffffffff82601610 >>> trap_fatal() at trap_fatal+0x387/frame 0xffffffff82601670 >>> trap_pfault() at trap_pfault+0x97/frame 0xffffffff826016d0 >>> trap() at trap+0x2ab/frame 0xffffffff826017e0 >>> calltrap() at calltrap+0x8/frame 0xffffffff826017e0 >>> --- trap 0xc, rip = 0xffffffff80ec0b63, rsp = 0xffffffff826018b0, rbp = >>> 0xffffffff82601940 --- >>> vm_map_insert() at vm_map_insert+0x2f3/framw 0xffffffff82601940 >>> vm_map_find() at vm_map_find+0x4a4/frame 0xffffffff82601a00 >>> rtR0MemObjFreeBSDAllocHelper() at >>> rtR0MemObjFreeBSDAllocHelper+0x96/frame 0xffffffff82601a70 >>> rtR0MemObjNativeAllocCont() at rtR0MemObjNativeAllocCont+0x50/frame >>> 0xffffffff82601ac0 >>> supdrvGipCreate() at supdrvGipCreate+0x97/frame 0xffffffff82601b60 >>> supdrvInitDevExt() at supdrvInitDevExt+0x19a/frame 0xffffffff82601bd0 >>> VBoxDrvFreeBSDModuleEvent() at VBoxDrvFreeBSDModuleEvent+0x46/frame >>> 0xffffffff82601bf0 >>> module_register_init() at module_register_init+0xbd/frame >>> 0xffffffff82601c20 >>> mi_startup() at mi_startup+0xec/frame 0xffffffff82601c70 >>> btext() at btext+0x2c >>> KDB: enter: panic >>> [ thread pid 0 tid 100000 ] >>> Stopped at      kdb_enter+0x37: movq    $0,0x10b5616(%rip) >>> db> >>> >>> >>> Perhaps this gives some more insight into the problem? I can't assess, >>> sorry. > From owner-freebsd-current@freebsd.org Tue Sep 22 15:34:29 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 505F03EC6F6; Tue, 22 Sep 2020 15:34:29 +0000 (UTC) (envelope-from ali.abdallah@suse.com) Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.suse.de", Issuer "DigiCert SHA2 High Assurance Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BwljJ4Wfjz49c0; Tue, 22 Sep 2020 15:34:28 +0000 (UTC) (envelope-from ali.abdallah@suse.com) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id D5409ACAC; Tue, 22 Sep 2020 15:35:02 +0000 (UTC) Date: Tue, 22 Sep 2020 17:34:25 +0200 From: Ali Abdallah To: freebsd-stable@freebsd.org Cc: freebsd-current@freebsd.org Subject: HD audio problem on FreeBSD 12.1 bhyve VM Message-ID: <20200922153425.md5yvjj7asrjou3n@frix230> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Rspamd-Queue-Id: 4BwljJ4Wfjz49c0 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-5.00 / 15.00]; MID_RHS_NOT_FQDN(0.50)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[suse.com:s=susede1]; NEURAL_HAM_MEDIUM(-0.94)[-0.942]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_MED(-2.00)[suse.com:dkim]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:195.135.220.15]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; RWL_MAILSPIKE_GOOD(0.00)[195.135.220.15:from]; NEURAL_SPAM_SHORT(0.15)[0.145]; NEURAL_HAM_LONG(-1.00)[-1.003]; RCVD_IN_DNSWL_MED(-0.20)[195.135.220.15:from]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[suse.com,none]; DKIM_TRACE(0.00)[suse.com:+]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:29298, ipnet:195.135.220.0/22, country:DE]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-current,freebsd-stable] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 22 Sep 2020 15:34:29 -0000 Hello, I'm running FreeBSD 12.1 release host with the HD bhyve audio patch from 13-current. On a OpenSUSE 15.2 bhyve guest, audio works perfectly fine. However, on FreeBSD 12.1 only noise comes out. Using /dev/dsp4 (which is a USB sound device), audio works fine, but not on /dev/dsp0, the default sound device on my system. I see the following relevant errors: pcm0: chn_write(): pcm0:virtual:dsp0.vp0: play interrupt timeout, channel dead pcm0: chn_write(): pcm0:virtual:dsp0.vp0: play interrupt timeout, channel dead pin dump from FreeBSD 12.1 VM. ------------------------------ hdaa0: Dumping AFG pins: hdaa0: nid 0x as seq device conn jack loc color misc hdaa0: 3 00001010 1 0 Line-out Jack Unknown 0x00 Black 0 hdaa0: Caps: OUT Sense: 0x80000000 (connected) hdaa0: 5 00805020 2 0 Line-in Jack Unknown 0x00 Red 0 hdaa0: Caps: IN Sense: 0x80000000 (connected) hdaa0: NumGPIO=0 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=0 I tried sysctl dev.hdac.0.polling=1 with no success. Note that: The above problem is also reproducible on 13-Current 20200917. Any help is appreciated. Kind regards, Ali From owner-freebsd-current@freebsd.org Tue Sep 22 16:45: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 D2B843EF264 for ; Tue, 22 Sep 2020 16:45:39 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from gmailer.gwdg.de (gmailer.gwdg.de [134.76.11.17]) (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 4BwnHR1nJ5z4Hhr for ; Tue, 22 Sep 2020 16:45:38 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from excmbx-03.um.gwdg.de ([134.76.9.218] helo=email.gwdg.de) by mailer.gwdg.de with esmtp (GWDG Mailer) (envelope-from ) id 1kKlQ9-0006ac-8k; Tue, 22 Sep 2020 18:45:37 +0200 Received: from krabat.raven.hur (10.250.9.199) by EXCMBX-03.um.gwdg.de (134.76.9.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2044.4; Tue, 22 Sep 2020 18:45:36 +0200 Subject: Re: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X From: Rainer Hurling To: Konstantin Belousov CC: Hans Petter Selasky , monochrome , Reply-To: References: <88af31d4-9ed9-172a-d48f-1780f19841e3@twcny.rr.com> <11d27d41-029a-d7f5-eccc-0ba3a3fcfe97@gwdg.de> <2bbfb4b3-92e9-b3ca-9c31-6c513cee2f2d@gwdg.de> <20200920093814.GD94807@kib.kiev.ua> <0249197f-29f6-4df4-eb63-ca786aaea39d@gwdg.de> <20200920195526.GH94807@kib.kiev.ua> <20200920200735.GJ94807@kib.kiev.ua> <1621df05-35a9-92b9-ffee-d93c17110d87@gwdg.de> <2673660d-3a6e-97c9-82a2-17b5ab8b987b@gwdg.de> <20200921221329.GD2570@kib.kiev.ua> <14418f1d-4b3a-7c4d-4cdd-030a00d86383@gwdg.de> Message-ID: <6c5cff68-23d5-c093-7404-a3fed341e5bb@gwdg.de> Date: Tue, 22 Sep 2020 18:45:25 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.3.0 MIME-Version: 1.0 In-Reply-To: <14418f1d-4b3a-7c4d-4cdd-030a00d86383@gwdg.de> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [10.250.9.199] X-ClientProxiedBy: EXCMBX-12.um.gwdg.de (134.76.9.221) To EXCMBX-03.um.gwdg.de (134.76.9.218) X-Virus-Scanned: (clean) by clamav X-Rspamd-Queue-Id: 4BwnHR1nJ5z4Hhr X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.11 / 15.00]; HAS_REPLYTO(0.00)[rhurlin@freebsd.org]; HAS_XOIP(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:134.76.10.0/23]; RCVD_COUNT_THREE(0.00)[3]; RCVD_IN_DNSWL_MED(-0.20)[134.76.11.17:from]; NEURAL_HAM_SHORT(-0.56)[-0.560]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:680, ipnet:134.76.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.01)[-1.009]; FREEFALL_USER(0.00)[rhurlin]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-1.04)[-1.041]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; REPLYTO_DOM_NEQ_FROM_DOM(0.00)[]; DMARC_NA(0.00)[gwdg.de]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RWL_MAILSPIKE_VERYGOOD(0.00)[134.76.11.17:from]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 22 Sep 2020 16:45:39 -0000 On 22.09.20 07:06, Rainer Hurling wrote: > Am 22.09.20 um 00:13 schrieb Konstantin Belousov: >> On Mon, Sep 21, 2020 at 08:57:46PM +0200, Rainer Hurling wrote: >>> Fatal trap 12: page fault while in kernel mode >>> cpuid = 31; apic id = 1f >>> fault virtual address   = 0x25407efa >> This address is very suspicious. >> >> I cannot claim it as the fact, but most likely cause for such garbage >> pointer value is mismatched ABI between kernel and module.  In other >> words, the module was built against headers from different kernel. > > Hmm, thanks for the pointer. I will double check this evening and > reporting back. > > Normally, this module should have been built and installed with the > kernel build. As I said, the module was rebuild and reinstalled with the kernel build, and I double checked, the module was the patched version. So the boot messages about the page fault should be created by the rebuild, patched module. > >> >>> fault code              = supervisor read data, page not present >>> instruction pointer     = 0x20:0xffffffff80ec0b63 >>> stack pointer           = 0x28:0xffffffff826018b0 >>> frame pointer           = 0x28:0xffffffff82601940 >>> code segment            = base 0x0, limit 0xfffff, type 0x1b >>>                          = DPL 0, pres 1, long 1, def32 0, gran 1 >>> processor eflags        = interrupt enabled, resume, IOPL = 0 >>> current process         = 0 (swapper) >>> trap number             = 12 >>> panic: page fault >>> cpuid = 31 >>> time = 1 >>> KDB: stack backtrace: >>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >>> 0xffffffff82601560 >>> vpanic() at vpanic+0x182/frame 0xffffffff826015b0 >>> panic() at panic+0x43/frame 0xffffffff82601610 >>> trap_fatal() at trap_fatal+0x387/frame 0xffffffff82601670 >>> trap_pfault() at trap_pfault+0x97/frame 0xffffffff826016d0 >>> trap() at trap+0x2ab/frame 0xffffffff826017e0 >>> calltrap() at calltrap+0x8/frame 0xffffffff826017e0 >>> --- trap 0xc, rip = 0xffffffff80ec0b63, rsp = 0xffffffff826018b0, rbp = >>> 0xffffffff82601940 --- >>> vm_map_insert() at vm_map_insert+0x2f3/framw 0xffffffff82601940 >>> vm_map_find() at vm_map_find+0x4a4/frame 0xffffffff82601a00 >>> rtR0MemObjFreeBSDAllocHelper() at >>> rtR0MemObjFreeBSDAllocHelper+0x96/frame 0xffffffff82601a70 >>> rtR0MemObjNativeAllocCont() at rtR0MemObjNativeAllocCont+0x50/frame >>> 0xffffffff82601ac0 >>> supdrvGipCreate() at supdrvGipCreate+0x97/frame 0xffffffff82601b60 >>> supdrvInitDevExt() at supdrvInitDevExt+0x19a/frame 0xffffffff82601bd0 >>> VBoxDrvFreeBSDModuleEvent() at VBoxDrvFreeBSDModuleEvent+0x46/frame >>> 0xffffffff82601bf0 >>> module_register_init() at module_register_init+0xbd/frame >>> 0xffffffff82601c20 >>> mi_startup() at mi_startup+0xec/frame 0xffffffff82601c70 >>> btext() at btext+0x2c >>> KDB: enter: panic >>> [ thread pid 0 tid 100000 ] >>> Stopped at      kdb_enter+0x37: movq    $0,0x10b5616(%rip) >>> db> >>> >>> >>> Perhaps this gives some more insight into the problem? I can't assess, >>> sorry. From owner-freebsd-current@freebsd.org Tue Sep 22 16:51: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 EA6F53EF8C3 for ; Tue, 22 Sep 2020 16:51:44 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from gmailer.gwdg.de (gmailer.gwdg.de [134.76.11.17]) (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 4BwnQS2gxCz4JhW for ; Tue, 22 Sep 2020 16:51:44 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from excmbx-03.um.gwdg.de ([134.76.9.218] helo=email.gwdg.de) by mailer.gwdg.de with esmtp (GWDG Mailer) (envelope-from ) id 1kKlW3-0007eI-21; Tue, 22 Sep 2020 18:51:43 +0200 Received: from krabat.raven.hur (10.250.9.199) by EXCMBX-03.um.gwdg.de (134.76.9.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2044.4; Tue, 22 Sep 2020 18:51:42 +0200 Subject: Re: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X To: monochrome CC: Hans Petter Selasky , , Konstantin Belousov References: <88af31d4-9ed9-172a-d48f-1780f19841e3@twcny.rr.com> <11d27d41-029a-d7f5-eccc-0ba3a3fcfe97@gwdg.de> <2bbfb4b3-92e9-b3ca-9c31-6c513cee2f2d@gwdg.de> <20200920093814.GD94807@kib.kiev.ua> <0249197f-29f6-4df4-eb63-ca786aaea39d@gwdg.de> <20200920195526.GH94807@kib.kiev.ua> <20200920200735.GJ94807@kib.kiev.ua> <1621df05-35a9-92b9-ffee-d93c17110d87@gwdg.de> <2673660d-3a6e-97c9-82a2-17b5ab8b987b@gwdg.de> <20200921221329.GD2570@kib.kiev.ua> <14418f1d-4b3a-7c4d-4cdd-030a00d86383@gwdg.de> <5f318192-78a4-70bb-93e6-608efbc37b09@twcny.rr.com> Reply-To: From: Rainer Hurling Message-ID: <7c8d5376-2006-9e30-8ea2-8d1ca6392133@gwdg.de> Date: Tue, 22 Sep 2020 18:51:42 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.3.0 MIME-Version: 1.0 In-Reply-To: <5f318192-78a4-70bb-93e6-608efbc37b09@twcny.rr.com> Content-Language: en-US X-Originating-IP: [10.250.9.199] X-ClientProxiedBy: excmbx-18.um.gwdg.de (134.76.9.229) To EXCMBX-03.um.gwdg.de (134.76.9.218) X-Virus-Scanned: (clean) by clamav X-Rspamd-Queue-Id: 4BwnQS2gxCz4JhW X-Spamd-Bar: - X-Spamd-Result: default: False [-1.52 / 15.00]; HAS_REPLYTO(0.00)[rhurlin@freebsd.org]; HAS_XOIP(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:134.76.10.0/23:c]; HAS_ATTACHMENT(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCVD_IN_DNSWL_MED(-0.20)[134.76.11.17:from]; NEURAL_HAM_SHORT(-0.58)[-0.577]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:680, ipnet:134.76.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.990]; FREEFALL_USER(0.00)[rhurlin]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-1.05)[-1.054]; MIME_GOOD(-0.10)[multipart/mixed,text/plain,text/x-csrc]; MIME_BAD_ATTACHMENT(1.60)[c]; REPLYTO_DOM_NEQ_FROM_DOM(0.00)[]; DMARC_NA(0.00)[gwdg.de]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+]; RWL_MAILSPIKE_VERYGOOD(0.00)[134.76.11.17:from]; FREEMAIL_CC(0.00)[selasky.org,freebsd.org,gmail.com]; MAILMAN_DEST(0.00)[freebsd-current] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 22 Sep 2020 16:51:45 -0000 On 22.09.20 07:51, monochrome wrote: > Rainer, I'm all up and running and clean with the latest again, if it > still doesn't work after your next try, send me your step-by-step to > patch and i'll try it here. I'm using ryzen video so I have to disable > stuff to even see the fault messages. Hi monochrome, The attached file is the patched version, I put in the files dir of emulators/virtualbox-ose (the main port, not the kernel modules one). Then I rebuilt and reinstall the ports mulators/virtualbox-ose-kmod and mulators/virtualbox-ose and rebooted the box. In my case, the boot process freezes after the page fault messages. > > On 9/22/20 1:06 AM, Rainer Hurling wrote: >> Am 22.09.20 um 00:13 schrieb Konstantin Belousov: >>> On Mon, Sep 21, 2020 at 08:57:46PM +0200, Rainer Hurling wrote: >>>> Fatal trap 12: page fault while in kernel mode >>>> cpuid = 31; apic id = 1f >>>> fault virtual address   = 0x25407efa >>> This address is very suspicious. >>> >>> I cannot claim it as the fact, but most likely cause for such garbage >>> pointer value is mismatched ABI between kernel and module.  In other >>> words, the module was built against headers from different kernel. >> >> Hmm, thanks for the pointer. I will double check this evening and >> reporting back. >> >> Normally, this module should have been built and installed with the >> kernel build. >> >>> >>>> fault code              = supervisor read data, page not present >>>> instruction pointer     = 0x20:0xffffffff80ec0b63 >>>> stack pointer           = 0x28:0xffffffff826018b0 >>>> frame pointer           = 0x28:0xffffffff82601940 >>>> code segment            = base 0x0, limit 0xfffff, type 0x1b >>>>                          = DPL 0, pres 1, long 1, def32 0, gran 1 >>>> processor eflags        = interrupt enabled, resume, IOPL = 0 >>>> current process         = 0 (swapper) >>>> trap number             = 12 >>>> panic: page fault >>>> cpuid = 31 >>>> time = 1 >>>> KDB: stack backtrace: >>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >>>> 0xffffffff82601560 >>>> vpanic() at vpanic+0x182/frame 0xffffffff826015b0 >>>> panic() at panic+0x43/frame 0xffffffff82601610 >>>> trap_fatal() at trap_fatal+0x387/frame 0xffffffff82601670 >>>> trap_pfault() at trap_pfault+0x97/frame 0xffffffff826016d0 >>>> trap() at trap+0x2ab/frame 0xffffffff826017e0 >>>> calltrap() at calltrap+0x8/frame 0xffffffff826017e0 >>>> --- trap 0xc, rip = 0xffffffff80ec0b63, rsp = 0xffffffff826018b0, rbp = >>>> 0xffffffff82601940 --- >>>> vm_map_insert() at vm_map_insert+0x2f3/framw 0xffffffff82601940 >>>> vm_map_find() at vm_map_find+0x4a4/frame 0xffffffff82601a00 >>>> rtR0MemObjFreeBSDAllocHelper() at >>>> rtR0MemObjFreeBSDAllocHelper+0x96/frame 0xffffffff82601a70 >>>> rtR0MemObjNativeAllocCont() at rtR0MemObjNativeAllocCont+0x50/frame >>>> 0xffffffff82601ac0 >>>> supdrvGipCreate() at supdrvGipCreate+0x97/frame 0xffffffff82601b60 >>>> supdrvInitDevExt() at supdrvInitDevExt+0x19a/frame 0xffffffff82601bd0 >>>> VBoxDrvFreeBSDModuleEvent() at VBoxDrvFreeBSDModuleEvent+0x46/frame >>>> 0xffffffff82601bf0 >>>> module_register_init() at module_register_init+0xbd/frame >>>> 0xffffffff82601c20 >>>> mi_startup() at mi_startup+0xec/frame 0xffffffff82601c70 >>>> btext() at btext+0x2c >>>> KDB: enter: panic >>>> [ thread pid 0 tid 100000 ] >>>> Stopped at      kdb_enter+0x37: movq    $0,0x10b5616(%rip) >>>> db> >>>> >>>> >>>> Perhaps this gives some more insight into the problem? I can't assess, >>>> sorry. >> From owner-freebsd-current@freebsd.org Tue Sep 22 18:06:56 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 167F63F1A27 for ; Tue, 22 Sep 2020 18:06:56 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from mail.nomadlogic.org (mail.nomadlogic.org [174.136.98.114]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.nomadlogic.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Bwq5B6B1Jz4PNG for ; Tue, 22 Sep 2020 18:06:54 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from [192.168.1.160] (cpe-23-243-161-111.socal.res.rr.com [23.243.161.111]) by mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id ec483587 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Tue, 22 Sep 2020 18:06:46 +0000 (UTC) Subject: Re: Can't forward X11 apps over ssh since migrating to 13-CURRENT To: "O'Connor, Daniel" , Patrick McMunn Cc: freebsd-current@freebsd.org References: <56CFC7AB-8544-456F-891F-83F3BFDA6F80@dons.net.au> From: Pete Wright Message-ID: <2c24beb6-15cb-0830-e112-e4a082a68fda@nomadlogic.org> Date: Tue, 22 Sep 2020 11:06:41 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.2.2 MIME-Version: 1.0 In-Reply-To: <56CFC7AB-8544-456F-891F-83F3BFDA6F80@dons.net.au> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Rspamd-Queue-Id: 4Bwq5B6B1Jz4PNG X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.89 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[nomadlogic.org]; ARC_NA(0.00)[]; NEURAL_HAM_LONG(-1.04)[-1.045]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.59)[-0.589]; NEURAL_HAM_MEDIUM(-0.95)[-0.955]; FREEMAIL_TO(0.00)[dons.net.au,gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:25795, ipnet:174.136.96.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-current]; RECEIVED_SPAMHAUS_PBL(0.00)[23.243.161.111:received] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 22 Sep 2020 18:06:56 -0000 On 9/21/20 8:39 PM, O'Connor, Daniel wrote: > >> On 22 Sep 2020, at 08:06, Patrick McMunn wrote: >> I don't know if it's just coincidental or if it's because of some change in >> 13-CURRENT, but I recently migrated from 12.1-STABLE, and now I am unable >> to forward X11 apps over ssh. The only app I was accustomed to running this >> way was Handbrake. It worked fine before, but now i get this: >> >> $ ghb >> Unable to init server: Could not connect to 127.0.0.1: Connection refused >> >> (ghb:87219): Gtk-WARNING **: 13:12:41.281: cannot open display: >> >> I have tried other apps like Wireshark and even xclock just to see, but >> they won't work either. Has anyone else had problems with X11 forwarding on >> 13-CURRENT? If it's working for everyone else, at least I can know it's >> probably not 13-CURRENT's fault, and I need to look elsewhere for the >> cause. And yes, my sshd_config has it enabled. It worked fine before, and I >> made sure to keep the same config. > What is the value of DISPLAY? (ie echo $DISPLAY) > > Is sshd listening on that port? eg.. > [test 3:36] ~> echo $DISPLAY > localhost:11.0 > [test 3:36] ~> sockstat|grep 6011 > radar sshd 5414 8 tcp6 ::1:6011 *:* > radar sshd 5414 9 tcp4 127.0.0.1:6011 *:* might have missed this but how is the ssh session being established.  i just verified "ssh -X host" allows me to redirect X to my local workstation.  both systems are running CURRENT as well. -p -- Pete Wright pete@nomadlogic.org @nomadlogicLA From owner-freebsd-current@freebsd.org Tue Sep 22 21:18: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 77E653F7784 for ; Tue, 22 Sep 2020 21:18:25 +0000 (UTC) (envelope-from oleg@theweb.org.ua) Received: from sigill.theweb.org.ua (noc.quadranet.com [66.63.164.214]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "sigill.theweb.org.ua", Issuer "sigill.theweb.org.ua" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BwvL76X2Xz4fGR for ; Tue, 22 Sep 2020 21:18:22 +0000 (UTC) (envelope-from oleg@theweb.org.ua) Received: from sigill.theweb.org.ua (localhost [127.0.0.1]) by sigill.theweb.org.ua (8.16.1/8.16.1) with ESMTPS id 08MLIDtI036106 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Wed, 23 Sep 2020 00:18:13 +0300 (EEST) (envelope-from oleg@theweb.org.ua) Received: (from oleg@localhost) by sigill.theweb.org.ua (8.16.1/8.16.1/Submit) id 08MLIDDJ036105 for freebsd-current@freebsd.org; Wed, 23 Sep 2020 00:18:13 +0300 (EEST) (envelope-from oleg@theweb.org.ua) X-Authentication-Warning: sigill.theweb.org.ua: oleg set sender to oleg@theweb.org.ua using -f From: "Oleg V. Nauman" To: freebsd-current@freebsd.org Subject: Re: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X Date: Wed, 23 Sep 2020 00:18:12 +0300 Message-ID: <3773950.BRNeRiNLvY@sigill.theweb.org.ua> Organization: Private persom In-Reply-To: <6c5cff68-23d5-c093-7404-a3fed341e5bb@gwdg.de> References: <88af31d4-9ed9-172a-d48f-1780f19841e3@twcny.rr.com> <14418f1d-4b3a-7c4d-4cdd-030a00d86383@gwdg.de> <6c5cff68-23d5-c093-7404-a3fed341e5bb@gwdg.de> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Rspamd-Queue-Id: 4BwvL76X2Xz4fGR X-Spamd-Bar: ++++ X-Spamd-Result: default: False [4.99 / 15.00]; HFILTER_HELO_NORES_A_OR_MX(0.30)[sigill.theweb.org.ua]; HAS_XAW(0.00)[]; TO_DN_NONE(0.00)[]; HAS_ORG_HEADER(0.00)[]; HFILTER_HELO_IP_A(1.00)[sigill.theweb.org.ua]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; CTE_CASE(0.50)[]; ASN(0.00)[asn:8100, ipnet:66.63.164.0/23, country:US]; R_DKIM_NA(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[oleg]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.93)[0.934]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.80)[0.798]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[theweb.org.ua]; NEURAL_SPAM_LONG(0.55)[0.554]; R_SPF_NA(0.00)[no SPF record]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 22 Sep 2020 21:18:25 -0000 On 2020 M09 22, Tue 19:45:25 EEST Rainer Hurling wrote: > On 22.09.20 07:06, Rainer Hurling wrote: > > Am 22.09.20 um 00:13 schrieb Konstantin Belousov: > >> On Mon, Sep 21, 2020 at 08:57:46PM +0200, Rainer Hurling wrote: > >>> Fatal trap 12: page fault while in kernel mode > >>> cpuid = 31; apic id = 1f > >>> fault virtual address = 0x25407efa > >> > >> This address is very suspicious. > >> > >> I cannot claim it as the fact, but most likely cause for such garbage > >> pointer value is mismatched ABI between kernel and module. In other > >> words, the module was built against headers from different kernel. > > > > Hmm, thanks for the pointer. I will double check this evening and > > reporting back. > > > > Normally, this module should have been built and installed with the > > kernel build. > > As I said, the module was rebuild and reinstalled with the kernel build, > and I double checked, the module was the patched version. > > So the boot messages about the page fault should be created by the > rebuild, patched module. > > >>> fault code = supervisor read data, page not present > >>> instruction pointer = 0x20:0xffffffff80ec0b63 > >>> stack pointer = 0x28:0xffffffff826018b0 > >>> frame pointer = 0x28:0xffffffff82601940 > >>> code segment = base 0x0, limit 0xfffff, type 0x1b > >>> = DPL 0, pres 1, long 1, def32 0, gran 1 > >>> processor eflags = interrupt enabled, resume, IOPL = 0 > >>> current process = 0 (swapper) > >>> trap number = 12 > >>> panic: page fault > >>> cpuid = 31 > >>> time = 1 > >>> KDB: stack backtrace: > >>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > >>> 0xffffffff82601560 > >>> vpanic() at vpanic+0x182/frame 0xffffffff826015b0 > >>> panic() at panic+0x43/frame 0xffffffff82601610 > >>> trap_fatal() at trap_fatal+0x387/frame 0xffffffff82601670 > >>> trap_pfault() at trap_pfault+0x97/frame 0xffffffff826016d0 > >>> trap() at trap+0x2ab/frame 0xffffffff826017e0 > >>> calltrap() at calltrap+0x8/frame 0xffffffff826017e0 > >>> --- trap 0xc, rip = 0xffffffff80ec0b63, rsp = 0xffffffff826018b0, rbp = > >>> 0xffffffff82601940 --- > >>> vm_map_insert() at vm_map_insert+0x2f3/framw 0xffffffff82601940 > >>> vm_map_find() at vm_map_find+0x4a4/frame 0xffffffff82601a00 > >>> rtR0MemObjFreeBSDAllocHelper() at > >>> rtR0MemObjFreeBSDAllocHelper+0x96/frame 0xffffffff82601a70 > >>> rtR0MemObjNativeAllocCont() at rtR0MemObjNativeAllocCont+0x50/frame > >>> 0xffffffff82601ac0 > >>> supdrvGipCreate() at supdrvGipCreate+0x97/frame 0xffffffff82601b60 > >>> supdrvInitDevExt() at supdrvInitDevExt+0x19a/frame 0xffffffff82601bd0 > >>> VBoxDrvFreeBSDModuleEvent() at VBoxDrvFreeBSDModuleEvent+0x46/frame > >>> 0xffffffff82601bf0 > >>> module_register_init() at module_register_init+0xbd/frame > >>> 0xffffffff82601c20 > >>> mi_startup() at mi_startup+0xec/frame 0xffffffff82601c70 > >>> btext() at btext+0x2c > >>> KDB: enter: panic > >>> [ thread pid 0 tid 100000 ] > >>> Stopped at kdb_enter+0x37: movq $0,0x10b5616(%rip) > >>> db> > >>> > >>> > >>> Perhaps this gives some more insight into the problem? I can't assess, > >>> sorry. I am experiencing the same issue with panic caused by 'kldload vboxdrv' Below is the stack strace , with both virtualbox-ose and virtualbox-ose-kmod patched: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x1e419ada fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff80731b0d stack pointer = 0x28:0xfffffe008223b4d0 frame pointer = 0x28:0xfffffe008223b550 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 2194 (kldload) trap number = 12 panic: page fault cpuid = 0 time = 1600808943 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe008223b1b0 vpanic() at vpanic+0x182/frame 0xfffffe008223b200 panic() at panic+0x43/frame 0xfffffe008223b260 trap_fatal() at trap_fatal+0x387/frame 0xfffffe008223b2c0 trap_pfault() at trap_pfault+0x49/frame 0xfffffe008223b2f0 trap() at trap+0x259/frame 0xfffffe008223b400 calltrap() at calltrap+0x8/frame 0xfffffe008223b400 --- trap 0xc, rip = 0xffffffff80731b0d, rsp = 0xfffffe008223b4d0, rbp = 0xfffffe008223b550 --- vm_map_insert() at vm_map_insert+0x24d/frame 0xfffffe008223b550 vm_map_find() at vm_map_find+0x539/frame 0xfffffe008223b630 rtR0MemObjFreeBSDAllocHelper() at rtR0MemObjFreeBSDAllocHelper+0x96/frame 0xfffffe008223b6a0 rtR0MemObjNativeAllocCont() at rtR0MemObjNativeAllocCont+0x50/frame 0xfffffe008223b6f0 supdrvGipCreate() at supdrvGipCreate+0x97/frame 0xfffffe008223b790 supdrvInitDevExt() at supdrvInitDevExt+0x19a/frame 0xfffffe008223b800 VBoxDrvFreeBSDModuleEvent() at VBoxDrvFreeBSDModuleEvent+0x46/frame 0xfffffe008223b820 module_register_init() at module_register_init+0x94/frame 0xfffffe008223b850 linker_load_module() at linker_load_module+0xb78/frame 0xfffffe008223bb60 kern_kldload() at kern_kldload+0xa3/frame 0xfffffe008223bba0 sys_kldload() at sys_kldload+0x5b/frame 0xfffffe008223bbd0 amd64_syscall() at amd64_syscall+0xff/frame 0xfffffe008223bcf0 fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe008223bcf0 --- syscall (304, FreeBSD ELF64, sys_kldload), rip = 0x80037a11a, rsp = 0x7fffffffe598, rbp = 0x7fffffffeb10 --- KDB: enter: panic __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 55 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct pcpu, (kgdb) #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 #1 doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:394 #2 0xffffffff8035104a in db_dump (dummy=, dummy2=, dummy3=, dummy4=) at /usr/src/sys/ddb/db_command.c:575 #3 0xffffffff80350e10 in db_command (last_cmdp=, cmd_table=, dopager=1) at /usr/src/sys/ddb/db_command.c:482 #4 0xffffffff80350b7d in db_command_loop () at /usr/src/sys/ddb/db_command.c:535 #5 0xffffffff80353df6 in db_trap (type=, code=) at /usr/src/sys/ddb/db_main.c:270 #6 0xffffffff805983c3 in kdb_trap (type=3, code=0, tf=) at /usr/src/sys/kern/subr_kdb.c:699 #7 0xffffffff807ac26a in trap (frame=0xfffffe008223b0e0) at /usr/src/sys/amd64/amd64/trap.c:576 #8 #9 kdb_enter (why=0xffffffff80831558 "panic", msg=) at /usr/src/sys/kern/subr_kdb.c:486 #10 0xffffffff80552f0e in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:902 #11 0xffffffff80552d63 in panic ( fmt=0xffffffff80a8e688 "\275\317\203\200\377\377\377\377") at /usr/src/sys/kern/kern_shutdown.c:839 #12 0xffffffff807ac6a7 in trap_fatal (frame=0xfffffe008223b410, eva=507615962) at /usr/src/sys/amd64/amd64/trap.c:915 #13 0xffffffff807ac6f9 in trap_pfault (frame=0xfffffe008223b410, usermode=, signo=, ucode=) at /usr/src/sys/amd64/amd64/trap.c:732 #14 0xffffffff807abdd9 in trap (frame=0xfffffe008223b410) at /usr/src/sys/amd64/amd64/trap.c:398 #15 #16 vm_map_insert (map=, object=, offset=, start=18446741876713496576, end=18446741876713500672, prot=, max=7 '\a', cow=0) at /usr/src/sys/vm/vm_map.c:1660 #17 0xffffffff807341e9 in vm_map_find (map=, object=, offset=0, addr=, length=4096, max_addr=0, find_space=1, prot=3 '\003', max=7 '\a', cow=0) at /usr/src/sys/vm/vm_map.c:2156 #18 0xffffffff811c9326 in rtR0MemObjFreeBSDAllocHelper () from /boot/modules/vboxdrv.ko #19 0xffffffff811c94b0 in rtR0MemObjNativeAllocCont () from /boot/modules/vboxdrv.ko #20 0xffffffff811a6787 in supdrvGipCreate () from /boot/modules/vboxdrv.ko #21 0xffffffff8119f19a in supdrvInitDevExt () from /boot/modules/vboxdrv.ko #22 0xffffffff811aeff6 in VBoxDrvFreeBSDModuleEvent () from /boot/modules/vboxdrv.ko #23 0xffffffff8053a204 in module_register_init (arg=0x0) at /usr/src/sys/kern/kern_module.c:123 #24 0xffffffff8052df88 in linker_file_sysinit (lf=) at /usr/src/sys/kern/kern_linker.c:235 #25 linker_load_file (filename=, result=) at /usr/src/sys/kern/kern_linker.c:460 #26 linker_load_module (kldname=, modname=0xfffff80003525000 "vboxdrv", parent=0x0, verinfo=, lfpp=) at /usr/src/sys/kern/kern_linker.c:2129 #27 0xffffffff8052f5c3 in kern_kldload (td=, file=, fileid=0xfffffe008223bbb4) at /usr/src/sys/kern/kern_linker.c:1089 #28 0xffffffff8052f69b in sys_kldload (td=0xfffffe0081dd5c00, uap=) at /usr/src/sys/kern/kern_linker.c:1115 #29 0xffffffff807ace1f in syscallenter (td=0xfffffe0081dd5c00) at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:162 #30 amd64_syscall (td=0xfffffe0081dd5c00, traced=0) at /usr/src/sys/amd64/amd64/trap.c:1156 #31 #32 0x000000080037a11a in ?? () Backtrace stopped: Cannot access memory at address 0x7fffffffe598 (kgdb) Thank you From owner-freebsd-current@freebsd.org Tue Sep 22 22:51: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 9D1A83E2B2B for ; Tue, 22 Sep 2020 22:51:35 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-il1-x143.google.com (mail-il1-x143.google.com [IPv6:2607:f8b0:4864:20::143]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4BwxPf67vtz3Ynm; Tue, 22 Sep 2020 22:51:34 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-il1-x143.google.com with SMTP id s88so18951000ilb.6; Tue, 22 Sep 2020 15:51:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=1lt2X9dFdC8idIzes+JetVg8k+fWOAHUDC29xAKTaJk=; b=ITxy0eZGUpSSi9VMo5XZCUJWgRXCs7kMpbKbew9s/UlChVcNckK9BurxLaCnLDQe5b 6gy4pRYCwIGMqWfsatBcK53H6iuPeX6gIQCOD8XBN2eldZNLYMpCQZLl5w5LKsNOiI1v O2Om7iQxoCbuxL6eClYrVFawlg0Y787iSQ63tgKfhqvmdATZehOOYSuaF9f0Kx/m0b+G eJLYtXwMszIUFptWjT2AJQtqGRckcACKtG1NF7XZCXg9sAZ4hLKip1vybVq/6MSHsdtp MUQuLBw4l7B81DMu+ekoyysF85cp97jXsqS6I4J5IALtW1aivoOfTHaBosiJ+8y3boE0 INgA== X-Gm-Message-State: AOAM530+ZxSUJ/yCIxR77/oI65TVxXL7ITdFrlZ/AwAGezKH9fqpsA46 fima+CZ3L4NFL6pUvvOqqA0= X-Google-Smtp-Source: ABdhPJwcUfcG7Iip5RlBG6JXkHnlIFVRABeJ4MQIDR3wiZGZdfWURO2BXaopcWFKhkZR1myNHMinhg== X-Received: by 2002:a92:cb01:: with SMTP id s1mr6346318ilo.225.1600815093088; Tue, 22 Sep 2020 15:51:33 -0700 (PDT) Received: from raichu (toroon0560w-lp130-01-174-88-77-103.dsl.bell.ca. [174.88.77.103]) by smtp.gmail.com with ESMTPSA id u9sm7728169iow.26.2020.09.22.15.51.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 22 Sep 2020 15:51:32 -0700 (PDT) Sender: Mark Johnston Date: Tue, 22 Sep 2020 18:51:28 -0400 From: Mark Johnston To: Konstantin Belousov Cc: rhurlin@freebsd.org, Hans Petter Selasky , monochrome , freebsd-current@freebsd.org Subject: Re: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X Message-ID: <20200922225128.GA10974@raichu> References: <11d27d41-029a-d7f5-eccc-0ba3a3fcfe97@gwdg.de> <2bbfb4b3-92e9-b3ca-9c31-6c513cee2f2d@gwdg.de> <20200920093814.GD94807@kib.kiev.ua> <0249197f-29f6-4df4-eb63-ca786aaea39d@gwdg.de> <20200920195526.GH94807@kib.kiev.ua> <20200920200735.GJ94807@kib.kiev.ua> <1621df05-35a9-92b9-ffee-d93c17110d87@gwdg.de> <2673660d-3a6e-97c9-82a2-17b5ab8b987b@gwdg.de> <20200921221329.GD2570@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200921221329.GD2570@kib.kiev.ua> X-Rspamd-Queue-Id: 4BwxPf67vtz3Ynm X-Spamd-Bar: - X-Spamd-Result: default: False [-1.41 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; NEURAL_HAM_LONG(-1.03)[-1.031]; MIME_GOOD(-0.10)[text/plain]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_NA(0.00)[freebsd.org]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.31)[0.307]; DKIM_TRACE(0.00)[gmail.com:+]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::143:from]; NEURAL_HAM_MEDIUM(-0.99)[-0.986]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 22 Sep 2020 22:51:35 -0000 On Tue, Sep 22, 2020 at 01:13:29AM +0300, Konstantin Belousov wrote: > On Mon, Sep 21, 2020 at 08:57:46PM +0200, Rainer Hurling wrote: > > Fatal trap 12: page fault while in kernel mode > > cpuid = 31; apic id = 1f > > fault virtual address = 0x25407efa > This address is very suspicious. > > I cannot claim it as the fact, but most likely cause for such garbage > pointer value is mismatched ABI between kernel and module. In other > words, the module was built against headers from different kernel. For some reason clang is not complaining about a missing declaration for vm_pager_allocate(), despite -Wmissing-prototypes in the CFLAGS... This patch is required on top of a patched extract of the vbox sources: --- the-freebsd-kernel.h.orig 2020-09-22 18:49:26.499329000 -0400 +++ the-freebsd-kernel.h 2020-09-22 18:49:55.317615000 -0400 @@ -68,6 +68,7 @@ #include #include /* KERN_SUCCESS ++ */ #include +#include #include /* vm_phys_alloc_* */ #include /* kmem_alloc_attr */ #include /* vm_contig_grow_cache */ --- memobj-r0drv-freebsd.c.orig 2020-09-22 18:49:25.010456000 -0400 +++ memobj-r0drv-freebsd.c 2020-09-22 18:49:47.462276000 -0400 @@ -323,7 +323,8 @@ size_t cPages = atop(pMemFreeBSD->Core.cb); int rc; - pMemFreeBSD->pObject = vm_object_allocate(OBJT_PHYS, cPages); + pMemFreeBSD->pObject = vm_pager_allocate(OBJT_PHYS, NULL, + pMemFreeBSD->Core.cb, VM_PROT_ALL, 0, curthread->td_ucred); /* No additional object reference for auto-deallocation upon unmapping. */ #if __FreeBSD_version >= 1000055 @@ -457,7 +458,8 @@ return VERR_NO_MEMORY; } - pMemFreeBSD->pObject = vm_object_allocate(OBJT_PHYS, atop(cb)); + pMemFreeBSD->pObject = vm_pager_allocate(OBJT_PHYS, NULL, + pMemFreeBSD->Core.cb, VM_PROT_ALL, 0, curthread->td_ucred); if (PhysHighest != NIL_RTHCPHYS) VmPhysAddrHigh = PhysHighest; From owner-freebsd-current@freebsd.org Wed Sep 23 13:38: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 11B9E3F9B21 for ; Wed, 23 Sep 2020 13:38:11 +0000 (UTC) (envelope-from oleg@theweb.org.ua) Received: from sigill.theweb.org.ua (noc.quadranet.com [66.63.164.214]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "sigill.theweb.org.ua", Issuer "sigill.theweb.org.ua" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BxK4d2z7Qz4qMH for ; Wed, 23 Sep 2020 13:38:08 +0000 (UTC) (envelope-from oleg@theweb.org.ua) Received: from sigill.theweb.org.ua (localhost [127.0.0.1]) by sigill.theweb.org.ua (8.16.1/8.16.1) with ESMTPS id 08NDc4U6098615 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Wed, 23 Sep 2020 16:38:04 +0300 (EEST) (envelope-from oleg@theweb.org.ua) Received: (from oleg@localhost) by sigill.theweb.org.ua (8.16.1/8.16.1/Submit) id 08NDc48O098614 for freebsd-current@freebsd.org; Wed, 23 Sep 2020 16:38:04 +0300 (EEST) (envelope-from oleg@theweb.org.ua) X-Authentication-Warning: sigill.theweb.org.ua: oleg set sender to oleg@theweb.org.ua using -f From: "Oleg V. Nauman" To: freebsd-current@freebsd.org Subject: Re: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X Date: Wed, 23 Sep 2020 16:38:03 +0300 Message-ID: <2251935.mfXeX5GmMH@sigill.theweb.org.ua> Organization: Private persom In-Reply-To: <20200922225128.GA10974@raichu> References: <11d27d41-029a-d7f5-eccc-0ba3a3fcfe97@gwdg.de> <20200921221329.GD2570@kib.kiev.ua> <20200922225128.GA10974@raichu> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Rspamd-Queue-Id: 4BxK4d2z7Qz4qMH X-Spamd-Bar: ++++ X-Spamd-Result: default: False [4.12 / 15.00]; HFILTER_HELO_NORES_A_OR_MX(0.30)[sigill.theweb.org.ua]; HAS_XAW(0.00)[]; TO_DN_NONE(0.00)[]; HAS_ORG_HEADER(0.00)[]; HFILTER_HELO_IP_A(1.00)[sigill.theweb.org.ua]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; CTE_CASE(0.50)[]; ASN(0.00)[asn:8100, ipnet:66.63.164.0/23, country:US]; R_DKIM_NA(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[oleg]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.35)[0.347]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.52)[0.521]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[theweb.org.ua]; NEURAL_SPAM_LONG(0.56)[0.556]; R_SPF_NA(0.00)[no SPF record]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 23 Sep 2020 13:38:11 -0000 On 2020 M09 23, Wed 01:51:28 EEST Mark Johnston wrote: > On Tue, Sep 22, 2020 at 01:13:29AM +0300, Konstantin Belousov wrote: > > On Mon, Sep 21, 2020 at 08:57:46PM +0200, Rainer Hurling wrote: > > > Fatal trap 12: page fault while in kernel mode > > > cpuid = 31; apic id = 1f > > > fault virtual address = 0x25407efa > > > > This address is very suspicious. > > > > I cannot claim it as the fact, but most likely cause for such garbage > > pointer value is mismatched ABI between kernel and module. In other > > words, the module was built against headers from different kernel. > > For some reason clang is not complaining about a missing declaration for > vm_pager_allocate(), despite -Wmissing-prototypes in the CFLAGS... > > This patch is required on top of a patched extract of the vbox sources: > > --- the-freebsd-kernel.h.orig 2020-09-22 18:49:26.499329000 -0400 > +++ the-freebsd-kernel.h 2020-09-22 18:49:55.317615000 -0400 > @@ -68,6 +68,7 @@ > #include > #include /* KERN_SUCCESS ++ */ > #include > +#include > #include /* vm_phys_alloc_* */ > #include /* kmem_alloc_attr */ > #include /* vm_contig_grow_cache */ > --- memobj-r0drv-freebsd.c.orig 2020-09-22 18:49:25.010456000 -0400 > +++ memobj-r0drv-freebsd.c 2020-09-22 18:49:47.462276000 -0400 > @@ -323,7 +323,8 @@ > size_t cPages = atop(pMemFreeBSD->Core.cb); > int rc; > > - pMemFreeBSD->pObject = vm_object_allocate(OBJT_PHYS, cPages); > + pMemFreeBSD->pObject = vm_pager_allocate(OBJT_PHYS, NULL, > + pMemFreeBSD->Core.cb, VM_PROT_ALL, 0, curthread->td_ucred); > > /* No additional object reference for auto-deallocation upon unmapping. > */ #if __FreeBSD_version >= 1000055 > @@ -457,7 +458,8 @@ > return VERR_NO_MEMORY; > } > > - pMemFreeBSD->pObject = vm_object_allocate(OBJT_PHYS, atop(cb)); > + pMemFreeBSD->pObject = vm_pager_allocate(OBJT_PHYS, NULL, > + pMemFreeBSD->Core.cb, VM_PROT_ALL, 0, curthread->td_ucred); > > if (PhysHighest != NIL_RTHCPHYS) > VmPhysAddrHigh = PhysHighest; This fixed the issue with panic, thank you From owner-freebsd-current@freebsd.org Wed Sep 23 14:49: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 D2C763FBCE2 for ; Wed, 23 Sep 2020 14:49:13 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qk1-x744.google.com (mail-qk1-x744.google.com [IPv6:2607:f8b0:4864:20::744]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4BxLfd080cz3RV0; Wed, 23 Sep 2020 14:49:12 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qk1-x744.google.com with SMTP id n133so22989707qkn.11; Wed, 23 Sep 2020 07:49:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=mIcJzqZ8tyo+5rjuO/9879lhCHKAMFpROsQ+jAy7meM=; b=hPi01eTHQ/sfMzl3HwZW63bXothZPM5zBQZznq8oq8OwLiNNJpNdceucHTgfmyIMe5 xWouoY1nXHySH+p2snIiPZDEa16hEkCeLYNmjVUVg9KxYfuRvGBjpSdVZJjHKMrfkVKF hicEZB15NqMk0Zc45uSiWuEj2BTOvZ/KVH7LrStisjsn6wgymh2EyoXeFVGvMh0jvXOl qyn0r/LztLq+OvQmeCCxhKl/1wtgmdehzuiE3mdQpU9Ep084GvNOfR/UrJGlBFWgMadw +pJxpBoFS3+boowmknw/f1RO/9mYLwxUeKp7KB2FyvZClqBurMzRBpA8CaCXWxj2WJ6x Tszg== X-Gm-Message-State: AOAM532gKS0UYpD3z2Nkbzv4uuZrUFk+4f4BziLMLOnPC1U5/rlF/Kpv 9LXbCUYeQurjLEzGV1spX6E= X-Google-Smtp-Source: ABdhPJzrGOjEQkdxhmiGiTWkS3GI6CLMKj+YywK0lJlFGRFOcA/XDpDKLR/Lb22TTCh/FYvkv2i8jg== X-Received: by 2002:a05:620a:c97:: with SMTP id q23mr256733qki.168.1600872552059; Wed, 23 Sep 2020 07:49:12 -0700 (PDT) Received: from raichu (toroon0560w-lp130-01-174-88-77-103.dsl.bell.ca. [174.88.77.103]) by smtp.gmail.com with ESMTPSA id h65sm14812571qtd.58.2020.09.23.07.49.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2020 07:49:11 -0700 (PDT) Sender: Mark Johnston Date: Wed, 23 Sep 2020 10:49:08 -0400 From: Mark Johnston To: Konstantin Belousov Cc: rhurlin@freebsd.org, Hans Petter Selasky , monochrome , freebsd-current@freebsd.org Subject: Re: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X Message-ID: <20200923144908.GB10974@raichu> References: <2bbfb4b3-92e9-b3ca-9c31-6c513cee2f2d@gwdg.de> <20200920093814.GD94807@kib.kiev.ua> <0249197f-29f6-4df4-eb63-ca786aaea39d@gwdg.de> <20200920195526.GH94807@kib.kiev.ua> <20200920200735.GJ94807@kib.kiev.ua> <1621df05-35a9-92b9-ffee-d93c17110d87@gwdg.de> <2673660d-3a6e-97c9-82a2-17b5ab8b987b@gwdg.de> <20200921221329.GD2570@kib.kiev.ua> <20200922225128.GA10974@raichu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200922225128.GA10974@raichu> X-Rspamd-Queue-Id: 4BxLfd080cz3RV0 X-Spamd-Bar: - X-Spamd-Result: default: False [-1.84 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; NEURAL_HAM_LONG(-1.04)[-1.038]; MIME_GOOD(-0.10)[text/plain]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_NA(0.00)[freebsd.org]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; NEURAL_HAM_SHORT(-0.07)[-0.067]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::744:from]; NEURAL_HAM_MEDIUM(-1.03)[-1.033]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 23 Sep 2020 14:49:13 -0000 On Tue, Sep 22, 2020 at 06:51:28PM -0400, Mark Johnston wrote: > On Tue, Sep 22, 2020 at 01:13:29AM +0300, Konstantin Belousov wrote: > > On Mon, Sep 21, 2020 at 08:57:46PM +0200, Rainer Hurling wrote: > > > Fatal trap 12: page fault while in kernel mode > > > cpuid = 31; apic id = 1f > > > fault virtual address = 0x25407efa > > This address is very suspicious. > > > > I cannot claim it as the fact, but most likely cause for such garbage > > pointer value is mismatched ABI between kernel and module. In other > > words, the module was built against headers from different kernel. > > For some reason clang is not complaining about a missing declaration for > vm_pager_allocate(), despite -Wmissing-prototypes in the CFLAGS... It looks like the virtualbox makefiles helpfully add -w to the compiler invocation, so the build output is "sanitized." Of course, removing that flag uncovers a slew of warnings. :( In any case I submitted a patch to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=249326 From owner-freebsd-current@freebsd.org Wed Sep 23 16:35: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 1772D3FE435 for ; Wed, 23 Sep 2020 16:35:08 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from gmailer.gwdg.de (gmailer.gwdg.de [134.76.11.17]) (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 4BxP0q2zbbz3ZCb; Wed, 23 Sep 2020 16:35:07 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from excmbx-03.um.gwdg.de ([134.76.9.218] helo=email.gwdg.de) by mailer.gwdg.de with esmtp (GWDG Mailer) (envelope-from ) id 1kL7jV-0000tz-TS; Wed, 23 Sep 2020 18:35:05 +0200 Received: from krabat.raven.hur (10.250.9.199) by EXCMBX-03.um.gwdg.de (134.76.9.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2044.4; Wed, 23 Sep 2020 18:35:05 +0200 Subject: Re: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X To: Mark Johnston , Konstantin Belousov CC: Hans Petter Selasky , monochrome , References: <11d27d41-029a-d7f5-eccc-0ba3a3fcfe97@gwdg.de> <2bbfb4b3-92e9-b3ca-9c31-6c513cee2f2d@gwdg.de> <20200920093814.GD94807@kib.kiev.ua> <0249197f-29f6-4df4-eb63-ca786aaea39d@gwdg.de> <20200920195526.GH94807@kib.kiev.ua> <20200920200735.GJ94807@kib.kiev.ua> <1621df05-35a9-92b9-ffee-d93c17110d87@gwdg.de> <2673660d-3a6e-97c9-82a2-17b5ab8b987b@gwdg.de> <20200921221329.GD2570@kib.kiev.ua> <20200922225128.GA10974@raichu> Reply-To: "Hurling, Rainer" From: Rainer Hurling Message-ID: <77a92c5c-9d0a-6433-8879-7108730118dc@gwdg.de> Date: Wed, 23 Sep 2020 18:35:00 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.3.0 MIME-Version: 1.0 In-Reply-To: <20200922225128.GA10974@raichu> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.250.9.199] X-ClientProxiedBy: excmbx-25.um.gwdg.de (134.76.9.235) To EXCMBX-03.um.gwdg.de (134.76.9.218) X-Virus-Scanned: (clean) by clamav X-Rspamd-Queue-Id: 4BxP0q2zbbz3ZCb X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.74 / 15.00]; HAS_REPLYTO(0.00)[rhurlin@FreeBSD.org]; HAS_XOIP(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:134.76.10.0/23]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; RCVD_IN_DNSWL_MED(-0.20)[134.76.11.17:from]; NEURAL_HAM_SHORT(-0.24)[-0.241]; FREEMAIL_TO(0.00)[freebsd.org,gmail.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:680, ipnet:134.76.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[rhurlin]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_MEDIUM(-1.01)[-1.008]; NEURAL_HAM_LONG(-0.99)[-0.988]; MIME_GOOD(-0.10)[text/plain]; REPLYTO_DOM_NEQ_FROM_DOM(0.00)[]; DMARC_NA(0.00)[gwdg.de]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RWL_MAILSPIKE_VERYGOOD(0.00)[134.76.11.17:from]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 23 Sep 2020 16:35:08 -0000 On 23.09.20 00:51, Mark Johnston wrote: > On Tue, Sep 22, 2020 at 01:13:29AM +0300, Konstantin Belousov wrote: >> On Mon, Sep 21, 2020 at 08:57:46PM +0200, Rainer Hurling wrote: >>> Fatal trap 12: page fault while in kernel mode >>> cpuid = 31; apic id = 1f >>> fault virtual address = 0x25407efa >> This address is very suspicious. >> >> I cannot claim it as the fact, but most likely cause for such garbage >> pointer value is mismatched ABI between kernel and module. In other >> words, the module was built against headers from different kernel. > > For some reason clang is not complaining about a missing declaration for > vm_pager_allocate(), despite -Wmissing-prototypes in the CFLAGS... > > This patch is required on top of a patched extract of the vbox sources: > > --- the-freebsd-kernel.h.orig 2020-09-22 18:49:26.499329000 -0400 > +++ the-freebsd-kernel.h 2020-09-22 18:49:55.317615000 -0400 > @@ -68,6 +68,7 @@ > #include > #include /* KERN_SUCCESS ++ */ > #include > +#include > #include /* vm_phys_alloc_* */ > #include /* kmem_alloc_attr */ > #include /* vm_contig_grow_cache */ > --- memobj-r0drv-freebsd.c.orig 2020-09-22 18:49:25.010456000 -0400 > +++ memobj-r0drv-freebsd.c 2020-09-22 18:49:47.462276000 -0400 > @@ -323,7 +323,8 @@ > size_t cPages = atop(pMemFreeBSD->Core.cb); > int rc; > > - pMemFreeBSD->pObject = vm_object_allocate(OBJT_PHYS, cPages); > + pMemFreeBSD->pObject = vm_pager_allocate(OBJT_PHYS, NULL, > + pMemFreeBSD->Core.cb, VM_PROT_ALL, 0, curthread->td_ucred); > > /* No additional object reference for auto-deallocation upon unmapping. */ > #if __FreeBSD_version >= 1000055 > @@ -457,7 +458,8 @@ > return VERR_NO_MEMORY; > } > > - pMemFreeBSD->pObject = vm_object_allocate(OBJT_PHYS, atop(cb)); > + pMemFreeBSD->pObject = vm_pager_allocate(OBJT_PHYS, NULL, > + pMemFreeBSD->Core.cb, VM_PROT_ALL, 0, curthread->td_ucred); > > if (PhysHighest != NIL_RTHCPHYS) > VmPhysAddrHigh = PhysHighest; > I can confirm that these patches (two files) work for me. The system reboots with loaded vbox kernel modules. Many thanks for your help and investigations! Best regards, Rainer From owner-freebsd-current@freebsd.org Wed Sep 23 17:53: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 67841421367 for ; Wed, 23 Sep 2020 17:53:31 +0000 (UTC) (envelope-from xtouqh@hotmail.com) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-oln040092075053.outbound.protection.outlook.com [40.92.75.53]) (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 4BxQlC5xhmz3yJs; Wed, 23 Sep 2020 17:53:27 +0000 (UTC) (envelope-from xtouqh@hotmail.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=b02Ou+KCOM4CgfTWCZlAsHe8WYr0nIMOiVIHzJ+lofhJLEbnHGPKLKbkyRt10fA4AjMR3bBna019erudqqM4Cdwlm76BjsKG3SvgEQSFQAql4Un1WVBgjJFGKj7GQVPxHXmuwe6yQaLUd4jOjXxA7fz9ENLWYz1sP/FfsCUJtct7tk9TAo0k7JqQpJ/oyYGkJ04cvzefdUYostdqtIOqvwlCjOfJONMZY6lK/pNsGImnqsJIgkPFatuqz/AfqvRVpk7i/AzqHIqTryF8kXNT0dh2FAkUrCbXd4LqOeQCLPvY+CEd8Bp7EOiAJPodrQpXzd2DNify5+IxoFyA/em/DQ== 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=YkqSwLUSGinOA7CFcRqHSBw/+Ovj45vWjtqu6epQPRw=; b=FwTGchbkhTrRHU5IzRPnKmtTyAaRYX3MtD/mC0NE6QS76xWeAzsWyEMthes3z5XOPaPWyHkZGNHqV3FSg6Kn6rxXsix1qSTOCXiGe/bP4Ray4ldCQMg+FBySGUUQdLavleRUrV5AxbfRoLxRktwmcLqnNSTBAXj4WlkTXF3CTu9zwWM9EqyO68bQN5heA14Bg1FdPgSuzjexJPVSqzmK4YULrgTBDw7b/WsaqBcv5/wBFHJz8JH2r+1Iybn4HCPSzM2S1RX7cXmAZx9IDCB7RiBzuQjQaD4gSG51LkWMWr2RkmBP2dobaK8re5b2xxQiB+5jOIdsNe5se8jPVglgIQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Received: from DB3EUR04FT013.eop-eur04.prod.protection.outlook.com (2a01:111:e400:7e0c::51) by DB3EUR04HT051.eop-eur04.prod.protection.outlook.com (2a01:111:e400:7e0c::324) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.21; Wed, 23 Sep 2020 17:37:23 +0000 Received: from AM0PR06MB3986.eurprd06.prod.outlook.com (2a01:111:e400:7e0c::4f) by DB3EUR04FT013.mail.protection.outlook.com (2a01:111:e400:7e0c::277) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.21 via Frontend Transport; Wed, 23 Sep 2020 17:37:23 +0000 X-IncomingTopHeaderMarker: OriginalChecksum:C018A3804954EA71985E70E80604772474A8B94399D453E0A0BFCE44332E61F1; UpperCasedChecksum:E78222F3C8EC377DA389D3AC116B58A5A20C75910A4CC6B0CBF11589276E5E43; SizeAsReceived:8833; Count:49 Received: from AM0PR06MB3986.eurprd06.prod.outlook.com ([fe80::9dd1:2866:7eae:1ccf]) by AM0PR06MB3986.eurprd06.prod.outlook.com ([fe80::9dd1:2866:7eae:1ccf%7]) with mapi id 15.20.3391.027; Wed, 23 Sep 2020 17:37:23 +0000 Subject: Re: iflib/bridge kernel panic To: Kristof Provost , Shawn Webb Cc: FreeBSD Current References: <58CADEBB-64FD-414E-AB19-E4F8D3CABCA5@FreeBSD.org> From: xtouqh@hotmail.com Message-ID: Date: Wed, 23 Sep 2020 20:37:22 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.2.2 In-Reply-To: <58CADEBB-64FD-414E-AB19-E4F8D3CABCA5@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-ClientProxiedBy: AM0PR06CA0137.eurprd06.prod.outlook.com (2603:10a6:208:ab::42) To AM0PR06MB3986.eurprd06.prod.outlook.com (2603:10a6:208:b6::28) X-Microsoft-Original-Message-ID: <62291446-5b6d-70c0-3e86-57233e0c2241@hotmail.com> MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.6] (91.240.124.157) by AM0PR06CA0137.eurprd06.prod.outlook.com (2603:10a6:208:ab::42) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.14 via Frontend Transport; Wed, 23 Sep 2020 17:37:22 +0000 X-Microsoft-Original-Message-ID: <62291446-5b6d-70c0-3e86-57233e0c2241@hotmail.com> X-TMN: [TCMGujt9q/fLLEYHsoL4gFmutlDtdJ91] X-MS-PublicTrafficType: Email X-IncomingHeaderCount: 49 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-Correlation-Id: 2f11a013-01cb-4248-3f51-08d85fe75424 X-MS-TrafficTypeDiagnostic: DB3EUR04HT051: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: CfAFd5dmxUMUUWWGVZW8gtFC9B6P2II9scv/DG6BH0eXb+/naERiklsS89a/uoxKzKAgV39WN+a/9X5bQhFV+uuaOZV+Damy1rNNi+8PuvCMD1mB3Ay5k42WCS/cDFKC5orraYLGq/5uRABwPPrGx9zMfR9Ejxuq85Z1xVu6qQSrDM1Q9s+/TBGcB8l7iJ3UbNYflnY7nGNarOWUikN1SjUNDqZu16C//HwGoFz46dtT1MqePrs2HFBZPw3SO+Rl X-MS-Exchange-AntiSpam-MessageData: noCcXk1u1tVRbJ1ouuf9UeHKylqSN22U7yzp2AClhJYv9RR2AQfN0LFU6H1D48yLbva++5+A28ZvFFxyMUJkGdU3MW+w8RBIydtSvE9g2KAJ/6eLwMe2xRnoWlc8vkkVG/M/2CMDSbMU0MdXnDj70A== X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2f11a013-01cb-4248-3f51-08d85fe75424 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Sep 2020 17:37:23.5086 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-AuthSource: DB3EUR04FT013.eop-eur04.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3EUR04HT051 X-Rspamd-Queue-Id: 4BxQlC5xhmz3yJs X-Spamd-Bar: ++++++ X-Spamd-Result: default: False [6.56 / 15.00]; FREEMAIL_FROM(0.00)[hotmail.com]; R_SPF_ALLOW(0.00)[+ip4:40.92.0.0/15]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[hotmail.com:+]; DMARC_POLICY_ALLOW(0.00)[hotmail.com,none]; NEURAL_HAM_SHORT(-0.17)[-0.173]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[hotmail.com]; ASN(0.00)[asn:8075, ipnet:40.80.0.0/12, country:US]; FORGED_MUA_THUNDERBIRD_MSGID_UNKNOWN(2.50)[]; ARC_ALLOW(0.00)[microsoft.com:s=arcselector9901:i=1]; DWL_DNSWL_NONE(0.00)[hotmail.com:dkim]; RECEIVED_SPAMHAUS_XBL(5.00)[91.240.124.157:received]; R_DKIM_ALLOW(0.00)[hotmail.com:s=selector1]; RCVD_COUNT_FIVE(0.00)[5]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_MEDIUM(-0.19)[-0.187]; NEURAL_HAM_LONG(-0.58)[-0.584]; MIME_GOOD(-0.10)[text/plain]; BAD_REP_POLICIES(0.10)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_NO_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[40.92.75.53:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.92.75.53:from]; GREYLIST(0.00)[pass,body]; MAILMAN_DEST(0.00)[freebsd-current] X-Spam: Yes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 23 Sep 2020 17:53:31 -0000 Kristof Provost wrote: > On 21 Sep 2020, at 2:52, Shawn Webb wrote: >>> From latest HEAD on a Dell Precision 7550 laptop: >> >> https://gist.github.com/lattera/a0803f31f58bcf8ead51ac1ebbc447e2 >> >> The last working boot environment was 14 Aug 2020. If I get some time to >> bisect commits, I'll try to figure out the culprit. >> > Try https://reviews.freebsd.org/D26418 Anything stopping this from being integrated? From owner-freebsd-current@freebsd.org Wed Sep 23 17:54: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 6005B421273 for ; Wed, 23 Sep 2020 17:54:24 +0000 (UTC) (envelope-from kp@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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4BxQmJ1xNRz3ymW; Wed, 23 Sep 2020 17:54:24 +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 0C68A2866E; Wed, 23 Sep 2020 17:54:24 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: by venus.codepro.be (Postfix, authenticated sender kp) id 8E6551B36E; Wed, 23 Sep 2020 19:54:22 +0200 (CEST) From: "Kristof Provost" To: xtouqh@hotmail.com Cc: "Shawn Webb" , "FreeBSD Current" Subject: Re: iflib/bridge kernel panic Date: Wed, 23 Sep 2020 19:54:21 +0200 X-Mailer: MailMate (1.13.2r5673) Message-ID: <42B90E2E-7F9A-47B7-9FD5-F321E473EDFF@FreeBSD.org> In-Reply-To: References: <58CADEBB-64FD-414E-AB19-E4F8D3CABCA5@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; markup=markdown Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 23 Sep 2020 17:54:24 -0000 On 23 Sep 2020, at 19:37, xtouqh@hotmail.com wrote: > Kristof Provost wrote: >> On 21 Sep 2020, at 2:52, Shawn Webb wrote: >>>> From latest HEAD on a Dell Precision 7550 laptop: >>> >>> https://gist.github.com/lattera/a0803f31f58bcf8ead51ac1ebbc447e2 >>> >>> The last working boot environment was 14 Aug 2020. If I get some time to >>> bisect commits, I'll try to figure out the culprit. >>> >> Try https://reviews.freebsd.org/D26418 > > Anything stopping this from being integrated? Yes, it’s not correct. I’ve got this on my todo list. I think I know how to fix it better. Best regards, Kristof From owner-freebsd-current@freebsd.org Thu Sep 24 00:00:02 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 A37CB3E2EB0; Thu, 24 Sep 2020 00:00:02 +0000 (UTC) (envelope-from owner-freebsd-quarterly-calls@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4BxZtB3MTlz4Y8M; Thu, 24 Sep 2020 00:00:02 +0000 (UTC) (envelope-from owner-freebsd-quarterly-calls@freebsd.org) Delivered-To: freebsd-quarterly-calls@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 D9FD33E2F92; Thu, 24 Sep 2020 00:00:00 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (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-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 4BxZt84tD1z4YDt; Thu, 24 Sep 2020 00:00:00 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1471) id 9B8321953A; Thu, 24 Sep 2020 00:00:00 +0000 (UTC) To: freebsd-quarterly-calls@FreeBSD.org Subject: [LAST OFFICIAL REMINDER] Call for 2020Q3 quarterly status reports Message-Id: <20200924000000.9B8321953A@freefall.freebsd.org> Date: Thu, 24 Sep 2020 00:00:00 +0000 (UTC) From: Daniel Ebdrup Jensen ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1600905600; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc; bh=GsZkOQ98mtEG+Y4D3fU55qcSdX0+pLRfjUgDx/1c48s=; b=FkZfdhF1a6JX84Uqa8lqJh0iZo4oTxNwhkkKi9sC52mkkIdYRAM80T2BsO9HZkohKbub+m qwzxrGOS3mGo6exkJIw2unODx8EErXL2OBtEYnljPLY1wQfesS7yUrIUwl9Bc6IhFz6hWa tNmPUuvKJeJufVIQMqXbil0BwHEb91z9RVEFJxDGrhzEbbS8l8zqZd/AfAtiDB81h/t9gP +gMuXojWJS1Hi9LyhyaxL3ZGbwwlXc/wgX2Ig+wcKxzYGLVpo9yLY+ewW0TDaO14hA5mYF 3bM1UOis9iQzs+wXG+x1biGp9QiFdS/UCLkeTlNwPRbeTeaUKyjDlmb2IDc0sg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1600905600; a=rsa-sha256; cv=none; b=WH1PJKadEVrFu2s1qMxd85iOLEng16iOkVGmraSye+RqG4zNCFEWAjZpiL3BLCH59V16Lj 6Wgq+qWMBY2RK4/VnIwP5xNIyHET6c6TDzMF2iZ23tolxEQQauXZz2r5iXWtbFrxsTkum7 NJFlhrQlBhpSTSFSWDFU/TKWhsuhqhsw4q9YzhNQz+iC89fXSOCFiZALlovRZYdRyYTkid NHieaON2zKeiTvCWTZPpysEg7KNwrnannybvkzQXwF2/ipdFejunZNHgQjhhNO/KpwAL/t St1E6WIL13i3C/TGunuH8olHwRXoenq+KHqthLlN07nSzXsoyVlgojrDg+VltQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-BeenThere: freebsd-quarterly-calls@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: owner-freebsd-quarterly-calls@freebsd.org Sender: owner-freebsd-quarterly-calls@freebsd.org X-Mailman-Approved-At: Thu, 24 Sep 2020 01:19:16 +0000 X-BeenThere: freebsd-current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2020 00:00:02 -0000 Dear FreeBSD Community, The deadline for the next FreeBSD Quarterly Status update is October, 1st 2020 for work done since the last round of Quarterly Reports: July 2020 - September 2020. I would like to remind you that reports are collected during the last month of every quarter. Status report submissions do not need to be very long. They may be about anything happening in the FreeBSD project and community, and they provide a great way to inform FreeBSD users and developers about work that is underway or has been completed. Report submissions are not limited to committers; anyone doing anything interesting and FreeBSD related can -- and should -- write one! The preferred method is to follow the guidelines at the Quarterly GitHub repository: https://github.com/freebsd/freebsd-quarterly Alternatively you can fetch the Markdown template, fill it in, and email it to quarterly-submissions@FreeBSD.org. The template can be found at: https://raw.githubusercontent.com/freebsd/freebsd-quarterly/master/report-sample.md We look forward to seeing your 2020Q3 reports! Thanks, Daniel Ebdrup Jensen (on behalf of quarterly@) _______________________________________________ freebsd-quarterly-calls@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-quarterly-calls To unsubscribe, send any mail to "freebsd-quarterly-calls-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Thu Sep 24 09:17: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 91EBD3F1A97 for ; Thu, 24 Sep 2020 09:17:43 +0000 (UTC) (envelope-from monochrome@twcny.rr.com) Received: from p-impout001.msg.pkvw.co.charter.net (p-impout010aa.msg.pkvw.co.charter.net [47.43.26.141]) (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 4BxqFf1V6vz4B69 for ; Thu, 24 Sep 2020 09:17:41 +0000 (UTC) (envelope-from monochrome@twcny.rr.com) Received: from [192.168.13.11] ([45.47.33.158]) by cmsmtp with ESMTP id LNNckI4mkvmn7LNNekE1cQ; Thu, 24 Sep 2020 09:17:34 +0000 X-Authority-Analysis: v=2.3 cv=GdJpYjfL c=1 sm=1 tr=0 a=VvwePSPmDFBOGFNvGtd2Cw==:117 a=VvwePSPmDFBOGFNvGtd2Cw==:17 a=IkcTkHD0fZMA:10 a=b7RcBn1CbnprctDlzTIA:9 a=x4tplhRPxbVYnnSW:21 a=QEXdDO2ut3YA:10 To: freebsd-current@freebsd.org From: monochrome Subject: geeqie, and neverball build problem on 13-current Message-ID: <59b99301-028c-132a-c974-30608ea18d24@twcny.rr.com> Date: Thu, 24 Sep 2020 05:17:31 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfF46HmWLHo75bHGufAFiQslGmWg/OPB+H41kbOCowK9q1tgGHya6/3Yb7FDX7crsWDH7kfi26VQBAifDEpsQXMc93uyHTXtu47DL4PmvT25cPCv1PvhR DWS0HMPQjysPbhXieYBi+Wij5Zo5BxV5jg7RBSOkEvfJKszHi2dvH4cQokX6BZMksBdzDAjxfwStZA== X-Rspamd-Queue-Id: 4BxqFf1V6vz4B69 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.03 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[45.47.33.158:received]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:47.43.26.0/24]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[rr.com]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.93)[-0.929]; NEURAL_HAM_MEDIUM(-0.96)[-0.956]; NEURAL_SPAM_SHORT(0.16)[0.159]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:40294, ipnet:47.43.24.0/21, country:US]; MIME_TRACE(0.00)[0:+]; MAILMAN_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 24 Sep 2020 09:17:43 -0000 Not sure how long this has been a problem, I noticed with the new version of geeqie (geeqie-devel builds fine) and found the neverball problem when rebuilding all packages to investigate. neverball output changes with consecutive build attempts, geeqie does not. ------------------------------- geeqie output: first some of these: /usr/local/include/gtk-2.0/gtk/gtktooltips.h:73:3: warning: 'GTimeVal' is deprecated: Use 'GDateTime' instead [-Wdeprecated-declarations] then c++ -I/usr/local/include -pthread -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include/gtk-2.0 -I/usr/local/include/pango-1.0 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include -I/usr/local/include/fribidi -I/usr/local/include/cairo -I/usr/local/include/pixman-1 -I/usr/local/include/freetype2 -I/usr/local/include/libdrm -I/usr/local/include/libpng16 -I/usr/local/include/harfbuzz -I/usr/local/include/gdk-pixbuf-2.0 -I/usr/local/include/atk-1.0 -D_THREAD_SAFE -pthread -I/usr/local/include -I/usr/local/include -I/usr/local/include/lua53 -I.. -I.. -O2 -pipe -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing -isystem /usr/local/include -fstack-protector-strong -o geeqie ui_bookmark.o ui_fileops.o ui_help.o ui_menu.o ui_misc.o ui_pathsel.o ui_spinner.o ui_tabcomp.o ui_tree_edit.o ui_utildlg.o pan-view/pan-calendar.o pan-view/pan-folder.o pan-view/pan-grid.o pan-view/pan-item.o pan-view/pan-timeline.o pan-view/pan-util.o pan-view/pan-view.o pan-view/pan-view-filter.o pan-view/pan-view-search.o view_file/view_file.o view_file/view_file_icon.o view_file/view_file_list.o advanced_exif.o bar.o bar_comment.o bar_gps.o bar_histogram.o bar_keywords.o bar_exif.o bar_sort.o cache.o cache-loader.o cache_maint.o cellrenderericon.o collect.o collect-dlg.o collect-io.o collect-table.o color-man.o compat.o debug.o desktop_file.o dnd.o dupe.o editors.o exif.o exif-common.o exiv2.o filecache.o filedata.o filefilter.o gq-marshal.o format_canon.o format_fuji.o format_nikon.o format_olympus.o format_raw.o fullscreen.o histogram.o history_list.o image.o image-load.o image_load_gdk.o image_load_jpeg.o image_load_tiff.o image_load_dds.o image_load_collection.o image_load_pdf.o image_load_ffmpegthumbnailer.o image-overlay.o img-view.o jpeg_parser.o layout.o layout_config.o layout_image.o layout_util.o keymap_template.o lirc.o logwindow.o main.o md5-util.o menu.o metadata.o misc.o options.o osd.o pixbuf-renderer.o renderer-tiles.o renderer-clutter.o pixbuf_util.o preferences.o print.o remote.o rcfile.o search.o secure_save.o shortcuts.o similar.o slideshow.o thumb.o thumb_standard.o toolbar.o trash.o uri_utils.o utilops.o view_dir.o view_dir_list.o view_dir_tree.o window.o lua.o zonedetect.o -L/usr/local/lib -lgtk-x11-2.0 -lgdk-x11-2.0 -lpangocairo-1.0 -latk-1.0 -lcairo -lpthread -lgdk_pixbuf-2.0 -lgio-2.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lintl -lfontconfig -lfreetype -L/usr/local/lib -lgthread-2.0 -pthread -lglib-2.0 -lintl -lintl -ljpeg -ltiff -L/usr/local/lib -llcms2 -L/usr/local/lib -lexiv2 -L/usr/local/lib -llua-5.3 -lm -L/usr/local/lib ld: error: duplicate symbol: bar_exif_key_count >>> defined at pan-view.c >>> pan-view/pan-view.o:(bar_exif_key_count) >>> defined at advanced_exif.c >>> advanced_exif.o:(.rodata+0x0) ld: error: duplicate symbol: bar_exif_key_list >>> defined at pan-view.c >>> pan-view/pan-view.o:(bar_exif_key_list) >>> defined at advanced_exif.c >>> advanced_exif.o:(.bss+0x0) ld: error: duplicate symbol: bar_exif_key_count >>> defined at pan-view.c >>> pan-view/pan-view.o:(bar_exif_key_count) >>> defined at bar.c >>> bar.o:(.rodata+0x180) ld: error: duplicate symbol: bar_exif_key_list >>> defined at pan-view.c >>> pan-view/pan-view.o:(bar_exif_key_list) >>> defined at bar.c >>> bar.o:(.bss+0x0) ld: error: duplicate symbol: bar_exif_key_count >>> defined at pan-view.c >>> pan-view/pan-view.o:(bar_exif_key_count) >>> defined at bar_exif.c >>> bar_exif.o:(.rodata+0x0) ld: error: duplicate symbol: bar_exif_key_list >>> defined at pan-view.c >>> pan-view/pan-view.o:(bar_exif_key_list) >>> defined at bar_exif.c >>> bar_exif.o:(.bss+0x0) ld: error: duplicate symbol: bar_exif_key_count >>> defined at pan-view.c >>> pan-view/pan-view.o:(bar_exif_key_count) >>> defined at options.c >>> options.o:(.rodata+0x0) ld: error: duplicate symbol: bar_exif_key_list >>> defined at pan-view.c >>> pan-view/pan-view.o:(bar_exif_key_list) >>> defined at options.c >>> options.o:(.bss+0x0) ld: error: duplicate symbol: bar_exif_key_count >>> defined at pan-view.c >>> pan-view/pan-view.o:(bar_exif_key_count) >>> defined at preferences.c >>> preferences.o:(.rodata+0x30) ld: error: duplicate symbol: bar_exif_key_list >>> defined at pan-view.c >>> pan-view/pan-view.o:(bar_exif_key_list) >>> defined at preferences.c >>> preferences.o:(.bss+0x10) ld: error: duplicate symbol: bar_exif_key_count >>> defined at pan-view.c >>> pan-view/pan-view.o:(bar_exif_key_count) >>> defined at rcfile.c >>> rcfile.o:(.rodata+0x84) ld: error: duplicate symbol: bar_exif_key_list >>> defined at pan-view.c >>> pan-view/pan-view.o:(bar_exif_key_list) >>> defined at rcfile.c >>> rcfile.o:(.bss+0x0) c++: error: linker command failed with exit code 1 (use -v to see invocation) gmake[5]: *** [Makefile:926: geeqie] Error 1 gmake[5]: Leaving directory '/usr/ports/graphics/geeqie/work/geeqie-1.5.1/src' gmake[4]: *** [Makefile:1093: all-recursive] Error 1 gmake[4]: Leaving directory '/usr/ports/graphics/geeqie/work/geeqie-1.5.1/src' gmake[3]: *** [Makefile:674: all-recursive] Error 1 gmake[3]: Leaving directory '/usr/ports/graphics/geeqie/work/geeqie-1.5.1' gmake[2]: *** [Makefile:506: all] Error 2 gmake[2]: Leaving directory '/usr/ports/graphics/geeqie/work/geeqie-1.5.1' ===> Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to the maintainer. *** Error code 1 Stop. Stop. make[1]: stopped in /usr/ports/graphics/geeqie *** Error code 1 Stop. make: stopped in /usr/ports/graphics/geeqie ------------------------------------ neverball output cc -Wall -Wshadow -std=c99 -pedantic -O2 -pipe -DLIBICONV_PLUG -fstack-protector-strong -fno-strict-aliasing -o neverball share/lang.o share/st_common.o share/vec3.o share/base_image.o share/image.o share/solid_base.o share/solid_vary.o share/solid_draw.o share/solid_all.o share/mtrl.o share/part.o share/geom.o share/ball.o share/gui.o share/font.o share/theme.o share/base_config.o share/config.o share/video.o share/glext.o share/binary.o share/state.o share/audio.o share/text.o share/common.o share/list.o share/queue.o share/cmd.o share/array.o share/dir.o share/fbo.o share/glsl.o share/fs_common.o share/fs_png.o share/fs_jpg.o share/fs_rwops.o share/fs_ov.o share/log.o ball/hud.o ball/game_common.o ball/game_client.o ball/game_server.o ball/game_proxy.o ball/game_draw.o ball/score.o ball/level.o ball/progress.o ball/set.o ball/demo.o ball/demo_dir.o ball/util.o ball/st_conf.o ball/st_demo.o ball/st_save.o ball/st_goal.o ball/st_fail.o ball/st_done.o ball/st_level.o ball/st_over.o ball/st_play.o ball/st_set.o ball/st_start.o ball/st_title.o ball/st_help.o ball/st_name.o ball/st_shared.o ball/st_pause.o ball/st_ball.o ball/main.o share/solid_sim_sol.o share/fs_physfs.o share/tilt_null.o share/hmd_null.o -fstack-protector-strong -lSDL2_ttf -lvorbisfile -L/usr/local/lib -lSDL2 -lGL -ljpeg -lpng16 -lphysfs -lm -L/usr/local/lib ld: error: duplicate symbol: text_input >>> defined at text.c >>> share/text.o:(text_input) >>> defined at st_save.c >>> ball/st_save.o:(.bss+0x10) ld: error: duplicate symbol: text_input >>> defined at text.c >>> share/text.o:(text_input) >>> defined at st_name.c >>> ball/st_name.o:(.bss+0x20) ld: error: duplicate symbol: text_input >>> defined at text.c >>> share/text.o:(text_input) >>> defined at main.c >>> ball/main.o:(.bss+0x1080) cc: error: linker command failed with exit code 1 (use -v to see invocation) gmake[2]: *** [Makefile:434: neverball] Error 1 gmake[2]: *** Waiting for unfinished jobs.... msggrep: warning: Locale charset "ASCII" is different from input file charset "UTF-8". Output of 'msggrep' might be incorrect. Possible workarounds are: - Set LC_ALL to a locale with encoding UTF-8. - Convert the translation catalog to ASCII using 'msgconv', then apply 'msggrep', then convert back to UTF-8 using 'msgconv'. msggrep: warning: Locale charset "ASCII" is different from input file charset "UTF-8". Output of 'msggrep' might be incorrect. Possible workarounds are: - Set LC_ALL to a locale with encoding UTF-8. - Convert the translation catalog to ASCII using 'msgconv', then apply 'msggrep', then convert back to UTF-8 using 'msgconv'. msggrep: warning: Locale charset "ASCII" is different from input file charset "UTF-8". Output of 'msggrep' might be incorrect. Possible workarounds are: - Set LC_ALL to a locale with encoding UTF-8. - Convert the translation catalog to ASCII using 'msgconv', then apply 'msggrep', then convert back to UTF-8 using 'msgconv'. msggrep: warning: Locale charset "ASCII" is different from input file charset "UTF-8". Output of 'msggrep' might be incorrect. Possible workarounds are: - Set LC_ALL to a locale with encoding UTF-8. - Convert the translation catalog to ASCII using 'msgconv', then apply 'msggrep', then convert back to UTF-8 using 'msgconv'. msggrep: warning: Locale charset "ASCII" is different from input file charset "UTF-8". Output of 'msggrep' might be incorrect. Possible workarounds are: - Set LC_ALL to a locale with encoding UTF-8. - Convert the translation catalog to ASCII using 'msgconv', then apply 'msggrep', then convert back to UTF-8 using 'msgconv'. msggrep: warning: Locale charset "ASCII" is different from input file charset "UTF-8". Output of 'msggrep' might be incorrect. Possible workarounds are: - Set LC_ALL to a locale with encoding UTF-8. - Convert the translation catalog to ASCII using 'msgconv', then apply 'msggrep', then convert back to UTF-8 using 'msgconv'. msggrep: warning: Locale charset "ASCII" is different from input file charset "UTF-8". Output of 'msggrep' might be incorrect. Possible workarounds are: - Set LC_ALL to a locale with encoding UTF-8. - Convert the translation catalog to ASCII using 'msgconv', then apply 'msggrep', then convert back to UTF-8 using 'msgconv'. msggrep: warning: Locale charset "ASCII" is different from input file charset "UTF-8". Output of 'msggrep' might be incorrect. Possible workarounds are: - Set LC_ALL to a locale with encoding UTF-8. - Convert the translation catalog to ASCII using 'msgconv', then apply 'msggrep', then convert back to UTF-8 using 'msgconv'. msggrep: warning: Locale charset "ASCII" is different from input file charset "UTF-8". Output of 'msggrep' might be incorrect. Possible workarounds are: - Set LC_ALL to a locale with encoding UTF-8. - Convert the translation catalog to ASCII using 'msgconv', then apply 'msggrep', then convert back to UTF-8 using 'msgconv'. msggrep: warning: Locale charset "ASCII" is different from input file charset "UTF-8". Output of 'msggrep' might be incorrect. Possible workarounds are: - Set LC_ALL to a locale with encoding UTF-8. - Convert the translation catalog to ASCII using 'msgconv', then apply 'msggrep', then convert back to UTF-8 using 'msgconv'. msggrep: warning: Locale charset "ASCII" is different from input file charset "UTF-8". Output of 'msggrep' might be incorrect. Possible workarounds are: - Set LC_ALL to a locale with encoding UTF-8. - Convert the translation catalog to ASCII using 'msgconv', then apply 'msggrep', then convert back to UTF-8 using 'msgconv'. msggrep: warning: Locale charset "ASCII" is different from input file charset "UTF-8". Output of 'msggrep' might be incorrect. Possible workarounds are: - Set LC_ALL to a locale with encoding UTF-8. - Convert the translation catalog to ASCII using 'msgconv', then apply 'msggrep', then convert back to UTF-8 using 'msgconv'. msggrep: warning: Locale charset "ASCII" is different from input file charset "UTF-8". Output of 'msggrep' might be incorrect. Possible workarounds are: - Set LC_ALL to a locale with encoding UTF-8. - Convert the translation catalog to ASCII using 'msgconv', then apply 'msggrep', then convert back to UTF-8 using 'msgconv'. msggrep: warning: Locale charset "ASCII" is different from input file charset "UTF-8". Output of 'msggrep' might be incorrect. Possible workarounds are: - Set LC_ALL to a locale with encoding UTF-8. - Convert the translation catalog to ASCII using 'msgconv', then apply 'msggrep', then convert back to UTF-8 using 'msgconv'. msggrep: warning: Locale charset "ASCII" is different from input file charset "UTF-8". Output of 'msggrep' might be incorrect. Possible workarounds are: - Set LC_ALL to a locale with encoding UTF-8. - Convert the translation catalog to ASCII using 'msgconv', then apply 'msggrep', then convert back to UTF-8 using 'msgconv'. msggrep: warning: Locale charset "ASCII" is different from input file charset "UTF-8". Output of 'msggrep' might be incorrect. Possible workarounds are: - Set LC_ALL to a locale with encoding UTF-8. - Convert the translation catalog to ASCII using 'msgconv', then apply 'msggrep', then convert back to UTF-8 using 'msgconv'. msggrep: warning: Locale charset "ASCII" is different from input file charset "UTF-8". Output of 'msggrep' might be incorrect. Possible workarounds are: - Set LC_ALL to a locale with encoding UTF-8. - Convert the translation catalog to ASCII using 'msgconv', then apply 'msggrep', then convert back to UTF-8 using 'msgconv'. msggrep: warning: Locale charset "ASCII" is different from input file charset "UTF-8". Output of 'msggrep' might be incorrect. Possible workarounds are: - Set LC_ALL to a locale with encoding UTF-8. - Convert the translation catalog to ASCII using 'msgconv', then apply 'msggrep', then convert back to UTF-8 using 'msgconv'. msggrep: warning: Locale charset "ASCII" is different from input file charset "UTF-8". Output of 'msggrep' might be incorrect. Possible workarounds are: - Set LC_ALL to a locale with encoding UTF-8. - Convert the translation catalog to ASCII using 'msgconv', then apply 'msggrep', then convert back to UTF-8 using 'msgconv'. msggrep: warning: Locale charset "ASCII" is different from input file charset "UTF-8". Output of 'msggrep' might be incorrect. Possible workarounds are: - Set LC_ALL to a locale with encoding UTF-8. - Convert the translation catalog to ASCII using 'msgconv', then apply 'msggrep', then convert back to UTF-8 using 'msgconv'. msggrep: warning: Locale charset "ASCII" is different from input file charset "UTF-8". Output of 'msggrep' might be incorrect. Possible workarounds are: - Set LC_ALL to a locale with encoding UTF-8. - Convert the translation catalog to ASCII using 'msgconv', then apply 'msggrep', then convert back to UTF-8 using 'msgconv'. msggrep: warning: Locale charset "ASCII" is different from input file charset "UTF-8". Output of 'msggrep' might be incorrect. Possible workarounds are: - Set LC_ALL to a locale with encoding UTF-8. - Convert the translation catalog to ASCII using 'msgconv', then apply 'msggrep', then convert back to UTF-8 using 'msgconv'. msggrep: warning: Locale charset "ASCII" is different from input file charset "UTF-8". Output of 'msggrep' might be incorrect. Possible workarounds are: - Set LC_ALL to a locale with encoding UTF-8. - Convert the translation catalog to ASCII using 'msgconv', then apply 'msggrep', then convert back to UTF-8 using 'msgconv'. msggrep: warning: Locale charset "ASCII" is different from input file charset "UTF-8". Output of 'msggrep' might be incorrect. Possible workarounds are: - Set LC_ALL to a locale with encoding UTF-8. - Convert the translation catalog to ASCII using 'msgconv', then apply 'msggrep', then convert back to UTF-8 using 'msgconv'. msggrep: warning: Locale charset "ASCII" is different from input file charset "UTF-8". Output of 'msggrep' might be incorrect. Possible workarounds are: - Set LC_ALL to a locale with encoding UTF-8. - Convert the translation catalog to ASCII using 'msgconv', then apply 'msggrep', then convert back to UTF-8 using 'msgconv'. msggrep: warning: Locale charset "ASCII" is different from input file charset "UTF-8". Output of 'msggrep' might be incorrect. Possible workarounds are: - Set LC_ALL to a locale with encoding UTF-8. - Convert the translation catalog to ASCII using 'msgconv', then apply 'msggrep', then convert back to UTF-8 using 'msgconv'. msggrep: warning: Locale charset "ASCII" is different from input file charset "UTF-8". Output of 'msggrep' might be incorrect. Possible workarounds are: - Set LC_ALL to a locale with encoding UTF-8. - Convert the translation catalog to ASCII using 'msgconv', then apply 'msggrep', then convert back to UTF-8 using 'msgconv'. msggrep: warning: Locale charset "ASCII" is different from input file charset "UTF-8". Output of 'msggrep' might be incorrect. Possible workarounds are: - Set LC_ALL to a locale with encoding UTF-8. - Convert the translation catalog to ASCII using 'msgconv', then apply 'msggrep', then convert back to UTF-8 using 'msgconv'. msggrep: warning: Locale charset "ASCII" is different from msggrep: warning: Locale charset "ASCII" is different from input file charset "UTF-8". Output of 'msggrep' might be incorrect. Possible workarounds are: - Set LC_ALL to a locale with encoding UTF-8. - Convert the translation catalog to ASCII using 'msgconv', then apply 'msggrep', then convert back to UTF-8 using 'msgconv'. input file charset "UTF-8". Output of 'msggrep' might be incorrect. Possible workarounds are: - Set LC_ALL to a locale with encoding UTF-8. - Convert the translation catalog to ASCII using 'msgconv', then apply 'msggrep', then convert back to UTF-8 using 'msgconv'. msggrep: warning: Locale charset "ASCII" is different from input file charset "UTF-8". Output of 'msggrep' might be incorrect. Possible workarounds are: - Set LC_ALL to a locale with encoding UTF-8. - Convert the translation catalog to ASCII using 'msgconv', then apply 'msggrep', then convert back to UTF-8 using 'msgconv'. msggrep: warning: Locale charset "ASCII" is different from input file charset "UTF-8". Output of 'msggrep' might be incorrect. Possible workarounds are: - Set LC_ALL to a locale with encoding UTF-8. - Convert the translation catalog to ASCII using 'msgconv', then apply 'msggrep', then convert back to UTF-8 using 'msgconv'. msggrep: warning: Locale charset "ASCII" is different from input file charset "UTF-8". Output of 'msggrep' might be incorrect. Possible workarounds are: - Set LC_ALL to a locale with encoding UTF-8. - Convert the translation catalog to ASCII using 'msgconv', then apply 'msggrep', then convert back to UTF-8 using 'msgconv'. msggrep: warning: Locale charset "ASCII" is different from input file charset "UTF-8". Output of 'msggrep' might be incorrect. Possible workarounds are: - Set LC_ALL to a locale with encoding UTF-8. - Convert the translation catalog to ASCII using 'msgconv', then apply 'msggrep', then convert back to UTF-8 using 'msgconv'. msggrep: warning: Locale charset "ASCII" is different from input file charset "UTF-8". Output of 'msggrep' might be incorrect. Possible workarounds are: - Set LC_ALL to a locale with encoding UTF-8. - Convert the translation catalog to ASCII using 'msgconv', then apply 'msggrep', then convert back to UTF-8 using 'msgconv'. msggrep: warning: Locale charset "ASCII" is different from input file charset "UTF-8". Output of 'msggrep' might be incorrect. Possible workarounds are: - Set LC_ALL to a locale with encoding UTF-8. - Convert the translation catalog to ASCII using 'msgconv', then apply 'msggrep', then convert back to UTF-8 using 'msgconv'. msggrep: warning: Locale charset "ASCII" is different from input file charset "UTF-8". Output of 'msggrep' might be incorrect. Possible workarounds are: - Set LC_ALL to a locale with encoding UTF-8. - Convert the translation catalog to ASCII using 'msgconv', then apply 'msggrep', then convert back to UTF-8 using 'msgconv'. msggrep: warning: Locale charset "ASCII" is different from input file charset "UTF-8". Output of 'msggrep' might be incorrect. Possible workarounds are: - Set LC_ALL to a locale with encoding UTF-8. - Convert the translation catalog to ASCII using 'msgconv', then apply 'msggrep', then convert back to UTF-8 using 'msgconv'. msggrep: warning: Locale charset "ASCII" is different from input file charset "UTF-8". Output of 'msggrep' might be incorrect. Possible workarounds are: - Set LC_ALL to a locale with encoding UTF-8. - Convert the translation catalog to ASCII using 'msgconv', then apply 'msggrep', then convert back to UTF-8 using 'msgconv'. msggrep: warning: Locale charset "ASCII" is different from input file charset "UTF-8". Output of 'msggrep' might be incorrect. Possible workarounds are: - Set LC_ALL to a locale with encoding UTF-8. - Convert the translation catalog to ASCII using 'msgconv', then apply 'msggrep', then convert back to UTF-8 using 'msgconv'. gmake[2]: Leaving directory '/usr/ports/games/neverball/work/neverball-1.6.0' ===> Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to the maintainer. *** Error code 1 Stop. make[1]: stopped in /usr/ports/games/neverball *** Error code 1 Stop. make: stopped in /usr/ports/games/neverball ---------------------------- From owner-freebsd-current@freebsd.org Thu Sep 24 09:24: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 4B4023F1CF1 for ; Thu, 24 Sep 2020 09:24:52 +0000 (UTC) (envelope-from zeising+freebsd@daemonic.se) Received: from mail.daemonic.se (mail.daemonic.se [IPv6:2607:f740:d:20::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BxqPv1mxfz4CLy for ; Thu, 24 Sep 2020 09:24:50 +0000 (UTC) (envelope-from zeising+freebsd@daemonic.se) Received: from cid.daemonic.se (localhost [IPv6:::1]) by mail.daemonic.se (Postfix) with ESMTP id 4BxqPr4QB2z3nDJ; Thu, 24 Sep 2020 09:24:48 +0000 (UTC) X-Virus-Scanned: amavisd-new at daemonic.se Received: from mail.daemonic.se ([IPv6:::1]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256) by cid.daemonic.se (mailscanner.daemonic.se [IPv6:::1]) (amavisd-new, port 10587) with ESMTPS id NkvnoHeSuXRB; Thu, 24 Sep 2020 09:24:48 +0000 (UTC) Received: from garnet.daemonic.se (host-95-194-26-120.mobileonline.telia.com [95.194.26.120]) by mail.daemonic.se (Postfix) with ESMTPSA id 4BxqPr0F9Tz3nDG; Thu, 24 Sep 2020 09:24:47 +0000 (UTC) Subject: Re: geeqie, and neverball build problem on 13-current To: monochrome , freebsd-current@freebsd.org References: <59b99301-028c-132a-c974-30608ea18d24@twcny.rr.com> From: Niclas Zeising Message-ID: <70e5cb57-c78c-39cc-d7f8-20afbefe00fa@daemonic.se> Date: Thu, 24 Sep 2020 11:24:47 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <59b99301-028c-132a-c974-30608ea18d24@twcny.rr.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4BxqPv1mxfz4CLy X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.59 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[daemonic.se:s=20151023]; FREEFALL_USER(0.00)[zeising]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.01)[-1.013]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[daemonic.se:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[daemonic.se,none]; NEURAL_HAM_SHORT(-0.65)[-0.645]; NEURAL_HAM_MEDIUM(-0.93)[-0.931]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:36236, ipnet:2607:f740:d::/48, country:US]; TAGGED_FROM(0.00)[freebsd]; MAILMAN_DEST(0.00)[freebsd-current]; RECEIVED_SPAMHAUS_PBL(0.00)[95.194.26.120:received] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 24 Sep 2020 09:24:52 -0000 On 2020-09-24 11:17, monochrome wrote: > Not sure how long this has been a problem, I noticed with the new > version of geeqie (geeqie-devel builds fine) and found the neverball > problem when rebuilding all packages to investigate. neverball output > changes with consecutive build attempts, geeqie does not. > > This is related to the update of llvm to 11. With this update, builds are by default using -fno-common, which means global variables cannot exist in multiple places. gcc 10 has the same default. A quick fix is to add -fcommon to CFLAGS, but the proper fix is to update the application source to only have the variable in one place. Regards -- Niclas From owner-freebsd-current@freebsd.org Thu Sep 24 09:52:10 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 865553F2909 for ; Thu, 24 Sep 2020 09:52:10 +0000 (UTC) (envelope-from se@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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4Bxr1Q32qbz4DnW; Thu, 24 Sep 2020 09:52:10 +0000 (UTC) (envelope-from se@freebsd.org) Received: from Stefans-MBP-WLAN.fritz.box (p200300cd5f30c8003c8f9e409704137a.dip0.t-ipconnect.de [IPv6:2003:cd:5f30:c800:3c8f:9e40:9704:137a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 7E6A32F0B8; Thu, 24 Sep 2020 09:52:09 +0000 (UTC) (envelope-from se@freebsd.org) To: monochrome References: <59b99301-028c-132a-c974-30608ea18d24@twcny.rr.com> <70e5cb57-c78c-39cc-d7f8-20afbefe00fa@daemonic.se> From: Stefan Esser Cc: Niclas Zeising , freebsd-current@freebsd.org Subject: Re: geeqie, and neverball build problem on 13-current Message-ID: Date: Thu, 24 Sep 2020 11:52:07 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.2.2 MIME-Version: 1.0 In-Reply-To: <70e5cb57-c78c-39cc-d7f8-20afbefe00fa@daemonic.se> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="GF7v9y4tiHnha9XPA0ASm2SFoUjsHVEE5" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 24 Sep 2020 09:52:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GF7v9y4tiHnha9XPA0ASm2SFoUjsHVEE5 Content-Type: multipart/mixed; boundary="rgrTtLUvB1ZtzWhTRXpKhbFPBDypPbwU5"; protected-headers="v1" From: Stefan Esser To: monochrome Cc: Niclas Zeising , freebsd-current@freebsd.org Message-ID: Subject: Re: geeqie, and neverball build problem on 13-current References: <59b99301-028c-132a-c974-30608ea18d24@twcny.rr.com> <70e5cb57-c78c-39cc-d7f8-20afbefe00fa@daemonic.se> In-Reply-To: <70e5cb57-c78c-39cc-d7f8-20afbefe00fa@daemonic.se> --rgrTtLUvB1ZtzWhTRXpKhbFPBDypPbwU5 Content-Type: multipart/mixed; boundary="------------DD4EB1C8261EBFF334026249" Content-Language: en-US This is a multi-part message in MIME format. --------------DD4EB1C8261EBFF334026249 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Am 24.09.20 um 11:24 schrieb Niclas Zeising: > On 2020-09-24 11:17, monochrome wrote: >> Not sure how long this has been a problem, I noticed with the new=20 >> version of geeqie (geeqie-devel builds fine) and found the neverball=20 >> problem when rebuilding all packages to investigate. neverball output = >> changes with consecutive build attempts, geeqie does not. >=20 > This is related to the update of llvm to 11.=A0 With this update, build= s=20 > are by default using -fno-common, which means global variables cannot=20 > exist in multiple places.=A0 gcc 10 has the same default.=A0 A quick fi= x is=20 > to add -fcommon to CFLAGS, but the proper fix is to update the=20 > application source to only have the variable in one place. This was very easy to fix (like most of the ports affected by the -fno-common issue). The port is updated (r549911) and packages will appear in due time. Regards, STefan --------------DD4EB1C8261EBFF334026249-- --rgrTtLUvB1ZtzWhTRXpKhbFPBDypPbwU5-- --GF7v9y4tiHnha9XPA0ASm2SFoUjsHVEE5 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEo3HqZZwL7MgrcVMTR+u171r99UQFAl9sbEcFAwAAAAAACgkQR+u171r99UQw 1AgAy9/7VR2QcKSU3PQgmCd0XaROht1kok6vCUeTIyu9/0m5jmhCuFRtZMM1yIPYxSA2heugc7g/ WFYhigoyEbEC07P5Er2cZF3VSs4ENtxHmj5BK9gUEjMdMN+2EiZ/ZDUg+nmeO3eHowKgMzo0q+X9 n8dffLjyp4dWdVXOLR0lD184HBvmPd+QfAu1OrCjau4H5rMoSF3uX5OeS8wOGKSwxdDaF8/TSUKG iSPk5q6bq+PdIzHyPToS91g8l3EhGE3GQuojJIG7xcrrh9cTHzzDNg3wHwQVg/4kWyZljql+J5JK f9zvU9mEKUsnVPmUdukYgTQN+8sS3zjS7l5q9cTJ5A== =rPpY -----END PGP SIGNATURE----- --GF7v9y4tiHnha9XPA0ASm2SFoUjsHVEE5-- From owner-freebsd-current@freebsd.org Thu Sep 24 09:53: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 B87103F2AFB for ; Thu, 24 Sep 2020 09:53:34 +0000 (UTC) (envelope-from zeising+freebsd@daemonic.se) Received: from mail.daemonic.se (mail.daemonic.se [176.58.89.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Bxr314qzmz4FLp; Thu, 24 Sep 2020 09:53:33 +0000 (UTC) (envelope-from zeising+freebsd@daemonic.se) Received: from cid.daemonic.se (localhost [IPv6:::1]) by mail.daemonic.se (Postfix) with ESMTP id 4Bxr2t2J5Bz3nDG; Thu, 24 Sep 2020 09:53:26 +0000 (UTC) X-Virus-Scanned: amavisd-new at daemonic.se Received: from mail.daemonic.se ([127.0.0.1]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256) by cid.daemonic.se (mailscanner.daemonic.se [127.0.0.1]) (amavisd-new, port 10587) with ESMTPS id oBjMZCQ50pa7; Thu, 24 Sep 2020 09:53:25 +0000 (UTC) Received: from garnet.daemonic.se (host-95-194-26-120.mobileonline.telia.com [95.194.26.120]) by mail.daemonic.se (Postfix) with ESMTPSA id 4Bxr2s46ntz3mQw; Thu, 24 Sep 2020 09:53:25 +0000 (UTC) Subject: Re: geeqie, and neverball build problem on 13-current To: Stefan Esser , monochrome Cc: freebsd-current@freebsd.org References: <59b99301-028c-132a-c974-30608ea18d24@twcny.rr.com> <70e5cb57-c78c-39cc-d7f8-20afbefe00fa@daemonic.se> From: Niclas Zeising Message-ID: Date: Thu, 24 Sep 2020 11:53:25 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4Bxr314qzmz4FLp X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.13 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[daemonic.se:s=20151023]; FREEFALL_USER(0.00)[zeising]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.02)[-1.016]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[daemonic.se:+]; DMARC_POLICY_ALLOW(-0.50)[daemonic.se,none]; NEURAL_HAM_SHORT(-1.15)[-1.155]; NEURAL_HAM_MEDIUM(-0.96)[-0.958]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:36236, ipnet:176.58.89.0/24, country:US]; TAGGED_FROM(0.00)[freebsd]; MAILMAN_DEST(0.00)[freebsd-current]; RECEIVED_SPAMHAUS_PBL(0.00)[95.194.26.120:received] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 24 Sep 2020 09:53:34 -0000 On 2020-09-24 11:52, Stefan Esser wrote: > Am 24.09.20 um 11:24 schrieb Niclas Zeising: >> On 2020-09-24 11:17, monochrome wrote: >>> Not sure how long this has been a problem, I noticed with the new=20 >>> version of geeqie (geeqie-devel builds fine) and found the neverball=20 >>> problem when rebuilding all packages to investigate. neverball output= =20 >>> changes with consecutive build attempts, geeqie does not. >> >> This is related to the update of llvm to 11.=A0 With this update, buil= ds=20 >> are by default using -fno-common, which means global variables cannot=20 >> exist in multiple places.=A0 gcc 10 has the same default.=A0 A quick f= ix=20 >> is to add -fcommon to CFLAGS, but the proper fix is to update the=20 >> application source to only have the variable in one place. >=20 > This was very easy to fix (like most of the ports affected by the > -fno-common issue). >=20 > The port is updated (r549911) and packages will appear in due time. Great! Thanks for doing the work! Regards --=20 Niclas From owner-freebsd-current@freebsd.org Thu Sep 24 18:50:47 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 2346F424EA9 for ; Thu, 24 Sep 2020 18:50:47 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4By3ys1yDnz41Ws for ; Thu, 24 Sep 2020 18:50:44 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from outgoing.leidinger.net (p508d59c0.dip0.t-ipconnect.de [80.141.89.192]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (Client did not present a certificate) by mailgate.Leidinger.net (Postfix) with ESMTPSA id D3D211C4C; Thu, 24 Sep 2020 20:50:40 +0200 (CEST) Received: from webmail.leidinger.net (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (Client did not present a certificate) by outgoing.leidinger.net (Postfix) with ESMTPS id E53A57488; Thu, 24 Sep 2020 20:50:37 +0200 (CEST) Date: Thu, 24 Sep 2020 20:50:37 +0200 Message-ID: <20200924205037.Horde.gJim0TPjTDTRJqNVAw0co0z@webmail.leidinger.net> From: Alexander Leidinger To: Christian Weisgerber Cc: freebsd-current@freebsd.org Subject: Re: Plans for git References: <202009201400.08KE0PBd028190@gndrsh.dnsmgr.net> <13a965d9-ef02-f876-dd6c-aa872b66d114@nomadlogic.org> <20200921092159.Horde.yLakOjqLl4pZWCjCuYTfZVh@webmail.leidinger.net> <37d9eb3b-642d-f324-3da3-03d198f5b5f1@nomadlogic.org> In-Reply-To: Accept-Language: de,en Content-Type: multipart/signed; boundary="=_LC3K3Ls1FXCYnlnfJFbxX4d"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-Rspamd-Queue-Id: 4By3ys1yDnz41Ws X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.23 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; NEURAL_HAM_MEDIUM(-1.02)[-1.022]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.004]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[leidinger.net:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; NEURAL_HAM_SHORT(-0.10)[-0.103]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:34240, ipnet:2a00:1828::/32, country:DE]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current]; RECEIVED_SPAMHAUS_PBL(0.00)[80.141.89.192:received] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 24 Sep 2020 18:50:47 -0000 This message is in MIME format and has been PGP signed. --=_LC3K3Ls1FXCYnlnfJFbxX4d Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoting Christian Weisgerber (from Mon, 21 Sep=20=20 2020=2021:55:00 -0000 (UTC)): > Well, I was asking for a summary. > > For instance, I don't know if the Git migration is merely a switch > of the version control system or what other changes will be layered > on top of it as a matter of course, e.g. will the development > infrastructure move to GitHub? Don't answer that, just point me > to the information. I don't remember from where I got it... I haven't found it. Maybe in=20=20 an=20FreeBSD office hours session. At least it was mentioned (again)=20=20 yesterday=20in the FreeBSD Office hours. Bye, Alexander. P.S.: phase 1 =3D switch of the internal repo to git, mirrored to github=20= =20 and=20gitlab, and ... maybe others. Phase 2 =3D improve processes (may or= =20=20 may=20not include use of external resources like github/gitlab/...). --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_LC3K3Ls1FXCYnlnfJFbxX4d Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJfbOp8AAoJEBINsJsD+NiGWjoP/A1JxliNwE9qnemy4jWnMz8i ydOO3DLixwrOnpHx2ev2iyzRhkfKjQ/RwFf+f0aRZG5W3zCXqr5si3TN2KHmbgPX toc/a6WllMzK3+ZR8ZN/XzHH8KelqzhTdYeC03gisEvWzTwRP0dCVOcEi258FyAf tQGV2ygoV9D6Jduw+wPedVz2P+HGbjJ7IeRIxTmj+ezQSK4lqRscRRyqVKbu0mEa GE3lhiV1aaqbE2ebl1znjxSbA2VcPcZI8UVLRKpycgep3W3pnXOOrJ1+avObRNus zaRTs6kyjgh1K+oLZUJYB5nfDL3PQbbb/EgF9eulkBiKSOcpv54il3Pqjp6GGp1I 5ycwieRd1OCn0Www5sWDZKI9x5fbUqJo6ThJUbnR9OGbpVf9IgGj7JFbAxCIPOuE lM22RDSbwLstB5xxNv9gabOu4iUC30pIK2M2sDoKYSjeIi9ank2qYxAcG0S50S9v ilh2TXmp5dBdJ4zEjqfXSnWZ3C/pufIZhKhHazItkFyMsxccduM9EDNjhLSHwNz0 gbMn4lsYEpsqR80tADvP8BgaUgLjWGe6W5npcAzz02W8CQ+WktQods8TdLUpXycN /oCqWy4ieSwWDq42vaLUbh2N7Jvpzq+yiiwL+HSRBJpXAm7yvQIVCtckmPXsfyCD fwSrTXz9bq1QQ60kpL/R =1URR -----END PGP SIGNATURE----- --=_LC3K3Ls1FXCYnlnfJFbxX4d-- From owner-freebsd-current@freebsd.org Fri Sep 25 17:44: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 ED3ED3FDEFF for ; Fri, 25 Sep 2020 17:44:54 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4ByfSQ0LJGz4JXR; Fri, 25 Sep 2020 17:44:53 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: by mail-lf1-x12e.google.com with SMTP id u8so3754155lff.1; Fri, 25 Sep 2020 10:44:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=iiCYThJSPc/YiJHU3gfey8NR0Na6H0w8zDFnlMhQhRM=; b=qTBkQfCAHUUl4AlCGiN5t2oefwICrfnq4nvL0P1CEeGelghWPRU8FENzF0wXS7veHZ nOcUaZUP93VGB8bKucRN3tSguCJ6tK71r/jCTS7geM07SHUV1CyoZDlDOxYbAVU6fo0N wcySykUWTCUcChLqbP6LXWsgqjKkXBNqXi0KvuzMJPkLhD74s1yRqberce8m4HLHSLSo 5b+PtH8Ds7WecLUX3gJfxB92PWxUIsGfWEWhx+cfApH+zZlmc8qE0EaNCvg/aZMl838x GoaU9ADqBC01Fb8hWyUlxerZfNaO86McIMCBzxExR7u+dyHksu3O3VGfOIzhe0KNhr3V YiNw== X-Gm-Message-State: AOAM5335KF6brhOkTXFaE9mFGySqFd0rIFlU4WAXRBxDP7V3i8O+NVOd 2aP0aj4obkBTz0dnuqaq7bwk1qnqlGjmhv3W X-Google-Smtp-Source: ABdhPJyapVx0IHDI3BUpG/39pMt6tG1xckDt4loWYY+ldmqAz9fCzzf6/q6UFWnlw4vg4ABBf7iUrg== X-Received: by 2002:a19:2346:: with SMTP id j67mr1634965lfj.449.1601055891847; Fri, 25 Sep 2020 10:44:51 -0700 (PDT) Received: from laptop.domain (mm-115-11-215-37.mfilial.dynamic.pppoe.byfly.by. [37.215.11.115]) by smtp.gmail.com with ESMTPSA id f27sm2780079lfh.45.2020.09.25.10.44.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 25 Sep 2020 10:44:51 -0700 (PDT) Date: Fri, 25 Sep 2020 20:47:45 +0300 From: "Sergey V. Dyatko" To: "Kristof Provost" Cc: "FreeBSD Current" Subject: Re: iflib/bridge kernel panic Message-ID: <20200925204745.6a08e357@laptop.domain> In-Reply-To: <58CADEBB-64FD-414E-AB19-E4F8D3CABCA5@FreeBSD.org> References: <58CADEBB-64FD-414E-AB19-E4F8D3CABCA5@FreeBSD.org> X-Mailer: Claws Mail 3.17.5 (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: 4ByfSQ0LJGz4JXR X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.34 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.32)[-0.318]; RECEIVED_SPAMHAUS_PBL(0.00)[37.215.11.115:received]; 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]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.02)[-1.021]; 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)[-0.998]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::12e:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 25 Sep 2020 17:44:55 -0000 On Mon, 21 Sep 2020 09:57:40 +0200 "Kristof Provost" wrote: > On 21 Sep 2020, at 2:52, Shawn Webb wrote: > >> From latest HEAD on a Dell Precision 7550 laptop: > > > > https://gist.github.com/lattera/a0803f31f58bcf8ead51ac1ebbc447e2 > > > > The last working boot environment was 14 Aug 2020. If I get some time to > > bisect commits, I'll try to figure out the culprit. > > > Try https://reviews.freebsd.org/D26418 > > Best regards, > Kristof I'm not sure, but doesn't this panic have the same root as mine? Sorry, but I haven't text console and can post only screenshot[s] from IP-KVM https://gyazo.com/fee41c5267e9fc543d43901e498b7c94 rc.conf have something like: clonned_interfaces="lagg0 vlan101" ifconfig_lagg0="laggproto lacp laggport em0 laggport em1 x.x.x.x/mask" ifconfig_vlan101="vlan 101 vlandev lagg0 192.168.1.29/24" without VLAN part all works fine. Installed from FreeBSD-13.0-CURRENT-amd64-20200924-3c514403bef-disc1.iso -- wbr, Sergey From owner-freebsd-current@freebsd.org Fri Sep 25 18:02: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 AE3FE3FF18E for ; Fri, 25 Sep 2020 18:02:27 +0000 (UTC) (envelope-from xtouqh@hotmail.com) Received: from EUR06-AM7-obe.outbound.protection.outlook.com (mail-am7eur06olkn2086.outbound.protection.outlook.com [40.92.16.86]) (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 4Byfrf4NWWz4Ktg; Fri, 25 Sep 2020 18:02:26 +0000 (UTC) (envelope-from xtouqh@hotmail.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=X4jZgy1x7ioKiIloBZr79EpM2cKQzdvpTszbSxhsnwP0jMWN5AFEpCDcX37YnU6E0Q6WAXBCTxqxcTNHaIbxku9pX1plL/tNkdDXDAUySGAvsU6uZu+zo5kwFJ7Z72V/Nxp6ECeAQJwqO4YpMJj0Q747xg+2P3ld/GzIhEY9i/xYFrBrfj+J3Jif9vwtqfERLAIoPN2KS6h3B5zcJt4WBvSfUs/D5GOwlYJeQN90Z9gyYc9c3YV5nlOvIcFfoWn9VT1Sg2szzyHfkhpZq15Uf+qWMQF8JTYPRBD6YDc5swfRdRjutvsqYHusc4D1UWInrBe2AbZVQc5OWKgwflQyjQ== 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=g0o/Uk7V5e8j9A3CKSdfsSo41QDC1219eLkrK+MrK00=; b=ACbj/03vGSMaVNu4sKs5HAXh/yzuYnEbS4qTz9AtauTHe64cAB8DBhpFc09lQgP8wb+wVD0+lpEFqG9wwMutykN4RimEH9OfrVvXjvq8eVTsz+uzQZbQe1a7/iDY+nlUaE6Db3WRHU8sGLQcwk1bWiO1T/IPUOkNuod3HQbpWn/6PgvXiRiZyz1bxa6IGB8bjDUdnHuYTB6/kpoKtzrn3RGzzy+kTRVwRrLiGLn0RiyLW6mazYs1k/Eae/jixBtkbMVrfgIXPAaxNSzJHhQTiMcuy/ahntCcbUNp2gi+iTVc0ZePC+wnH9LrN50HwfRo+CUYyZJVj1edbUspuZy28Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Received: from AM7EUR06FT046.eop-eur06.prod.protection.outlook.com (2a01:111:e400:fc36::42) by AM7EUR06HT141.eop-eur06.prod.protection.outlook.com (2a01:111:e400:fc36::120) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.21; Fri, 25 Sep 2020 17:46:58 +0000 Received: from AM0PR06MB3986.eurprd06.prod.outlook.com (2a01:111:e400:fc36::45) by AM7EUR06FT046.mail.protection.outlook.com (2a01:111:e400:fc36::352) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.21 via Frontend Transport; Fri, 25 Sep 2020 17:46:58 +0000 X-IncomingTopHeaderMarker: OriginalChecksum:1CAEE2FB1FE2E1DE1A2A1FC1A18A80DADBB1F1A07758AA0E9A63BDA1C327A731; UpperCasedChecksum:8478466376C3BCE7602F6FAE00723D30C9D5CE3E10B01B2998FE198A5C280802; SizeAsReceived:8882; Count:49 Received: from AM0PR06MB3986.eurprd06.prod.outlook.com ([fe80::9dd1:2866:7eae:1ccf]) by AM0PR06MB3986.eurprd06.prod.outlook.com ([fe80::9dd1:2866:7eae:1ccf%7]) with mapi id 15.20.3391.027; Fri, 25 Sep 2020 17:46:58 +0000 Subject: Re: iflib/bridge kernel panic To: "Sergey V. Dyatko" , Kristof Provost Cc: FreeBSD Current References: <58CADEBB-64FD-414E-AB19-E4F8D3CABCA5@FreeBSD.org> <20200925204745.6a08e357@laptop.domain> From: xt Message-ID: Date: Fri, 25 Sep 2020 20:46:57 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.3.0 In-Reply-To: <20200925204745.6a08e357@laptop.domain> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-ClientProxiedBy: AM0PR10CA0060.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:150::40) To AM0PR06MB3986.eurprd06.prod.outlook.com (2603:10a6:208:b6::28) X-Microsoft-Original-Message-ID: MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.6] (91.240.124.157) by AM0PR10CA0060.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:150::40) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.22 via Frontend Transport; Fri, 25 Sep 2020 17:46:57 +0000 X-Microsoft-Original-Message-ID: X-TMN: [wF2+GjfKNLIXcOMXqb7903y4PbiSGySD] X-MS-PublicTrafficType: Email X-IncomingHeaderCount: 49 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-Correlation-Id: 29a497a2-9ccd-4dd3-d0a7-08d8617afffb X-MS-TrafficTypeDiagnostic: AM7EUR06HT141: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Wp5oZd5lRXUguvLu7u+WjUEfopa4Dhy/iP8dsO9Ddo2TKlg88ttEMn8EYyYmSPPnWfjNTHJlmUm29w5h+0xv9fEioEV2C3q5rhzgnwKNc1TxBAD/kM7Vi2TjmLuBJ2yz+F4lDqvaf/58Dpyn+oKvQISAptjOy4uiOfiFccT3LBnFQR0m1YloKGDXz0MHtoIgo5JVHWQMBkD5Jn5LlugPWAlmWvFOkNxnTCztR/LS1Ch9PxJb2aLq88nBWsOy63z9 X-MS-Exchange-AntiSpam-MessageData: HwnDXlEAjcAjnIVBdbdSYFhOzb0wImdiAv2Yulxc75gRYGKlvXlxzFLK2zRb4JrY6pP1oiGhpzHhiA4zVt3aw8qW2vABg5IkHJUWx9ynLY0JHHG28SlrN9T20xBDY8sf/mveKH1AYXPByHA44tXejw== X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-Network-Message-Id: 29a497a2-9ccd-4dd3-d0a7-08d8617afffb X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Sep 2020 17:46:58.5930 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-AuthSource: AM7EUR06FT046.eop-eur06.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7EUR06HT141 X-Rspamd-Queue-Id: 4Byfrf4NWWz4Ktg X-Spamd-Bar: +++++++ X-Spamd-Result: default: False [7.47 / 15.00]; FREEMAIL_FROM(0.00)[hotmail.com]; R_SPF_ALLOW(0.00)[+ip4:40.92.0.0/15]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[hotmail.com:+]; DMARC_POLICY_ALLOW(0.00)[hotmail.com,none]; NEURAL_HAM_SHORT(-0.28)[-0.275]; FREEMAIL_TO(0.00)[gmail.com,FreeBSD.org]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[hotmail.com]; ASN(0.00)[asn:8075, ipnet:40.80.0.0/12, country:US]; FORGED_MUA_THUNDERBIRD_MSGID_UNKNOWN(2.50)[]; ARC_ALLOW(0.00)[microsoft.com:s=arcselector9901:i=1]; DWL_DNSWL_NONE(0.00)[hotmail.com:dkim]; RECEIVED_SPAMHAUS_XBL(5.00)[91.240.124.157:received]; R_DKIM_ALLOW(0.00)[hotmail.com:s=selector1]; RCVD_COUNT_FIVE(0.00)[5]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_MEDIUM(-0.09)[-0.093]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; BAD_REP_POLICIES(0.10)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.34)[0.336]; RCVD_IN_DNSWL_NONE(0.00)[40.92.16.86:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.92.16.86:from]; GREYLIST(0.00)[pass,body]; MAILMAN_DEST(0.00)[freebsd-current] X-Spam: Yes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 25 Sep 2020 18:02:27 -0000 Sergey V. Dyatko wrote: > On Mon, 21 Sep 2020 09:57:40 +0200 > "Kristof Provost" wrote: > >> On 21 Sep 2020, at 2:52, Shawn Webb wrote: >>>> From latest HEAD on a Dell Precision 7550 laptop: >>> >>> https://gist.github.com/lattera/a0803f31f58bcf8ead51ac1ebbc447e2 >>> >>> The last working boot environment was 14 Aug 2020. If I get some time to >>> bisect commits, I'll try to figure out the culprit. >>> >> Try https://reviews.freebsd.org/D26418 >> >> Best regards, >> Kristof > > I'm not sure, but doesn't this panic have the same root as mine? > Sorry, but I haven't text console and can post only screenshot[s] > from IP-KVM > https://gyazo.com/fee41c5267e9fc543d43901e498b7c94 > > rc.conf have something like: > clonned_interfaces="lagg0 vlan101" > ifconfig_lagg0="laggproto lacp laggport em0 laggport em1 x.x.x.x/mask" > ifconfig_vlan101="vlan 101 vlandev lagg0 192.168.1.29/24" > > without VLAN part all works fine. > Installed from FreeBSD-13.0-CURRENT-amd64-20200924-3c514403bef-disc1.iso Yes, same panic. From owner-freebsd-current@freebsd.org Fri Sep 25 18:03: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 707F63FF316 for ; Fri, 25 Sep 2020 18:03:51 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4ByftG35CHz4LB5 for ; Fri, 25 Sep 2020 18:03:50 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: by mail-lf1-x12a.google.com with SMTP id z19so3785975lfr.4 for ; Fri, 25 Sep 2020 11:03:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-transfer-encoding; bh=RtHOZtusLl7PH0DFtiv3KHCEQPYm7iDYYrV+jcrUmok=; b=XayG9Mace35e7fm+uNJzlSR2ryx06weMzm+EXChlJDkFAJ1aCL2vNzwUrKlsWfDFin b9T4t+gJwKfsSIe6hIWr1dBF5YTuB8i1M3fa14N0s8SQuU2IslOiQ3Xiqh7OFRKusO4B nkSO6K7IvIPhhOb9QBR9bunPLt4h1ObWTT9fWwdetgc0hj0h+7Drm+8xmW1LuTPtgen4 LGyuStxJ2vXbZQI1iLxFQlYr6CgQ6Gjbjg2TIk8K2yxnVs0r9yWcSatNgavjArYF//1z lS8zZsW3vYxMdVnSU0rjlFRDSn38Wv69Kke6/G/qeZr+akp1DUSRm0M1VKMjOdHXRKVk WfPQ== X-Gm-Message-State: AOAM531Cf9oPve5cHCgUtXGDoFJoDX82ciTUgCv05NeqfOaZzd86+wsD tIIe8MDzOiVudPqXXyzyLg1NpsTrYYwqsdb2 X-Google-Smtp-Source: ABdhPJxwu0S1qctMCqdyqHJ1p6TgdjEkxfpZ2+Eh1gq94SXD+bhNncNKFm3TLaWOKvI502IeRU7rWQ== X-Received: by 2002:a19:4952:: with SMTP id l18mr10674lfj.321.1601057027097; Fri, 25 Sep 2020 11:03:47 -0700 (PDT) Received: from laptop.domain (mm-115-11-215-37.mfilial.dynamic.pppoe.byfly.by. [37.215.11.115]) by smtp.gmail.com with ESMTPSA id o15sm2837521lfg.226.2020.09.25.11.03.46 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 25 Sep 2020 11:03:46 -0700 (PDT) Date: Fri, 25 Sep 2020 21:06:41 +0300 From: "Sergey V. Dyatko" To: Subject: How to find out the revision for HEAD after build-snapshots-from-git? Message-ID: <20200925210641.6f6289f1@laptop.domain> X-Mailer: Claws Mail 3.17.5 (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: 4ByftG35CHz4LB5 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.09 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.15)[-0.152]; RECEIVED_SPAMHAUS_PBL(0.00)[37.215.11.115:received]; SUBJECT_ENDS_QUESTION(1.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.96)[-0.961]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.97)[-0.973]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::12a:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 25 Sep 2020 18:03:51 -0000 Hi, Possible I missed the answer to my question, sorry. But Today I installed FreeBSD from FreeBSD-13.0-CURRENT-amd64-20200924-3c514403bef-disc1 and now I want to rebuild kernel and so on BUT I don't know which SVN revision should I checkout. uname -a output: FreeBSD my.host.name 13.0-CURRENT FreeBSD 13.0-CURRENT #0 3c514403bef-c253353(main): Thu Sep 24 06:45:17 UTC 2020 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 r253353 looks too old, I suppose... -- wbr, Sergey From owner-freebsd-current@freebsd.org Fri Sep 25 18:28:29 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 DC8CA3FFD53 for ; Fri, 25 Sep 2020 18:28:29 +0000 (UTC) (envelope-from xtouqh@hotmail.com) Received: from EUR06-VI1-obe.outbound.protection.outlook.com (mail-vi1eur06olkn2021.outbound.protection.outlook.com [40.92.17.21]) (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 4BygQg4y0Hz4Mrm for ; Fri, 25 Sep 2020 18:28:27 +0000 (UTC) (envelope-from xtouqh@hotmail.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dJvD8SlTUp9lkOHBKrNBVR39t+MD08ZH/vH6m0RmWSpq8zvg/KvG/C92UJBVz9n5cIbtzt+P8XKuxoTv4+rTYqCy1gsGzgaREB1hNt2X0MUxfMCF54u4q2P95TzGm2G9QwKu0b1zNTBaXZFpHCfiTs35RKMRIrQbrH5YMzkOgnQTNLv8BAXHBGO3OlLls38tlxVpDFE+4bqyl5vXeatbU1Ulz+EKbilF6thGphphdO/LHBwkgxLQVI3LGULMSrcaHaNMuwDI89Q1LG2cR2fmJW8Xz1Lrz48v/eE1niUw1V2vmbAHb3iAhzE2/4G+MOPl8pMEJm2iN9l3jdoYSlVh8A== 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=PsthXEx75znaJvnNIjQyZ3BoeJR/w3M2q8TllJdwgfg=; b=gROUeAbiJQPz1Dn2YGWB+18vnrQecG4Ac+iayBIe/GAWV1sbZMwRx9KC86MkU9d0WMFCEXkHJOT/47QuOpaXHW6//QeZ69SFCFI1pgmcMcPJoieN9Q6+VRgIylkTF0wcSd99i2JY/krsYGq6L8yZXWNd7oNY+nXnkh975y2UqczwdjJfDcHnI6RzroLI4m54fr4ZxxEFttYJjHrdt6gAguOISKie5qu3Wj8DPbNB0XiRFNXFkau2MGyM4rXr0dn7NGNSEefrYZNBcHgWzYWvu3qNYcqBSwZ8OFszxdn/vccgxShfdjbQpAQVSp39A72tey8EP4Xs2qK3LiORVxLUgQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Received: from AM7EUR06FT056.eop-eur06.prod.protection.outlook.com (2a01:111:e400:fc36::40) by AM7EUR06HT169.eop-eur06.prod.protection.outlook.com (2a01:111:e400:fc36::176) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.21; Fri, 25 Sep 2020 18:13:29 +0000 Received: from AM0PR06MB3986.eurprd06.prod.outlook.com (2a01:111:e400:fc36::51) by AM7EUR06FT056.mail.protection.outlook.com (2a01:111:e400:fc36::435) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.21 via Frontend Transport; Fri, 25 Sep 2020 18:13:29 +0000 X-IncomingTopHeaderMarker: OriginalChecksum:FB844FDD041FF5860C608872D458BA98644650ADFEF296D59DACF666E5C6E255; UpperCasedChecksum:ACC6C57E59867CD3B146C03DC7095D3462162B8AEAF00A9E98B3D24BEA7EE174; SizeAsReceived:8733; Count:48 Received: from AM0PR06MB3986.eurprd06.prod.outlook.com ([fe80::9dd1:2866:7eae:1ccf]) by AM0PR06MB3986.eurprd06.prod.outlook.com ([fe80::9dd1:2866:7eae:1ccf%7]) with mapi id 15.20.3391.027; Fri, 25 Sep 2020 18:13:29 +0000 Subject: Re: How to find out the revision for HEAD after build-snapshots-from-git? To: "Sergey V. Dyatko" , freebsd-current@freebsd.org References: <20200925210641.6f6289f1@laptop.domain> From: xtouqh@hotmail.com Message-ID: Date: Fri, 25 Sep 2020 21:13:28 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.3.0 In-Reply-To: <20200925210641.6f6289f1@laptop.domain> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-ClientProxiedBy: AM0PR10CA0052.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:150::32) To AM0PR06MB3986.eurprd06.prod.outlook.com (2603:10a6:208:b6::28) X-Microsoft-Original-Message-ID: <3ddbe77e-a5e4-fedb-9b10-86772fabd814@hotmail.com> MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.6] (91.240.124.157) by AM0PR10CA0052.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:150::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.23 via Frontend Transport; Fri, 25 Sep 2020 18:13:28 +0000 X-Microsoft-Original-Message-ID: <3ddbe77e-a5e4-fedb-9b10-86772fabd814@hotmail.com> X-TMN: [JWYfkrI7ZX0h/LiGZRPUKZuUW5p4yDJm] X-MS-PublicTrafficType: Email X-IncomingHeaderCount: 48 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-Correlation-Id: fbe81b64-5841-4ad9-1c8e-08d8617eb437 X-MS-TrafficTypeDiagnostic: AM7EUR06HT169: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 3D20mm3CGtL0TDE+af8acSR/PbzUTZRMD1icYKhvIVX/XGiKaNE3ZtThDr/3MXxUhAbhp01zJKQyyxwUaikph285X16LPs/l3j3AswPAey8zyx21at61/4RxjVB33MpMl9Xa9y1DniOgoWemuG+ifXInnPeF79fth/eBS7MG5DZAKZ4a4pd+DxzY1JSf1QXSDCfLa/KfZxXIR+GEg+NhyvjCHYU8C0z5KkfQNYZkKgG6FoOhTQ24ABnglSrArL+P X-MS-Exchange-AntiSpam-MessageData: GUvHfJ5Y4IHoc9pz/VLOcnX+G1jdOsYn5k6KW7n21MFazl9pAqDZLz9EdZN6YttiZjEjcOityiquxgV6F4v7t+c8tlWX8NwvgLu0/74A85sXmhAyhLcjXZ6z9jNrKJm7yJTVOgR3LccQdM1e8o4LGw== X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-Network-Message-Id: fbe81b64-5841-4ad9-1c8e-08d8617eb437 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Sep 2020 18:13:29.2338 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-AuthSource: AM7EUR06FT056.eop-eur06.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7EUR06HT169 X-Rspamd-Queue-Id: 4BygQg4y0Hz4Mrm X-Spamd-Bar: +++++++++ X-Spamd-Result: default: False [9.18 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[hotmail.com]; R_SPF_ALLOW(0.00)[+ip4:40.92.0.0/15]; DKIM_TRACE(0.00)[hotmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(0.00)[hotmail.com,none]; NEURAL_HAM_SHORT(-0.15)[-0.150]; FREEMAIL_TO(0.00)[gmail.com,freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[hotmail.com]; FORGED_MUA_THUNDERBIRD_MSGID_UNKNOWN(2.50)[]; ASN(0.00)[asn:8075, ipnet:40.80.0.0/12, country:US]; DWL_DNSWL_NONE(0.00)[hotmail.com:dkim]; RECEIVED_SPAMHAUS_XBL(5.00)[91.240.124.157:received]; R_DKIM_ALLOW(0.00)[hotmail.com:s=selector1]; RCVD_COUNT_FIVE(0.00)[5]; RCVD_TLS_LAST(0.00)[]; ARC_ALLOW(0.00)[microsoft.com:s=arcselector9901:i=1]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_MEDIUM(0.20)[0.205]; BAD_REP_POLICIES(0.10)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.63)[0.627]; FROM_NO_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[40.92.17.21:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.92.17.21:from]; GREYLIST(0.00)[pass,body]; MAILMAN_DEST(0.00)[freebsd-current] X-Spam: Yes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 25 Sep 2020 18:28:29 -0000 Sergey V. Dyatko wrote: > Hi, > > Possible I missed the answer to my question, sorry. But > Today I installed FreeBSD from > FreeBSD-13.0-CURRENT-amd64-20200924-3c514403bef-disc1 > and now I want to rebuild kernel and so on BUT I don't know which SVN revision > should I checkout. > uname -a output: > > FreeBSD my.host.name 13.0-CURRENT FreeBSD 13.0-CURRENT #0 > 3c514403bef-c253353(main): Thu Sep 24 06:45:17 UTC 2020 > root@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 > > r253353 looks too old, I suppose... There certainly should be easier way, but as a quick "fix", try searching for commit hash: https://cgit-beta.freebsd.org/src/log/?qt=range&q=3c514403bef From owner-freebsd-current@freebsd.org Fri Sep 25 18:33: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 A13463E022E for ; Fri, 25 Sep 2020 18:33:51 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4BygXt45WNz4NXX for ; Fri, 25 Sep 2020 18:33:50 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: by mail-lj1-x22c.google.com with SMTP id u21so3261268ljl.6 for ; Fri, 25 Sep 2020 11:33:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=pgB1EkhoV+g2YVke/F0MymmzuZXhuUNGYQCSkFw/dWY=; b=Tgh7yLlXk3mjIOuPHPUt9KZaQZ3jTAIfovtquGg4cJwSDgMmgRASlgfSCk+8WpsUZh 0v1OjZiNSniCwY7MxWsBKsBZUbJUybolxdICNvb859exvaIPVwc5WB1PvCvSQzsf9wG+ +3OQdnkl6S6cphbJXjauZFTZQLSZzIsUCtgPbSdZi4hAkUjyi/F+mf0YYsAuuFxkiBJG gR3a53tmHxcZKSv4RhuSbgjo+yTMbvwtatpeiq5ds0Od4iqcj+82NYPWj0nTmqikveQt zdfxgL8qj5RbjrpHpLFmkLJZv66Kwj0tX5TE6esdBEg79I0G2UjdfFl7q2S9GtrXTDUp uTKQ== X-Gm-Message-State: AOAM532VzMlZn6mOyRFr3643KvPD+BmpOmdYNaMPNigAUMtS7KICMwhz a/SBQk5l5ghqw+YXgFVzNenTEfPBq5Osy8YX X-Google-Smtp-Source: ABdhPJxzzejvcVUDVc9jJYVgToYk+pe+3CuPPV27DUpVJl8ma/bmwRcxV4FvoFtEDYtM/6PCCSbWVA== X-Received: by 2002:a2e:9b13:: with SMTP id u19mr1701093lji.204.1601058828586; Fri, 25 Sep 2020 11:33:48 -0700 (PDT) Received: from laptop.domain (mm-115-11-215-37.mfilial.dynamic.pppoe.byfly.by. [37.215.11.115]) by smtp.gmail.com with ESMTPSA id x5sm2867948lfd.119.2020.09.25.11.33.47 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 25 Sep 2020 11:33:48 -0700 (PDT) Date: Fri, 25 Sep 2020 21:36:42 +0300 From: "Sergey V. Dyatko" To: freebsd-current@freebsd.org Subject: Re: How to find out the revision for HEAD after build-snapshots-from-git? Message-ID: <20200925213642.2df76e18@laptop.domain> In-Reply-To: References: <20200925210641.6f6289f1@laptop.domain> X-Mailer: Claws Mail 3.17.5 (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: 4BygXt45WNz4NXX X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.08 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.14)[-0.138]; RECEIVED_SPAMHAUS_PBL(0.00)[37.215.11.115:received]; SUBJECT_ENDS_QUESTION(1.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.96)[-0.963]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.98)[-0.978]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::22c:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 25 Sep 2020 18:33:51 -0000 On Fri, 25 Sep 2020 21:13:28 +0300 xtouqh@hotmail.com wrote: > Sergey V. Dyatko wrote: > > Hi, > > > > Possible I missed the answer to my question, sorry. But > > Today I installed FreeBSD from > > FreeBSD-13.0-CURRENT-amd64-20200924-3c514403bef-disc1 > > and now I want to rebuild kernel and so on BUT I don't know which SVN > > revision should I checkout. > > uname -a output: > > > > FreeBSD my.host.name 13.0-CURRENT FreeBSD 13.0-CURRENT #0 > > 3c514403bef-c253353(main): Thu Sep 24 06:45:17 UTC 2020 > > root@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 > > > > r253353 looks too old, I suppose... > > There certainly should be easier way, but as a quick "fix", try > searching for commit hash: > > https://cgit-beta.freebsd.org/src/log/?qt=range&q=3c514403bef Looks amazing! but i'm not an Alien, I'm just a human... It is r366075, right ? Thanks! -- wbr, Sergey From owner-freebsd-current@freebsd.org Fri Sep 25 19:11: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 02B503E1418; Fri, 25 Sep 2020 19:11:53 +0000 (UTC) (envelope-from andy@neu.net) Received: from mail.neu.net (neu.net [104.225.8.138]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "freebsd-11-64", Issuer "freebsd-11-64" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ByhNm31Ysz4QtB; Fri, 25 Sep 2020 19:11:52 +0000 (UTC) (envelope-from andy@neu.net) Received: from neu.net (neu.net [104.225.8.138]) by mail.neu.net (8.15.2/8.15.2) with ESMTPS id 08PJBotp075773 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 25 Sep 2020 15:11:50 -0400 (EDT) (envelope-from andy@neu.net) Date: Fri, 25 Sep 2020 15:11:50 -0400 (EDT) From: AN To: freebsd-current@freebsd.org, freebsd-gnome@freebsd.org Subject: BROKEN DESKTOP Message-ID: User-Agent: Alpine 2.21.9999 (BSF 287 2018-06-16) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=1.6 required=2.9 tests=SUBJ_ALL_CAPS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on mail.neu.net X-Rspamd-Queue-Id: 4ByhNm31Ysz4QtB X-Spamd-Bar: ++ X-Spamd-Result: default: False [2.68 / 15.00]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[andy]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.39)[0.394]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[neu.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.16)[0.157]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.07)[0.075]; SUBJ_ALL_CAPS(1.05)[14]; RCVD_COUNT_ONE(0.00)[1]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:36236, ipnet:104.225.8.0/24, country:US]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-gnome,freebsd-current]; ONCE_RECEIVED(0.10)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 25 Sep 2020 19:11:53 -0000 FreeBSD Free_BSD_13 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r366158: Fri Sep 25 12:23:15 EDT 2020 root@Free_BSD_13:/usr/obj/usr/src/amd64.amd64/sys/MYKERNEL.bak amd64 1300117 After a recent upgrade of base system, kernel and all ports my desktop is broken. >From log: Sep 25 14:25:17 Free_BSD_13 mate-session[78320]: WARNING: Could not connect to ConsoleKit: Could not get owner of name 'org.freedesktop.ConsoleKit': no such name Sep 25 14:25:17 Free_BSD_13 syslogd: last message repeated 1 times Sep 25 14:25:17 Free_BSD_13 mate-session[78320]: WARNING: Unable to find provider '' of required component 'dock' Sep 25 14:25:18 Free_BSD_13 gnome-keyring-daemon[85947]: The PKCS#11 component was already initialized Sep 25 14:25:18 Free_BSD_13 gnome-keyring-daemon[85947]: The Secret Service was already initialized Sep 25 14:25:18 Free_BSD_13 gnome-keyring-daemon[85947]: The SSH agent was already initialized Sep 25 14:25:18 Free_BSD_13 console-kit-daemon[4901]: CRITICAL: polkit_authority_check_authorization: assertion 'POLKIT_IS_AUTHORITY (authority)' failed Now nothing is working, does anyone have an idea how to fix this? From owner-freebsd-current@freebsd.org Fri Sep 25 23:25: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 829493E8252 for ; Fri, 25 Sep 2020 23:25:54 +0000 (UTC) (envelope-from doctorwhoguy@gmail.com) Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4Byp1s5YcGz3Ts0; Fri, 25 Sep 2020 23:25:53 +0000 (UTC) (envelope-from doctorwhoguy@gmail.com) Received: by mail-ej1-x629.google.com with SMTP id o8so796794ejb.10; Fri, 25 Sep 2020 16:25:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=T9dp5J8gU9jhB4dP+mb9/jNU/SfmVPyQ1DgAaYM7kko=; b=d2sJnASkRWvgxLl2Iij6XMnjLulcL2+xkiS3LNUwVXjIA4F44i4HBHdu8KH+gQRyqP 3enShAtSr5ayUV1vm3u1UQmSzvwnvgRdYUvaWlE+1SoCM1+PJ16wH9YNMvjhOH/9pgPh AcEke0fQaExYX/sYaoL3VetIvbnduA5vioEviNTpS08vYt3lmBoJEUMjM2kjuUydYF8y SwW4BAZPYEE1xwHdIhs6ATHIMumMk8a5JYVwQz6nhLNHO1Uip9bfyeRNRxicYi+CUG6D 0FyK2To0/HnNuwK19cT6CVx3Tb052UPEi3uA71zFDZPsJZkN65paKmoKJsZeJIR+DKYI tWZw== X-Gm-Message-State: AOAM532+jhNgNbp3ijUDl47dgTbhAiwGgOREv9ERHsuilSi3iDzVcACm pH3ytCK8B1F5W150bd9gAV6lA6WPO2afbLfH+DosObNWIFE= X-Google-Smtp-Source: ABdhPJy2bbr77aC8zSKOMRy72xZVWHdod4aQFCFDroxxG89ednuHAb4DXK8Dov8w/3nORR9gJVXlop7aMtfa/vRdrG8= X-Received: by 2002:a17:906:6ce:: with SMTP id v14mr4979197ejb.451.1601076351500; Fri, 25 Sep 2020 16:25:51 -0700 (PDT) MIME-Version: 1.0 From: Patrick McMunn Date: Fri, 25 Sep 2020 18:25:39 -0500 Message-ID: Subject: error pulling from the Beta git repo To: emaste@freebsd.org Cc: freebsd-current@freebsd.org X-Rspamd-Queue-Id: 4Byp1s5YcGz3Ts0 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.45 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; NEURAL_HAM_MEDIUM(-1.00)[-1.003]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; NEURAL_SPAM_SHORT(0.55)[0.553]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::629:from]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; 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]; MAILMAN_DEST(0.00)[freebsd-current]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 25 Sep 2020 23:25:54 -0000 I'm using the beta git repo at , and I have been compiling source in that directory. Today, when I ran "git pull", it errored out instead of updating fully. I don't know if the error was a result of me building in the directory, but it seems like a reasonable possibility. It was never an issue with SVN, but should I build the source in a separate directory to avoid problems with git? I don't know if git keeps a log that I can check for the full output. If it does, I'd check if I knew the location. As it is, I only have the partial output still present in my terminal window. Following is the last portion of the output if it helps to identify the error and its cause: Auto-merging crypto/openssl/crypto/x509v3/v3_purp.c CONFLICT (content): Merge conflict in crypto/openssl/crypto/x509v3/v3_purp.c CONFLICT (rename/delete): crypto/x509/x_pubkey.c deleted in 2541f3df33872528e8bd003b97a78668119f812d and renamed to crypto/openssl/crypto/x509/x_pubkey.c in HEAD. Version HEAD of crypto/openssl/crypto/x509/x_pubkey.c left in tree. Auto-merging crypto/openssl/crypto/x509/x509_vfy.c CONFLICT (content): Merge conflict in crypto/openssl/crypto/x509/x509_vfy.c CONFLICT (rename/delete): crypto/x509/x509_local.h deleted in 2541f3df33872528e8bd003b97a78668119f812d and renamed to crypto/openssl/crypto/x509/x509_local.h in HEAD. Version HEAD of crypto/openssl/crypto/x509/x509_local.h left in tree. CONFLICT (rename/delete): crypto/whrlpool/wp_block.c deleted in 2541f3df33872528e8bd003b97a78668119f812d and renamed to crypto/openssl/crypto/whrlpool/wp_block.c in HEAD. Version HEAD of crypto/openssl/crypto/whrlpool/wp_block.c left in tree. Auto-merging crypto/openssl/crypto/ui/ui_openssl.c CONFLICT (content): Merge conflict in crypto/openssl/crypto/ui/ui_openssl.c CONFLICT (rename/delete): crypto/ts/ts_rsp_sign.c deleted in 2541f3df33872528e8bd003b97a78668119f812d and renamed to crypto/openssl/crypto/ts/ts_rsp_sign.c in HEAD. Version HEAD of crypto/openssl/crypto/ts/ts_rsp_sign.c left in tree. CONFLICT (rename/delete): crypto/store/store_lib.c deleted in 2541f3df33872528e8bd003b97a78668119f812d and renamed to crypto/openssl/crypto/store/store_lib.c in HEAD. Version HEAD of crypto/openssl/crypto/store/store_lib.c left in tree. CONFLICT (rename/delete): crypto/store/loader_file.c deleted in 2541f3df33872528e8bd003b97a78668119f812d and renamed to crypto/openssl/crypto/store/loader_file.c in HEAD. Version HEAD of crypto/openssl/crypto/store/loader_file.c left in tree. CONFLICT (rename/delete): crypto/rsa/rsa_ameth.c deleted in 2541f3df33872528e8bd003b97a78668119f812d and renamed to crypto/openssl/crypto/rsa/rsa_ameth.c in HEAD. Version HEAD of crypto/openssl/crypto/rsa/rsa_ameth.c left in tree. CONFLICT (rename/delete): crypto/rand/rand_local.h deleted in 2541f3df33872528e8bd003b97a78668119f812d and renamed to crypto/openssl/crypto/rand/rand_local.h in HEAD. Version HEAD of crypto/openssl/crypto/rand/rand_local.h left in tree. CONFLICT (rename/delete): crypto/rand/drbg_lib.c deleted in 2541f3df33872528e8bd003b97a78668119f812d and renamed to crypto/openssl/crypto/rand/drbg_lib.c in HEAD. Version HEAD of crypto/openssl/crypto/rand/drbg_lib.c left in tree. CONFLICT (rename/delete): crypto/rand/drbg_ctr.c deleted in 2541f3df33872528e8bd003b97a78668119f812d and renamed to crypto/openssl/crypto/rand/drbg_ctr.c in HEAD. Version HEAD of crypto/openssl/crypto/rand/drbg_ctr.c left in tree. CONFLICT (add/add): Merge conflict in crypto/openssl/crypto/pem/pvkfmt.c Auto-merging crypto/openssl/crypto/pem/pvkfmt.c Auto-merging crypto/openssl/crypto/pem/pem_pkey.c CONFLICT (content): Merge conflict in crypto/openssl/crypto/pem/pem_pkey.c Auto-merging crypto/openssl/crypto/pem/pem_lib.c CONFLICT (content): Merge conflict in crypto/openssl/crypto/pem/pem_lib.c Auto-merging crypto/openssl/crypto/o_time.c CONFLICT (content): Merge conflict in crypto/openssl/crypto/o_time.c CONFLICT (rename/delete): crypto/modes/xts128.c deleted in 2541f3df33872528e8bd003b97a78668119f812d and renamed to crypto/openssl/crypto/modes/xts128.c in HEAD. Version HEAD of crypto/openssl/crypto/modes/xts128.c left in tree. CONFLICT (rename/delete): crypto/modes/ofb128.c deleted in 2541f3df33872528e8bd003b97a78668119f812d and renamed to crypto/openssl/crypto/modes/ofb128.c in HEAD. Version HEAD of crypto/openssl/crypto/modes/ofb128.c left in tree. CONFLICT (rename/delete): crypto/modes/modes_local.h deleted in 2541f3df33872528e8bd003b97a78668119f812d and renamed to crypto/openssl/crypto/modes/modes_local.h in HEAD. Version HEAD of crypto/openssl/crypto/modes/modes_local.h left in tree. CONFLICT (rename/delete): crypto/modes/gcm128.c deleted in 2541f3df33872528e8bd003b97a78668119f812d and renamed to crypto/openssl/crypto/modes/gcm128.c in HEAD. Version HEAD of crypto/openssl/crypto/modes/gcm128.c left in tree. CONFLICT (rename/delete): crypto/modes/ctr128.c deleted in 2541f3df33872528e8bd003b97a78668119f812d and renamed to crypto/openssl/crypto/modes/ctr128.c in HEAD. Version HEAD of crypto/openssl/crypto/modes/ctr128.c left in tree. CONFLICT (rename/delete): crypto/modes/cfb128.c deleted in 2541f3df33872528e8bd003b97a78668119f812d and renamed to crypto/openssl/crypto/modes/cfb128.c in HEAD. Version HEAD of crypto/openssl/crypto/modes/cfb128.c left in tree. CONFLICT (rename/delete): crypto/modes/ccm128.c deleted in 2541f3df33872528e8bd003b97a78668119f812d and renamed to crypto/openssl/crypto/modes/ccm128.c in HEAD. Version HEAD of crypto/openssl/crypto/modes/ccm128.c left in tree. CONFLICT (rename/delete): crypto/modes/cbc128.c deleted in 2541f3df33872528e8bd003b97a78668119f812d and renamed to crypto/openssl/crypto/modes/cbc128.c in HEAD. Version HEAD of crypto/openssl/crypto/modes/cbc128.c left in tree. CONFLICT (rename/delete): crypto/mem_sec.c deleted in 2541f3df33872528e8bd003b97a78668119f812d and renamed to crypto/openssl/crypto/mem_sec.c in HEAD. Version HEAD of crypto/openssl/crypto/mem_sec.c left in tree. CONFLICT (rename/delete): crypto/err/openssl.txt deleted in 2541f3df33872528e8bd003b97a78668119f812d and renamed to crypto/openssl/crypto/err/openssl.txt in HEAD. Version HEAD of crypto/openssl/crypto/err/openssl.txt left in tree. Auto-merging crypto/openssl/crypto/engine/eng_lib.c CONFLICT (content): Merge conflict in crypto/openssl/crypto/engine/eng_lib.c CONFLICT (add/add): Merge conflict in crypto/openssl/crypto/ec/ecp_nistz256.c Auto-merging crypto/openssl/crypto/ec/ecp_nistz256.c CONFLICT (rename/delete): crypto/ec/ecp_nistp521.c deleted in 2541f3df33872528e8bd003b97a78668119f812d and renamed to crypto/openssl/crypto/ec/ecp_nistp521.c in HEAD. Version HEAD of crypto/openssl/crypto/ec/ecp_nistp521.c left in tree. CONFLICT (rename/delete): crypto/ec/ecp_nistp224.c deleted in 2541f3df33872528e8bd003b97a78668119f812d and renamed to crypto/openssl/crypto/ec/ecp_nistp224.c in HEAD. Version HEAD of crypto/openssl/crypto/ec/ecp_nistp224.c left in tree. CONFLICT (rename/delete): crypto/ec/ec_local.h deleted in 2541f3df33872528e8bd003b97a78668119f812d and renamed to crypto/openssl/crypto/ec/ec_local.h in HEAD. Version HEAD of crypto/openssl/crypto/ec/ec_local.h left in tree. Auto-merging crypto/openssl/crypto/ec/ec_lib.c CONFLICT (add/add): Merge conflict in crypto/openssl/crypto/ec/ec_ameth.c Auto-merging crypto/openssl/crypto/ec/ec_ameth.c CONFLICT (rename/delete): crypto/ec/asm/ecp_nistz256-armv4.pl deleted in 2541f3df33872528e8bd003b97a78668119f812d and renamed to crypto/openssl/crypto/ec/asm/ecp_nistz256-armv4.pl in HEAD. Version HEAD of crypto/openssl/crypto/ec/asm/ecp_nistz256-armv4.pl left in tree. CONFLICT (rename/delete): crypto/cmac/cmac.c deleted in 2541f3df33872528e8bd003b97a78668119f812d and renamed to crypto/openssl/crypto/cmac/cmac.c in HEAD. Version HEAD of crypto/openssl/crypto/cmac/cmac.c left in tree. Auto-merging crypto/openssl/crypto/bn/bn_lib.c CONFLICT (content): Merge conflict in crypto/openssl/crypto/bn/bn_lib.c CONFLICT (add/add): Merge conflict in crypto/openssl/appveyor.yml Auto-merging crypto/openssl/appveyor.yml Auto-merging crypto/openssl/apps/s_client.c CONFLICT (content): Merge conflict in crypto/openssl/apps/s_client.c Auto-merging crypto/openssl/README CONFLICT (content): Merge conflict in crypto/openssl/README CONFLICT (rename/delete): NOTES.PERL deleted in 2541f3df33872528e8bd003b97a78668119f812d and renamed to crypto/openssl/NOTES.PERL in HEAD. Version HEAD of crypto/openssl/NOTES.PERL left in tree. Auto-merging crypto/openssl/NEWS CONFLICT (content): Merge conflict in crypto/openssl/NEWS Auto-merging crypto/openssl/Configure CONFLICT (content): Merge conflict in crypto/openssl/Configure Auto-merging crypto/openssl/CHANGES CONFLICT (content): Merge conflict in crypto/openssl/CHANGES Auto-merging contrib/one-true-awk/lex.c Auto-merging contrib/one-true-awk/b.c Auto-merging contrib/one-true-awk/awk.h CONFLICT (rename/delete): man/vi.1 deleted in 2541f3df33872528e8bd003b97a78668119f812d and renamed to contrib/nvi/man/vi.1 in HEAD. Version HEAD of contrib/nvi/man/vi.1 left in tree. CONFLICT (add/add): Merge conflict in contrib/libexecinfo/unwind.c Auto-merging contrib/libexecinfo/unwind.c CONFLICT (rename/delete): warshall.c deleted in 2541f3df33872528e8bd003b97a78668119f812d and renamed to contrib/byacc/warshall.c in HEAD. Version HEAD of contrib/byacc/warshall.c left in tree. CONFLICT (rename/delete): closure.c deleted in 2541f3df33872528e8bd003b97a78668119f812d and renamed to contrib/byacc/closure.c in HEAD. Version HEAD of contrib/byacc/closure.c left in tree. Auto-merging bin/cp/Makefile CONFLICT (content): Merge conflict in bin/cp/Makefile Auto-merging ObsoleteFiles.inc CONFLICT (content): Merge conflict in ObsoleteFiles.inc Auto-merging Makefile.inc1 CONFLICT (content): Merge conflict in Makefile.inc1 Auto-merging Makefile CONFLICT (content): Merge conflict in Makefile CONFLICT (add/add): Merge conflict in .clang-format Auto-merging .clang-format warning: inexact rename detection was skipped due to too many files. warning: you may want to set your merge.renamelimit variable to at least 132108 and retry the command. Automatic merge failed; fix conflicts and then commit the result. From owner-freebsd-current@freebsd.org Sat Sep 26 00:19: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 C3F793E9835 for ; Sat, 26 Sep 2020 00:19:33 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4ByqCm5R7fz3Wv7; Sat, 26 Sep 2020 00:19:32 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: by sdaoden.eu (Postfix, from userid 1000) id 9BE4C16059; Sat, 26 Sep 2020 02:19:25 +0200 (CEST) Date: Sat, 26 Sep 2020 02:19:25 +0200 From: Steffen Nurpmeso To: Patrick McMunn Cc: emaste@freebsd.org, freebsd-current@freebsd.org Subject: Re: error pulling from the Beta git repo Message-ID: <20200926001925.BVBKn%steffen@sdaoden.eu> In-Reply-To: References: Mail-Followup-To: Patrick McMunn , emaste@freebsd.org, freebsd-current@freebsd.org User-Agent: s-nail v14.9.19 OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. X-Rspamd-Queue-Id: 4ByqCm5R7fz3Wv7 X-Spamd-Bar: / X-Spamd-Result: default: False [-0.80 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.97)[-0.975]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sdaoden.eu]; NEURAL_HAM_LONG(-0.98)[-0.984]; NEURAL_SPAM_SHORT(0.46)[0.460]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_CONTAINS_FROM(1.00)[]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15987, ipnet:217.144.128.0/20, country:DE]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 26 Sep 2020 00:19:33 -0000 Patrick McMunn wrote in : |I'm using the beta git repo at , and I have been compiling source in that |directory. Today, when I ran "git pull", it errored out instead of updating |fully. I don't know if the error was a result of me building in the |directory, but it seems like a reasonable possibility. It was never an |issue with SVN, but should I build the source in a separate directory to |avoid problems with git? I don't know if git keeps a log that I can check |for the full output. If it does, I'd check if I knew the location. As it |is, I only have the partial output still present in my terminal window. $ git clean -fxd [--dry-run] $ [git reset --hard HEAD] $ [git fetch -vv] $ [git gc [--aggressive --prune=all]] $ git checkout -B local-branch-name origin/branch-name [Or git update-ref local-branch-name refs/remotes/origin/branch-name] Alternatively just use a bare repository as a database and several different checked-out working directories somewhere else. Btw. the Linux distro i use has a git driver for its ports system, it goes like that: cd "$REPOSITORY" 2> "/dev/null" if [ $? -lt 1 ]; then git checkout -q "$BRANCH" git fetch -q git diff --pretty=format: --name-status "$BRANCH" origin/"$BRANCH" | sed "s/M\t/ Edit /g; s/A\t/ Checkout /g; s/D\t/ Delete /g" | sort git clean -q -f git reset -q --hard origin/"$BRANCH" gc= else git clone -q -b "$BRANCH" "$URL" "$REPOSITORY" ls -1 $REPOSITORY | sed "s/^/ Checkout /" gc=--aggressive fi git gc --quiet $gc --prune=all That gc stuff is a local addition of mine, i hate stale stuff. Good night. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From owner-freebsd-current@freebsd.org Sat Sep 26 00:33: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 470FF3EA732 for ; Sat, 26 Sep 2020 00:33:12 +0000 (UTC) (envelope-from bakul@iitbombay.org) Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4ByqWW3fJ8z3XjG for ; Sat, 26 Sep 2020 00:33:11 +0000 (UTC) (envelope-from bakul@iitbombay.org) Received: by mail-pl1-x636.google.com with SMTP id c3so172291plz.5 for ; Fri, 25 Sep 2020 17:33:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=6z+qP7Bu2lS3P34ghO0dueW0+ZFbXRNVc/v4s81Yu8I=; b=RaUCehWr1GpvLjApvxKKI3Qza8bfELm7dEgrnMiWgYl2tcBqRyWjmwbCZILhNjShm/ at2b0p/umkoyQW55DUVNmk+TL/15HnmbK20ToLg2v4FlHeWQzbXr1eCRBe3Uh217Kha1 +uwOK9odpbdSLwXKvGwtIeuB0ldP2Ns4bv5h2bcWhKZTQpoSQlJoLFcTJOcOsaD2B26v CzMrtOkhln4d7Tjtq4onb64NjlvYsSahNzMWcDYfqjxZmvTURf+PgM/lWKOvRUqJMfBG T+wF3lhULpFjQT/ePO+MECX9RbX2/T+Nrrl9SFIIhDpSj0u3JRdk3p82B2DsY/lyaIRZ /Wrg== X-Gm-Message-State: AOAM532BVx9mRif/rAVtGl7n0F50dLE5aVtc7ip4RoAvNXW0A4HTplrK gACCJg9koXBW6nFIVLN/JdqyFV7nIe/L0Q8n X-Google-Smtp-Source: ABdhPJy8c2nbLnY+X3vqkqGIlmYI0+a67N2niyLFuDKA4JCahjqljxG0GD6Ciu02wZPJxGTkc4mSHQ== X-Received: by 2002:a17:90a:7bcf:: with SMTP id d15mr128701pjl.230.1601080388570; Fri, 25 Sep 2020 17:33:08 -0700 (PDT) Received: from [192.168.1.113] (172-125-77-130.lightspeed.sntcca.sbcglobal.net. [172.125.77.130]) by smtp.gmail.com with ESMTPSA id a13sm3129120pgq.41.2020.09.25.17.33.07 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 25 Sep 2020 17:33:07 -0700 (PDT) From: Bakul Shah Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Subject: fatal error: 'cpuid.h' file not found Message-Id: Date: Fri, 25 Sep 2020 17:33:05 -0700 To: freebsd-current@freebsd.org X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Rspamd-Queue-Id: 4ByqWW3fJ8z3XjG X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.38 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[iitbombay-org.20150623.gappssmtp.com:s=20150623]; FREEFALL_USER(0.00)[bakul]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; 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(-1.00)[-0.999]; RCVD_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[iitbombay.org]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; DKIM_TRACE(0.00)[iitbombay-org.20150623.gappssmtp.com:+]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::636:from]; NEURAL_HAM_SHORT(-0.37)[-0.371]; NEURAL_HAM_MEDIUM(-1.01)[-1.007]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 26 Sep 2020 00:33:12 -0000 Trying "make -j8 buildworld" with a very recent tree (revision 366156). This fails with /usr/src/sys/contrib/openzfs/lib/libspl/include/sys/simd.h:34:10: fatal = error: 'cpuid.h' file not found #include Could this be related to the flags I am using (in particular not building CLANG)? $ cat /etc/make.conf MALLOC_PRODUCTION=3Dyes WITH_CCACHE_BUILD=3Dyes CCACHE_DIR=3D/usr/obj/ccache $ cat /etc/src.conf WITHOUT_CLANG=3Dyes $ cat /etc/src-env.conf WITH_META_MODE=3Dyes I do kldload filemon before buildworld. Trying minimize incremental build time and don't really care to build clang every time. [I'd appreciate any advice on how to further cut down the build time] If it matters, I am using the cgit-beta tree. Thanks! From owner-freebsd-current@freebsd.org Sat Sep 26 07:14: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 90FE53F5E3F for ; Sat, 26 Sep 2020 07:14:51 +0000 (UTC) (envelope-from strigub@dialektika.com) Received: from strigub.esotery.net (strigub.esotery.net [109.251.97.75]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4Bz0Qy3c2lz4Chs; Sat, 26 Sep 2020 07:14:50 +0000 (UTC) (envelope-from strigub@dialektika.com) Received: from [10.10.10.189] (helo=SERJHOME) by strigub.esotery.net with smtp (Exim 4.94 (FreeBSD)) (envelope-from ) id 1kM4Pe-000EXu-NQ; Sat, 26 Sep 2020 10:14:40 +0300 Message-ID: <1646C7B3113541C0A684AD846CBF1EC0@SERJHOME> Reply-To: "S.N. Trigub" From: "S.N. Trigub" To: "Sergey V. Dyatko" , "Kristof Provost" , "xt" Cc: "FreeBSD Current" References: <58CADEBB-64FD-414E-AB19-E4F8D3CABCA5@FreeBSD.org> <20200925204745.6a08e357@laptop.domain> In-Reply-To: Date: Sat, 26 Sep 2020 10:14:35 +0300 Organization: =?UTF-8?B?0JfQkNCeICLQlNC40LDQu9C10LrRgtC40LrQsCI=?= MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 X-SA-Exim-Connect-IP: 10.10.10.189 X-SA-Exim-Mail-From: strigub@dialektika.com X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on strigub.esotery.net X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=ham autolearn_force=no version=3.4.4 Subject: Re: iflib/bridge kernel panic X-SA-Exim-Version: 4.2.1 X-SA-Exim-Scanned: Yes (on strigub.esotery.net) X-Rspamd-Queue-Id: 4Bz0Qy3c2lz4Chs X-Spamd-Bar: / X-Spamd-Result: default: False [-0.06 / 15.00]; HAS_REPLYTO(0.00)[strigub@dialektika.com]; R_SPF_ALLOW(-0.20)[+mx]; HAS_ORG_HEADER(0.00)[]; TO_DN_ALL(0.00)[]; HAS_X_PRIO_THREE(0.00)[3]; FREEMAIL_TO(0.00)[gmail.com,FreeBSD.org,hotmail.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:31148, ipnet:109.251.97.0/24, country:UA]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.97)[-0.973]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_SPAM_SHORT(0.17)[0.170]; NEURAL_HAM_LONG(-0.95)[-0.953]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[dialektika.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-current]; SUSPICIOUS_RECIPS(1.50)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 26 Sep 2020 07:14:51 -0000 Hi! There is some serios issue in kernel related to network interfaces. See my message "speedtest.net in multi connections mode causes the FreeBSD 13-CURRENT router to crash" from 28 aug 2020. I noticed that kernel every time goes into panic if users run on client computers in browser speedtest.net in multi connections mode. If my external network interface use VLAN this panic occurs when uplink has speed 100Mbits per second. Without VLAN speedtest passes without any problems at 100Mbits channel but every time goes into panic at 1Gbits outer channel. During crash, the console screen goes out and the server (router) stops responding to the keyboard. Can anyone do this test on their machine? Sergei. From: xt Sent: Friday, September 25, 2020 8:46 PM To: Sergey V. Dyatko ; Kristof Provost Cc: FreeBSD Current Subject: Re: iflib/bridge kernel panic Sergey V. Dyatko wrote: > On Mon, 21 Sep 2020 09:57:40 +0200 > "Kristof Provost" wrote: > >> On 21 Sep 2020, at 2:52, Shawn Webb wrote: >>>> From latest HEAD on a Dell Precision 7550 laptop: >>> >>> https://gist.github.com/lattera/a0803f31f58bcf8ead51ac1ebbc447e2 >>> >>> The last working boot environment was 14 Aug 2020. If I get some time to >>> bisect commits, I'll try to figure out the culprit. >>> >> Try https://reviews.freebsd.org/D26418 >> >> Best regards, >> Kristof > > I'm not sure, but doesn't this panic have the same root as mine? > Sorry, but I haven't text console and can post only screenshot[s] > from IP-KVM > https://gyazo.com/fee41c5267e9fc543d43901e498b7c94 > > rc.conf have something like: > clonned_interfaces="lagg0 vlan101" > ifconfig_lagg0="laggproto lacp laggport em0 laggport em1 x.x.x.x/mask" > ifconfig_vlan101="vlan 101 vlandev lagg0 192.168.1.29/24" > > without VLAN part all works fine. > Installed from FreeBSD-13.0-CURRENT-amd64-20200924-3c514403bef-disc1.iso Yes, same panic. _______________________________________________ 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 Sep 26 11:40:57 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 683193FBC2E for ; Sat, 26 Sep 2020 11:40:57 +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 4Bz6L02MFFz4VDK for ; Sat, 26 Sep 2020 11:40:55 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (zarychtam@localhost [127.0.0.1]) by plan-b.pwste.edu.pl (8.16.1/8.16.1) with ESMTPS id 08QBejuo033342 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 26 Sep 2020 13:40:45 +0200 (CEST) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: (from zarychtam@localhost) by plan-b.pwste.edu.pl (8.16.1/8.16.1/Submit) id 08QBejDO033341 for freebsd-current@freebsd.org; Sat, 26 Sep 2020 13:40:45 +0200 (CEST) (envelope-from zarychtam) Date: Sat, 26 Sep 2020 13:40:45 +0200 From: Marek Zarychta To: freebsd-current@freebsd.org Subject: clang build buggy code with certain CPUTYPE setting Message-ID: <20200926114045.GA31128@plan-b.pwste.edu.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="VbJkn9YxBvnuCH5J" Content-Disposition: inline X-Rspamd-Queue-Id: 4Bz6L02MFFz4VDK X-Spamd-Bar: ------- X-Spamd-Result: default: False [-7.19 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[plan-b.pwste.edu.pl:s=plan-b-mailer]; NEURAL_HAM_MEDIUM(-0.96)[-0.957]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_MED(-2.00)[pwste.edu.pl:dkim]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.03)[-1.031]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; DKIM_TRACE(0.00)[plan-b.pwste.edu.pl:+]; DMARC_POLICY_ALLOW(-0.50)[plan-b.pwste.edu.pl,none]; NEURAL_HAM_SHORT(-0.30)[-0.301]; SIGNED_PGP(-2.00)[]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:206006, ipnet:2001:678:618::/48, country:PL]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 26 Sep 2020 11:40:57 -0000 --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Dear list, I have done a few builds of CURRENT in a row one or two weeks apart. The builds with CPUTYPE?=3Damdfam10 set produce buggy code, for example while running mergemaster I get this error: PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed source, and associated run script. Stack dump: 0. Program arguments: cc --version=20 #0 0x00000000040ede6e (/usr/bin/cc+0x40ede6e) #1 0x00000000040ec0e5 (/usr/bin/cc+0x40ec0e5) #2 0x00000000040ee550 (/usr/bin/cc+0x40ee550) #3 0x000000080553babe (/lib/libthr.so.3+0x19abe) Illegal instruction make: "/usr/src/share/mk/bsd.compiler.mk" line 181: Unable to determine compiler type for CC=3Dcc. Consider setting COMPILER_TYPE. The 13-CURRENT world built without CPUTYPE runs fine, the same for recent 12.2-STABLE world build with CPUTYPE?=3Damdfam10 on the same machine. Any tips would be appreciated, -- =20 Marek Zarychta --VbJkn9YxBvnuCH5J Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEMOqvKm6wKvS1/ZeCdZ/s//1SjSwFAl9vKLoACgkQdZ/s//1S jSz57gf7BHw3v6gQjmE2yGq+OZ+3iEGFq3ks3sInRLZXT2uWJ1xMpS/xNjiMErJq wjvc9auH29kkNVtII6Gr2QTZ0Tha8M1ooOUzGv++kIgrzda0tqkikmwa97KU6f+B WMkaojxVItlIqoYOffM7JX2W95cYDImf9UHKEDTFCmUoOOcorgDntZyNAsU5LCIl STX7r5KgdCj5mP+z32dFHOi2BlgfHtec2eyJw1iY7L1sc6dx706bZgOCOdiafkMk VNYw68fyHQBoBNokqaj8GqpNUgtJMVNDXtNHL3tmbmA7+hDqd/MLj9HSSt4doooI JIwuDYBA4bRxGe4y8USZrneZgK+rWg== =sBwH -----END PGP SIGNATURE----- --VbJkn9YxBvnuCH5J-- From owner-freebsd-current@freebsd.org Sat Sep 26 15:48: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 65A444222C1 for ; Sat, 26 Sep 2020 15:48:46 +0000 (UTC) (envelope-from dim@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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4BzCqy0hxkz3VGH; Sat, 26 Sep 2020 15:48:46 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:470:7a58:1::1]) (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 D6BAF279C5; Sat, 26 Sep 2020 15:48:45 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:470:7a58::1541:df91:ecb9:de76] (unknown [IPv6:2001:470:7a58:0:1541:df91:ecb9:de76]) (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 8AB5A30CF; Sat, 26 Sep 2020 17:48:44 +0200 (CEST) From: Dimitry Andric Message-Id: <6AA016B6-EEAC-4580-B7F0-9D274ADA9E73@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_6C302055-441C-4F4A-9B7C-EC1B2E1846F6"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Subject: Re: clang build buggy code with certain CPUTYPE setting Date: Sat, 26 Sep 2020 17:48:33 +0200 In-Reply-To: <20200926114045.GA31128@plan-b.pwste.edu.pl> Cc: freebsd-current@freebsd.org To: Marek Zarychta References: <20200926114045.GA31128@plan-b.pwste.edu.pl> X-Mailer: Apple Mail (2.3445.104.17) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 26 Sep 2020 15:48:46 -0000 --Apple-Mail=_6C302055-441C-4F4A-9B7C-EC1B2E1846F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 26 Sep 2020, at 13:40, Marek Zarychta = wrote: >=20 > I have done a few builds of CURRENT in a row one or two weeks apart. = The > builds with CPUTYPE?=3Damdfam10 set produce buggy code, for example = while > running mergemaster I get this error: >=20 > PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and > include the crash backtrace, preprocessed source, and associated run > script. > Stack dump: > 0. Program arguments: cc --version > #0 0x00000000040ede6e (/usr/bin/cc+0x40ede6e) > #1 0x00000000040ec0e5 (/usr/bin/cc+0x40ec0e5) > #2 0x00000000040ee550 (/usr/bin/cc+0x40ee550) > #3 0x000000080553babe (/lib/libthr.so.3+0x19abe) > Illegal instruction > make: "/usr/src/share/mk/bsd.compiler.mk" line 181: Unable to = determine > compiler type for CC=3Dcc. Consider setting COMPILER_TYPE. >=20 > The 13-CURRENT world built without CPUTYPE runs fine, the same for > recent 12.2-STABLE world build with CPUTYPE?=3Damdfam10 on the same > machine. Hi Marek, In r365507 (on 2020-09-09) I committed a fix for amdfam10: ------------------------------------------------------------------------ r365507 | dim | 2020-09-09 20:11:04 +0200 (Wed, 09 Sep 2020) | 17 lines Merge commit e6bb4c8e7 from llvm git (by Craig Topper): [X86] SSE4_A should only imply SSE3 not SSSE3 in the frontend. SSE4_1 and SSE4_2 due imply SSSE3. So I guess I got confused when switching the code to being table based in D83273. Fixes PR47464 This should fix builds with -march=3Damdfam10 emitting SSSE3 = instructions such as pshufb, which lead to programs crashing with SIGILL on such processors. Reported by: avg MFC after: 6 weeks X-MFC-With: r364284 So I expect that the "Illegal instruction" you are seeing is an SSSE3 instruction. If this happens with your base compiler, please get a known-good copy from one of the snapshot images. Ensure your /usr/src is r365507 or later, then do a full buildworld and reinstall. -Dimitry --Apple-Mail=_6C302055-441C-4F4A-9B7C-EC1B2E1846F6 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 iFwEARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCX29i0gAKCRCwXqMKLiCW o9GbAJYiNkXYA4MMCdi1DQ7JPi+S9TUJAKDw8QLjUFqT5ntPcuLEDqCO6rOtXg== =HBEa -----END PGP SIGNATURE----- --Apple-Mail=_6C302055-441C-4F4A-9B7C-EC1B2E1846F6-- From owner-freebsd-current@freebsd.org Sat Sep 26 19:51: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 7DCC14274A6; Sat, 26 Sep 2020 19:51:00 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4BzKCR53d4z41R3; Sat, 26 Sep 2020 19:50:59 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: by sdaoden.eu (Postfix, from userid 1000) id 0E09516059; Sat, 26 Sep 2020 21:50:57 +0200 (CEST) Date: Sat, 26 Sep 2020 21:50:56 +0200 From: Steffen Nurpmeso To: FreeBSD Current , freebsd-git@freebsd.org Cc: Renato Botelho , Ed Maste Subject: Re: Please check the current beta git conversions Message-ID: <20200926195056.1QqEB%steffen@sdaoden.eu> In-Reply-To: <20200903191410.sgjUQ%steffen@sdaoden.eu> References: <20200903191410.sgjUQ%steffen@sdaoden.eu> Mail-Followup-To: FreeBSD Current , freebsd-git@freebsd.org, Renato Botelho , Ed Maste User-Agent: s-nail v14.9.19 OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. X-Rspamd-Queue-Id: 4BzKCR53d4z41R3 X-Spamd-Bar: - X-Spamd-Result: default: False [-1.70 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.01)[-1.011]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+a]; DMARC_NA(0.00)[sdaoden.eu]; NEURAL_HAM_LONG(-0.98)[-0.981]; NEURAL_HAM_SHORT(-0.41)[-0.414]; MID_CONTAINS_FROM(1.00)[]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15987, ipnet:217.144.128.0/20, country:DE]; MAILMAN_DEST(0.00)[freebsd-current,freebsd-git] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 26 Sep 2020 19:51:00 -0000 Steffen Nurpmeso wrote in <20200903191410.sgjUQ%steffen@sdaoden.eu>: |For one: thanks all, it now works! | |Steffen Nurpmeso wrote in | <20200903151825.G_Rv9%steffen@sdaoden.eu>: ||Renato Botelho wrote in || : |||On 02/09/20 20:20, Steffen Nurpmeso wrote: |||> Ed Maste wrote in |||> : |||> |||> I tried simply updating my github clone by switching |||> |||> url = https://cgit-beta.freebsd.org/src.git |||> #url = https://github.com/freebsd/freebsd.git |||> |||> and whereas ls-remote worked fine fetch -v --dry-run aborted as |||> well as normal fetch, after dumping dozens of POSTs |||> |||> POST git-upload-pack (gzip 1472 to 804 bytes) |||> ... |||> POST git-upload-pack (gzip 976722 to 483608 bytes) |||> POST git-upload-pack (chunked) |||> error: RPC failed; HTTP 413 curl 22 The requested URL returned \ |||> error: 413 |||> fatal: the remote end hung up unexpectedly ... It fails again, repeatedly and reproducably for my monthly update. POST git-upload-pack (chunked) error: RPC failed; curl 18 transfer closed with outstanding read data remaining fatal: the remote end hung up unexpectedly A nice Sunday from Germany i wish. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From owner-freebsd-current@freebsd.org Sat Sep 26 19:55: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 DC6BD42773D for ; Sat, 26 Sep 2020 19:55:37 +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 4BzKJn32c4z42Cf; Sat, 26 Sep 2020 19:55:37 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (zarychtam@localhost [127.0.0.1]) by plan-b.pwste.edu.pl (8.16.1/8.16.1) with ESMTPS id 08QJtXcs019129 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 26 Sep 2020 21:55:33 +0200 (CEST) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: (from zarychtam@localhost) by plan-b.pwste.edu.pl (8.16.1/8.16.1/Submit) id 08QJtX4N019128; Sat, 26 Sep 2020 21:55:33 +0200 (CEST) (envelope-from zarychtam) Date: Sat, 26 Sep 2020 21:55:33 +0200 From: Marek Zarychta To: Dimitry Andric Cc: freebsd-current@freebsd.org Subject: Re: clang build buggy code with certain CPUTYPE setting Message-ID: <20200926195533.GA16596@plan-b.pwste.edu.pl> References: <20200926114045.GA31128@plan-b.pwste.edu.pl> <6AA016B6-EEAC-4580-B7F0-9D274ADA9E73@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2oS5YaxWCcQjTEyO" Content-Disposition: inline In-Reply-To: <6AA016B6-EEAC-4580-B7F0-9D274ADA9E73@FreeBSD.org> X-Rspamd-Queue-Id: 4BzKJn32c4z42Cf X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:206006, ipnet:2001:678:618::/48, country:PL] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 26 Sep 2020 19:55:37 -0000 --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Sep 26, 2020 at 05:48:33PM +0200, Dimitry Andric wrote: > On 26 Sep 2020, at 13:40, Marek Zarychta = wrote: > >=20 > > I have done a few builds of CURRENT in a row one or two weeks apart. The > > builds with CPUTYPE?=3Damdfam10 set produce buggy code, for example whi= le > > running mergemaster I get this error: > >=20 > > PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and > > include the crash backtrace, preprocessed source, and associated run > > script. > > Stack dump: > > 0. Program arguments: cc --version > > #0 0x00000000040ede6e (/usr/bin/cc+0x40ede6e) > > #1 0x00000000040ec0e5 (/usr/bin/cc+0x40ec0e5) > > #2 0x00000000040ee550 (/usr/bin/cc+0x40ee550) > > #3 0x000000080553babe (/lib/libthr.so.3+0x19abe) > > Illegal instruction > > make: "/usr/src/share/mk/bsd.compiler.mk" line 181: Unable to determine > > compiler type for CC=3Dcc. Consider setting COMPILER_TYPE. > >=20 > > The 13-CURRENT world built without CPUTYPE runs fine, the same for > > recent 12.2-STABLE world build with CPUTYPE?=3Damdfam10 on the same > > machine. >=20 > Hi Marek, >=20 > In r365507 (on 2020-09-09) I committed a fix for amdfam10: >=20 > ------------------------------------------------------------------------ > r365507 | dim | 2020-09-09 20:11:04 +0200 (Wed, 09 Sep 2020) | 17 lines >=20 > Merge commit e6bb4c8e7 from llvm git (by Craig Topper): >=20 > [X86] SSE4_A should only imply SSE3 not SSSE3 in the frontend. >=20 > SSE4_1 and SSE4_2 due imply SSSE3. So I guess I got confused when > switching the code to being table based in D83273. >=20 > Fixes PR47464 >=20 > This should fix builds with -march=3Damdfam10 emitting SSSE3 instructions > such as pshufb, which lead to programs crashing with SIGILL on such > processors. >=20 > Reported by: avg > MFC after: 6 weeks > X-MFC-With: r364284 >=20 > So I expect that the "Illegal instruction" you are seeing is an SSSE3 > instruction. If this happens with your base compiler, please get a > known-good copy from one of the snapshot images. Ensure your /usr/src is > r365507 or later, then do a full buildworld and reinstall. >=20 > -Dimitry >=20 Dear Dimitry, Thank you for the information and for the fix. Sadly I must admit it doesn't work for me. I have tried two builds with fresh sources today to be certain and it looks like the bug is still present on FreeBSD 13-CURRENT r366186. Either the upstream fixed it only partially or it is another bug. As a workaround, I will build worlds without CPUTYPE?=3Damdfam10 for a while. I hope the problem will be resolved before clang 11 is MFCed to 12-STABLE. --=20 Marek Zarychta --2oS5YaxWCcQjTEyO Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEMOqvKm6wKvS1/ZeCdZ/s//1SjSwFAl9vnLIACgkQdZ/s//1S jSxqlwf/fKaRVWpTLv5YT2Eyfnybt25U/SEwSpq33UQv+ItZyG34tcl/G/euoSWv Ot9tFMnAHXS0CziyOVMyIS/70HnAgnZNlpRUuQI1eVOGLTcgwoH0wQ/QlFFTBssw XlcohMfjnZI+bHspY/iu9BfjMQTl500Bap1TAvaDbNEnTw/xurxiZkQScGkmf7Vi KENrPmeLzU58z7k2xmQpZA1YpDNu4Yz2QNcSIq0WGFSf/BHHev8L2gNfUpoAc3qM /RAFZmTc4sQ6Ghp9NpZy+iwL+4cAu1FVNBFAwotAi4M0uPRCRguMIrDi9EtUtYKf 0a5q2tF0kSuKEYoJO9t1kNTthqN/LA== =feP7 -----END PGP SIGNATURE----- --2oS5YaxWCcQjTEyO-- From owner-freebsd-current@freebsd.org Sat Sep 26 23:33:47 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 C6BF33E3F5E; Sat, 26 Sep 2020 23:33:47 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670086.outbound.protection.outlook.com [40.107.67.86]) (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 4BzQ8V68DDz4FFF; Sat, 26 Sep 2020 23:33:46 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ddVtrY+rCYXKQJylVPjHbH1oItpO8Ia5BlIkmUVE2CKx6mbPIFqdst6UKUGIZHQ+5f/KLkhIr1Eq5UVIjFGbbfI+Z2mrO8TnFMXA6vwM3YbNZelbnAmKO+2gwgSEroyLXLIPd1VKEsACS18Sq2Z4fcOAxmqmnTq6lAzlg7ue6nJcXVpq2eseKlJCchUFuVm3bsOc2rdAgMDSnQ/X1MwcLWlPYfuoCN4p1u1j0VZXmZSTuZYBUTzk6vpensfxEFl/UBLj2aSBa7dWMp7z1GtTXnTZ4qLAS0kD3FDgutWqXL985Ls3BA6bdF+qoI0VBv42+tSflBKyBS0Hqxa+eOoumQ== 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=+Rkkv0hXCDZGCy6t5EEvQOUpgw8GuR9sF9agdctGgI4=; b=hGnaOeljvxPM32V1B6J17cDDQssCfx60Ti8bqwlrMqy1tYOtD4xJJqCR3vHvuUFXrs+nATO1nEBCd95DUEvUd1WlRfQAOFGml/Hkhy6E2C3ttezAX02PU8r5J2DSiv4KvB6ORLnVtiICf+NE/LRdyEc5ve3VtpuVQJqx06+nYxOH41MsNEwlRsa3mhZr+bj7DDz+MtQnSmIIUDMDx3eYtszk5TeuMRiWmN1E8s1202DDWSbaMQhJn7sO4bQ9RdOYGOSIGYESU+NdiH8aVL8PaXq+1YT59ogXPr/JroqePYJavxX+gPP8F1Av7a7qNknf19pYLkJXpA49ibl83v+XfQ== 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 YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:24::27) by YTBPR01MB3438.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:1b::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.26; Sat, 26 Sep 2020 23:33:45 +0000 Received: from YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM ([fe80::687f:d85a:a0a3:bd20]) by YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM ([fe80::687f:d85a:a0a3:bd20%6]) with mapi id 15.20.3412.028; Sat, 26 Sep 2020 23:33:45 +0000 From: Rick Macklem To: FreeBSD Hackers , "freebsd-current@freebsd.org" Subject: RFC: should copy_file_range(2) remain Linux compatible or support special files? Thread-Topic: RFC: should copy_file_range(2) remain Linux compatible or support special files? Thread-Index: AQHWlFwtm/+ImGEdKkCaptKgpElFKw== Date: Sat, 26 Sep 2020 23:33:45 +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: a57845c6-fc79-4463-a624-08d862749c5f x-ms-traffictypediagnostic: YTBPR01MB3438: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: sduuz81oYZB7ti09m+skZyFjS40Zd9pzmUggqzDQpNxh/vTEJN0edI7uUh8ApxGoZmJiKnspqfYHcG87QA6tIP2P7eVzCB2EsRSvqwe9RAyG68fpn6cyeIkDIfiP79gCkrXwWWDpAFUTbkvJiHmOh4+yq/XE7G5kKfE8ijRPiFwTsxTh+8YCcK/QmSuYgwFFkoSNV7wAKFttB4OSyHXuEC0JPE3YkOB3h6LayhxR13aSk7QjRpJhXAZ+E7xVnI+iB6gvQSt8w0gsinA0mtXUYK56EQfUNLeWYEwdjYxilGnYAJwD4RWd4UsG6acR5kUZQi5FIvivur4hFlscd0NNbPIYM1wuMkp5NtLuqwAkt1JBk4KtgB66fLH7/0zHfvr2 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(376002)(396003)(366004)(346002)(136003)(39850400004)(8936002)(110136005)(8676002)(316002)(786003)(450100002)(86362001)(6506007)(7696005)(186003)(478600001)(55016002)(9686003)(2906002)(66446008)(64756008)(66556008)(66476007)(5660300002)(52536014)(83380400001)(33656002)(91956017)(66946007)(71200400001)(76116006); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: PDpvw9Tefe9g8ktGphXSmoMrGtwnL+QTW9cygeFa++6TUHKSrtkwUo6am/WxAyUJU48f4bBgrvDV9Fxyh11uYsB1Isb5FRWvXXleE9mRBi5LMfMngnsDSgIO126BCT6k/CzivZdwWDJtk/xP92ukhcFVX6r7vSwx2IBVpzCF9L1OIyFZ6o0+GXMq9tP04RjQxwAi/2EhpkhO+IPwuRmxa5DDQrLI7OcRn4DAZBNqxsJ0nksol18V/n8runpSTHkkslDAK3YHuEzegnBvluNwH4wWUS89jtWXerYG9b95Tu8Z7gdETKBLFRzU3Hkefz91KWVjK1aCnxfiYdKL93huuKHFSs1Ou0WfBeRtFdLOrJEdATlWN2yCEaNzkVJzhgYTkaoZbtNW/k43PO0c493zH+C/rSULsS4Q28jAx7HN7EZL+n1czTXoeo4Khb65s62WRLag8T0frdrYboy1/JM63zoBjfKkKPF9ROcn6L/VaoWTUFzZG1y1N2Rh0NiWqff5QK1mcMtgXDd8CGHgYjnGa63jVFZvbR0m6F+UjvXYU5gbeC8I/o/QlLuf3dnLppssDAXE1y9Z0+zGIoiZ97C2ZsjPBv53fQT9QUY6akQWHuaUQCGjL8R1T/Y8nCesHeSGkzwiLkxkTzNkYmr0xwmRDQTsJUb2VWQSEOPWX6F//fiXwXZNESbPR5OWmF2SJSeu+ZsNP9y7LqyfN4pJcZVRew== 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-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: a57845c6-fc79-4463-a624-08d862749c5f X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Sep 2020 23:33:45.1618 (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: qCanHT8AAeqYRPkoCpmMcU9te9GzSzAq8kn4CS74ExJy64BqGL4CDyHPJgBy/eggDx30zwroumAMjKJ6ExnhxQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTBPR01MB3438 X-Rspamd-Queue-Id: 4BzQ8V68DDz4FFF X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.73 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.991]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector1]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.01)[-1.009]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[uoguelph.ca:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[40.107.67.86:from]; NEURAL_HAM_SHORT(-0.73)[-0.729]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; RCVD_TLS_LAST(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers,freebsd-current]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.67.86:from] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: 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, 26 Sep 2020 23:33:47 -0000 I know cross-posting is frowned upon, but I wanted everyone who might=0A= like to comment to see this.=0A= =0A= Currently copy_file_range(2) only supports regular files, which is compatib= le=0A= with the Linux one, where EINVAL is returned when either file descriptor=0A= refers to a non-regular file.=0A= =0A= Alan Somers would like to extend the syscall to handle special files.=0A= I think he has a couple of reasons for this (he can correct me):=0A= - When integrating it into "cp", he needed to provide a fallback for=0A= special files and similar fallbacks would probably be needed for=0A= other utilities like "dd".=0A= - iSCSI provides a "copy" operation which could be implemented using=0A= copy_file_range(2)/VOP_COPY_FILE_RANGE() if it supported special files.= =0A= =0A= kib@ was concerned that a copy from /dev/zero would fill a disk, but=0A= I think that issue can be dealt with by limiting the duration of the syscal= l=0A= to 1sec (so that the utility can be terminated via SIGTERM or similar).=0A= =0A= I am on the fence w.r.t. since I modelled it after the Linux one and keepin= g=0A= it Linux compatible would facilitate portable code, but I understand why=0A= Alan Somers wants to extend it (the iSCSI support seems particularily usefu= l).=0A= =0A= Everyone, please comment on this, rick=0A=