Re: llvm10 build failure on Rpi3

On 2021-Jun-26, at 15:29, Mark Millard <marklmi at yahoo.com> wrote:
> 
> [freebsd-arm+owner at FreeBSD.org sent a notice of rejection
> of the original of the below because, according to it, I was
> not a subscriber to freebsd-arm. So this is a resend after
> (re-)subscribing. We will see if it is again rejected.]
> 
> On 2021-Jun-25, at 22:14, Mark Millard <marklmi at yahoo.com> wrote:
> 
>> On 2021-Jun-25, at 20:52, bob prohaska <fbsd at www.zefox.net> wrote:
>> 
>>> If you replicate the problem I'll be very pleased.
>>> And just slightly relieved.
>> 
>> 
>> No luck on the 1st try:
>> 
>> [ 28% 1315/4575] cd /wrkdirs/usr/ports/devel/llvm10/work/.build && /wrkdirs/usr/ports/devel/llvm10/work/.build/bin/llvm-tblgen -gen-global-isel -I /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/
>> lib/Target/AArch64 -I /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/include -I /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.s
>> rc/lib/Target/AArch64/AArch64.td --write-if-changed -o lib/Target/AArch64/AArch64GenGlobalISel.inc -d lib/Target/AArch64/AArch64GenGlobalISel.inc.d
>> . . .
>> [ 28% 1326/4575] cd /wrkdirs/usr/ports/devel/llvm10/work/.build && /wrkdirs/usr/ports/devel/llvm10/work/.build/bin/llvm-tblgen -gen-global-isel -I /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/AMDGPU -I /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/include -I /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/AMDGPU/AMDGPUGISel.td --write-if-changed -o lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc -d lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc.d
>> 
>> Both finished just fine, indicating that the prior file generations were
>> okay.
>> 
>> I'll put the options to be like you are using and try again.
> 
> No failure.
> 
> In a faster context with RAM such that there is no reported
> use of swap in top, I've tried a host kernel that is non-debug
> and a host kernel that is debug in combinations with host
> worlds that are non-debug vs. debug in combination with systems
> for the jail that are non-debug releng/13 based, non-debug
> main based, and debug main based.
> 
> So far none of that has failed.
> 
> On the RPi4B with total_mem=1024 I've only had the non-debug
> main host kernel and world and a world for jail use that was
> nondebug. But I've tried with and without junk:true.
> 
> No failures.
> 
> For the RPi4B, I've now got a debug host kernel and world
> and a debug world for jail use. So, by default, junk:true .
> 
> We will see if it gets a failure or not.
> 
> It is likely the last of the reproduction attempts based on
> the information so far.

No failure.

I do not plan on exploring swap/paging space sizes
that produce notices about being mistuned.

I do not plan on exploring use of spinning rust or
powered hubs. Or using USB2 for the SSD. (Use of
some vintage of RPi3B would require use of a
powered hub, so I'll not be trying that either.)

Not having replicated the problem, I'm not trying
some official build from expanding the likes of
artifacts.ci.freebsd.org materials.

RECOMMENDATION:

Since you have a failing context, I recommend that
you do the test of using expanded materials from
artifacts.ci.freebsd.org (so: use an official build)
with a swap space size that does not produce the
warning: See of the problem goes away vs. repeats
with such an "official" context.

Either your problem will be solved or you will at
least be able to report information about the
behavior of official build materials in a context
not reporting a mistuning.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)