Date: Thu, 28 Nov 2024 22:54:32 -0500 (EST) From: "Sean C. Farley" <scf@FreeBSD.org> To: Mark Millard <marklmi@yahoo.com> Cc: FreeBSD Current <freebsd-current@freebsd.org>, FreeBSD Mailing List <freebsd-ports@freebsd.org> Subject: Re: port binary dumping core on recent head in poudriere [tmpfs corruptions involving blocks of zeros that should not be all zeros] Message-ID: <7f4080f5-a371-9940-480b-df13956c76ab@FreeBSD.org> In-Reply-To: <4D541C32-7DF4-4CAC-B31E-D4DD17977154@yahoo.com> References: <4D541C32-7DF4-4CAC-B31E-D4DD17977154.ref@yahoo.com> <4D541C32-7DF4-4CAC-B31E-D4DD17977154@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 28 Nov 2024, Mark Millard wrote:
> Sean C. Farley <scf_at_FreeBSD.org> 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 <marklmi@yahoo.com> 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
-<<Missing EOF hole>>
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7f4080f5-a371-9940-480b-df13956c76ab>