[Bug 290962] armv7 chroot and lib32 use on aarch64: example fio command works on real armv7 system boots but fails for aarch64-to-armv7 chroot or lib32 use

From: <bugzilla-noreply_at_freebsd.org>
Date: Tue, 11 Nov 2025 22:15:21 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=290962

            Bug ID: 290962
           Summary: armv7 chroot and lib32 use on aarch64: example fio
                    command works on real armv7 system boots but fails for
                    aarch64-to-armv7 chroot or lib32 use
           Product: Base System
           Version: 16.0-CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: arm
          Assignee: freebsd-arm@FreeBSD.org
          Reporter: marklmi26-fbsd@yahoo.com

THe below is a copy of, for example:

https://lists.freebsd.org/archives/freebsd-arm/2025-November/005408.html

Due to my normal environments being main [so: 16] based
the examples are various vintages of 16 based. The main's
are from official pkgbase distributions, not personal
builds. I do use the non-debug kernel variant.

On a real armv7 system, booted from a armv7 kernel,
so far the example fio command has worked correctly.

But moving that same USB3 capable media to an aarch64
system and mounting and chrooting into it to do the test
in the armv7 chroot fails.

Both the RPi5 tested and the Windows Dev Kit 20023
tested show the issue.

A lib32 example on aarch64:

# /usr/obj/DESTDIRs/main-armv7-chroot-ports-main/usr/local/bin/fio
--name=random_rw_test --filename=./testfile1 --rw=randrw --bs=128k \
--ioengine=posixaio --iodepth=256 --numjobs=4 --runtime=120 --time_based \
--group_reporting --direct=1 --size=1G
random_rw_test: (g=0): rw=randrw, bs=(R) 128KiB-128KiB, (W) 128KiB-128KiB, (T)
128KiB-128KiB, ioengine=posixaio, iodepth=256
...
fio-3.40
Starting 4 processes
fio: io_u error on file ./testfile1: File too large: write offset=772538368,
buflen=131072
. . . (lots of the above)
fio: io_u error on file ./testfile1: Bad address: write offset=524288,
buflen=131072
. . . (more "File too large: write offset" notices)
fio: pid=2078, err=27/file:io_u.c:1982, func=io_u error, error=File too large
. . . (more "File too large: write offset" notices)
fio: pid=2077, err=27/file:io_u.c:1982, func=io_u error, error=File too large
. . . (more "File too large: write offset" notices)
fio: pid=2079, err=27/file:io_u.c:1982, func=io_u error, error=File too large

random_rw_test: (groupid=0, jobs=4): err=27 (file:io_u.c:1982, func=io_u error,
error=File too large): pid=2077: Tue Nov 11 13:31:32 2025
lat (usec)   : 500=1.17%, 750=0.68%, 1000=1.66%
lat (msec)   : 2=3.71%, 4=5.27%, 20=3.22%, 50=32.81%, 2000=0.59%
cpu          : usr=0.19%, sys=0.64%, ctx=85, majf=3, minf=56
IO depths    : 1=0.4%, 2=0.8%, 4=1.6%, 8=3.1%, 16=6.2%, 32=12.5%, >=64=75.4%
   submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
   complete  : 0=0.1%, 4=99.3%, 8=0.1%, 16=0.1%, 32=0.0%, 64=0.0%, >=64=0.4%
   issued rwts: total=503,521,0,0 short=0,0,0,0 dropped=0,0,0,0
   latency   : target=0, window=0, percentile=100.00%, depth=256

Run status group 0 (all jobs):


Being in a armv7 chroot and testing such (with a simple
fio command instead of such a path) looks the same.

-- 
You are receiving this mail because:
You are the assignee for the bug.