From nobody Fri Nov 29 03:54:32 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4XzzpM16sSz5fkcD; Fri, 29 Nov 2024 03:54:51 +0000 (UTC) (envelope-from scf@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 "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XzzpM0Xdgz4VLD; Fri, 29 Nov 2024 03:54:51 +0000 (UTC) (envelope-from scf@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1732852491; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=cPlqcsZueNMhoN/nGCdf9Pq46pvKs+8i1OH/HOMbZPs=; b=Bgjs0rF/0RzlWdazDlPeTbhgNZqyQojm82EWzvNcmMFwoylrHO9vC0hGGh//01r2HHEQzR fa6LletW82IIdUSKFi8CNyhpd7C4RyGFJ1Qgq9hvjmD1PB1R9ln+gqYf6tnE+JhL7OK637 TS+5ZWqE7MzpOJ+leTxsB/2LQoAWrUW3q9LJz+vBeufoD7N2mJkd5JDVi7x0JSn2hwSUA9 JOJEUWW4oHo7aSaSk/I63Sacedeno9FIl9zG3Ca7yqL4HeIva7++mmN476N9FiORJ45z8X bjTBxJYZPJWzhVl9j5OathhZSUkCbJMXqukXuawuMX1dcUFymqYQ3jEiYWHUnQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1732852491; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=cPlqcsZueNMhoN/nGCdf9Pq46pvKs+8i1OH/HOMbZPs=; b=LnlHnpUzkqeK15+66Pv93WUx8JpACYna+CuuRZfWNLRD96YIq+0t2GkxWAY0n6KvlQf145 cc5DqotrmOLuCM8r4tKRZyX5lxNlN5/XtUo2C2T17/GijtD6oolXzPLpK/9h5Nc+yMvc2U a/LMwdUHft7S4vPSmx6GLnNb+lW902RkRbyctjyq3FAkvtBiNCOglhgIcaCyFNRXC6sCmt N07CN0CO3i91h0vmQG9+JuDN0sqIHKlLtsA7J8xiDLcg8T51Y0l/chSWT5tGjg0d/MKUuq GP0AOH7t1wQnuhFnQTW64ZdDFN3NHOZ+O+xp+ucv7i151mkky3GWs7FrnC/EsQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1732852491; a=rsa-sha256; cv=none; b=kTultyJsZk71OU0/NTDtbnbS8DwWR1/z/P7JJp9EU8H3ayY6V4ngKlNMcyjts+3Vyrdj7Y JPj9TwUc+Nd1GnaEpVGWdY3/+NhowUh4wuPnhcrIBsHXB+P6Q+y3qItBMEWDx6FihDFbyW 3srOYUQZAzB++27O7TGHjuVCzQ360ILt3+xm86eTqvWLEKL4FwMXwauOgh05qlXeBTmstX gkL4l7Qe6MTx4vd9UVK3sZj+Ng9jxZYwnDrdI44pcEi0zUYlq0lZrAIENZXgaNDQrgsr/l zVbDyqOHeoDsG9MkU/CupdagvjQRxfJsWJ5xlLuUS2r82hofCzxWgAiJGz1rig== Received: from thor.farley.org (1609341-v107.1360-static.crmlinaa.metronetinc.net [104.254.222.35]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: scf/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4XzzpL5mPMz1Hr3; Fri, 29 Nov 2024 03:54:50 +0000 (UTC) (envelope-from scf@FreeBSD.org) Date: Thu, 28 Nov 2024 22:54:32 -0500 (EST) From: "Sean C. Farley" To: Mark Millard cc: FreeBSD Current , FreeBSD Mailing List Subject: Re: port binary dumping core on recent head in poudriere [tmpfs corruptions involving blocks of zeros that should not be all zeros] In-Reply-To: <4D541C32-7DF4-4CAC-B31E-D4DD17977154@yahoo.com> Message-ID: <7f4080f5-a371-9940-480b-df13956c76ab@FreeBSD.org> References: <4D541C32-7DF4-4CAC-B31E-D4DD17977154.ref@yahoo.com> <4D541C32-7DF4-4CAC-B31E-D4DD17977154@yahoo.com> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed On Thu, 28 Nov 2024, Mark Millard wrote: > Sean C. Farley wrote on > Date: Thu, 28 Nov 2024 18:16:16 UTC : > >> On Mon, 25 Nov 2024, Mark Millard wrote: >> >>> On Nov 25, 2024, at 18:05, Mark Millard wrote: >>> >>>> Top posting going in a different direction that >>>> established a way to control the behavior in my >>>> context . . . >>> >>> For folks new to the discoveries: the context here >>> is poudriere bulk builds, for USE_TMPFS=all vs. >>> USE_TMPFS=no . My test context is amd64 on a >>> 7950X3D system with 192 GiBytes of RAM. Others have >>> other contexts, including an Intel system. *snip* >> System setup: >> - FreeBSD 14.2-STABLE > > The context that I investigated --and what was fixed by a commit only > applies to-- main [so; 15 as stands], not stable/14 . > > stable/14 has no commits mentioning "tmpfs" after 2024-Jun-04. Thank you. That was my mistake. I will continue searching for an answer. Once I find a way to more consistently trigger it, it will be much easier. I ran all of the tmpfs*.sh tests from HEAD which all pass except for tmpfs24.sh. $ ./all.sh -o tmpfs24.sh 20241128 22:33:38 all: tmpfs24.sh Min hole size is 4096, file size is 524288000. data #1 @ 0, size=4096) hole #2 @ 4096, size=4096 data #3 @ 8192, size=4096) hole #4 @ 12288, size=4096 data #5 @ 16384, size=4096) hole #6 @ 20480, size=524267520 --- /tmp/tmpfs24.exp 2024-11-28 22:33:40.222199000 -0500 +++ /tmp/tmpfs24.log 2024-11-28 22:33:40.225048000 -0500 @@ -5,4 +5,3 @@ hole #4 @ 12288, size=4096 data #5 @ 16384, size=4096) hole #6 @ 20480, size=524267520 -<> FAIL tmpfs24.sh exit code 1 >> - i7-14700K (latest BIOS which *should* fix Intel power-related bugs) >> - 128 GiB RAM >> - ZFS (mirrored drives) > > The primary test context was ZFS but no redundancy or such. (Only > really used for bectl activity.) But testing on a UFS copy of > the live directory tree also got the problem. The actual problem > was in tmpfs support. That was what I thought from what I read, but I wanted to make sure I did not leave out an important detail. >> - 2 encrypted swap partitions (64 GiB each, lightly used) > > No encryption involved in my context at all. > >> - Lightly undervolted (-0.06 offset to Global Core SVID Voltage) > > Nothing analogous in my context. > >> - /tmp is tmpfs > > I have no default areas that are tmpfs: so only what > poudriere temporarily created during the bulk builds. > >> - ${HOME}/.cache is tmpfs > > No use of ccache or the like. > >> - Poudriere: >> - USE_TMPFS=all > > I also use TMPFS_BLACKLIST . > > My personal environment causes use of -gline-tables-only as > debug information normally. (That option is clang/clang++ > specific. gcc* and clang* do not seem to have a common > notation for analogous settings on the command line.) > >> - ccache > > No use of ccache or the like. > >> - jail version in sync with host > > True for my context. But the issue that was fixed was > in the kernel code, not the world code. > >> - /usr/ports is mounted with nullfs > > Also true for my context. I appreciate that information. *snip build failure* > None of this is directly stable/14 : all main > [so: 15 as stands]. > > stable/14 has no commits mentioning "tmpfs" after 2024-Jun-04. So > none of these changes are involved for stable/14 . It was a long shot on my part anyway. :) Sean -- scf@FreeBSD.org