I've set up armv7 boot media based on:
http://ftp3.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/14.0/FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20230803-8a5c836b51ce-264491.img.xz
for the OrangePi+2Ed (it also handles the RPi2B v1.1).
No builds by me. The ports installed are from the FreeBSD servers and
are for kyua activity's use, other than gdb.
The presence of panic and large count of hours waiting for
timeouts explain why this report only covers specific issues
and no a full kyua run at this point.
[I'll note that this activity has been driven by attempted testing
of lib32, where I then end up with the question "is this unique to
lib32?" and so end up looking at armv7 chroot on aarch64. More
problems there --and so the question "is this unique to armv7 use
on aarch64". This leads to looking at Cortex-A7 armv7 (a fully
native armv7) context for comparison. I've had to wander well
outside my original intended testing contexts and have ended up
blocked in each type of context. Given the original goal, I'm
sticking to main, not stable/* nor releng/*.* .]
EXAMPLE issue: *.py based kyua testing problem for armv7 main:
The kyua *.py based tests on armv7 main get long timeouts
when python executes as armv7 code, even for very simple
tests:
# /usr/bin/kyua test -k /usr/tests/Kyuafile
examples/test_examples.py:TestExampleSimple::test_with_cleanup
examples/test_examples.py:TestExampleSimple::test_with_cleanup -> broken:
Test case body timed out [300.062s]
Results file id is usr_tests.20230806-003823-404601
Results saved to /root/.kyua/store/results.usr_tests.20230806-003823-404601.db
0/1 passed (1 failed)
This happens even on the cortex-A7 system, no lib32 involved,
no chroot involved.
NOTE:
There are a lot of these tests and some have timeouts set at
3600s, others at 1800s and 1200s. Lots at 300s. If a full
kyua run completed, it would take a very long time to do so.
Kyua classifies all these long-timeout tests as broken. So
lots of testing is not happening, despte the time taken.
There are 10 or so:
-> skipped: comment me to run the test
and one each of each of:
-> skipped: Current architecture 'armv7' not supported
__test_cases_list__ -> broken: Test program did not exit cleanly
__test_cases_list__ -> broken: Test case list wrote to stderr
I do not know if this promblem type might be somehow tied to the
openssl 3 compatibility issue(s) that the ports python's currently
have for main. If it is, the error handling seems to not be
directly reporting anything that makes it obvious.
EXAMPLE armv7 related 'Alignment Fault' on read panic:
The kyua sys/netinet6/exthdr:exthdr panic has a different backtrace than
I've had from my builds, udp_input this time:
# /usr/bin/kyua test -k /usr/tests/Kyuafile sys/netinet6/exthdr:exthdr
sys/netinet6/exthdr:exthdr -> warning: KLD '/boot/kernel/if_epair.ko' is
newer than the linker.hints file
Fatal kernel mode data abort: 'Alignment Fault' on read
trapframe: 0xe014ab00
FSR=00000001, FAR=da87f00e, spsr=20000013
r0 =00000000, r1 =00000001, r2 =00000001, r3 =00000134
r4 =00000000, r5 =00000134, r6 =da87f00e, r7 =da87f022
r8 =00000134, r9 =c0918b04, r10=00000014, r11=e014ac28
r12=00000000, ssp=e014ab90, slr=c04534f4, pc =c048b34c
panic: Fatal abort
cpuid = 1
time = 1691281420
KDB: stack backtrace:
db_trace_self() at db_trace_self
pc = 0xc05ecde4 lr = 0xc0079c70 (db_trace_self_wrapper+0x30)
sp = 0xe014a8b8 fp = 0xe014a9d0
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
pc = 0xc0079c70 lr = 0xc02e99a0 (vpanic+0x140)
sp = 0xe014a9d8 fp = 0xe014a9f8
r4 = 0x00000100 r5 = 0x00000000
r6 = 0xc07597e2 r7 = 0xc0aeaec8
vpanic() at vpanic+0x140
pc = 0xc02e99a0 lr = 0xc02e9780 (doadump)
sp = 0xe014aa00 fp = 0xe014aa04
r4 = 0xe014ab00 r5 = 0x00000013
r6 = 0xda87f00e r7 = 0x00000001
r8 = 0x00000001 r9 = 0xe0773ba0
r10 = 0xda87f00e
doadump() at doadump
pc = 0xc02e9780 lr = 0xc0611184 (abort_align)
sp = 0xe014aa0c fp = 0xe014aa38
r4 = 0xda87f00e r5 = 0xe014aa04
r6 = 0xc02e9780 r10 = 0xe014aa0c
abort_align() at abort_align
pc = 0xc0611184 lr = 0xc06111f8 (abort_align+0x74)
sp = 0xe014aa40 fp = 0xe014aa58
r4 = 0x00000013 r10 = 0xda87f00e
abort_align() at abort_align+0x74
pc = 0xc06111f8 lr = 0xc0610e18 (abort_handler+0x498)
sp = 0xe014aa60 fp = 0xe014aaf8
r4 = 0x00000000 r10 = 0xda87f00e
abort_handler() at abort_handler+0x498
pc = 0xc0610e18 lr = 0xc05ef6ac (exception_exit)
sp = 0xe014ab00 fp = 0xe014ac28
r4 = 0x00000000 r5 = 0x00000134
r6 = 0xda87f00e r7 = 0xda87f022
r8 = 0x00000134 r9 = 0xc0918b04
r10 = 0x00000014
exception_exit() at exception_exit
pc = 0xc05ef6ac lr = 0xc04534f4 (ip_input+0x404)
sp = 0xe014ab90 fp = 0xe014ac28
r0 = 0x00000000 r1 = 0x00000001
r2 = 0x00000001 r3 = 0x00000134
r4 = 0x00000000 r5 = 0x00000134
r6 = 0xda87f00e r7 = 0xda87f022
r8 = 0x00000134 r9 = 0xc0918b04
r10 = 0x00000014 r12 = 0x00000000
udp_input() at udp_input+0x1c0
pc = 0xc048b34c lr = 0xc04534f4 (ip_input+0x404)
sp = 0xe014ac30 fp = 0xe014ac70
r4 = 0x00000001 r5 = 0x00000000
r6 = 0x00000000 r7 = 0x01000193
r8 = 0xda87f00e r9 = 0xc094a938
r10 = 0x00000014
ip_input() at ip_input+0x404
pc = 0xc04534f4 lr = 0xc04235bc (netisr_dispatch_src+0x100)
sp = 0xe014ac78 fp = 0xe014aca0
r4 = 0x00000004 r5 = 0xda854000
r6 = 0x00000000 r7 = 0xc0b5a2f8
r8 = 0x00000000 r9 = 0xc57f7780
r10 = 0x00000008
netisr_dispatch_src() at netisr_dispatch_src+0x100
pc = 0xc04235bc lr = 0xc041a384 (ether_demux+0x1bc)
sp = 0xe014aca8 fp = 0xe014acc0
r4 = 0xda854000 r5 = 0x00000001
r6 = 0xdb846400 r7 = 0x5e4a6f28
r8 = 0x00000000 r9 = 0xc57f7780
r10 = 0x00000008
ether_demux() at ether_demux+0x1bc
pc = 0xc041a384 lr = 0xc041bb68 (ether_nh_input+0x3dc)
sp = 0xe014acc8 fp = 0xe014acf0
r4 = 0xdb846400 r5 = 0xda854000
r6 = 0xda87f000 r10 = 0x00000008
ether_nh_input() at ether_nh_input+0x3dc
pc = 0xc041bb68 lr = 0xc04235bc (netisr_dispatch_src+0x100)
sp = 0xe014acf8 fp = 0xe014ad20
r4 = 0x00000006 r5 = 0xda854000
r6 = 0x00000000 r7 = 0xc0b5a378
r8 = 0x5e4a6f28 r9 = 0xc57f7780
r10 = 0x00000000
netisr_dispatch_src() at netisr_dispatch_src+0x100
pc = 0xc04235bc lr = 0xc041a808 (ether_input+0xec)
sp = 0xe014ad28 fp = 0xe014ad60
r4 = 0xdb846400 r5 = 0x00000000
r6 = 0xda854000 r7 = 0x00000000
r8 = 0x5e4a6f28 r9 = 0xc57f7780
r10 = 0x00000000
ether_input() at ether_input+0xec
pc = 0xc041a808 lr = 0xe098310c ($a.10+0xbc)
sp = 0xe014ad68 fp = 0xe014ad90
r4 = 0xdb846400 r5 = 0xdb7bf8c0
r6 = 0x00000000 r7 = 0xda854000
r8 = 0xe09724d3 r9 = 0xdb7bf8d0
r10 = 0x00000000
$a.10() at $a.10+0xbc
pc = 0xe098310c lr = 0xc03504dc (taskqueue_run_locked+0xb8)
sp = 0xe014ad98 fp = 0xe014ade0
r4 = 0xe0769e00 r5 = 0xe0769e50
r6 = 0xdb7bf8ec r7 = 0x00000001
r8 = 0x00000001 r9 = 0xc0768ff7
r10 = 0x00000000
taskqueue_run_locked() at taskqueue_run_locked+0xb8
pc = 0xc03504dc lr = 0xc0351560 (taskqueue_thread_loop+0x108)
sp = 0xe014ade8 fp = 0xe014ae18
r4 = 0x00000000 r5 = 0xe0769e00
r6 = 0xe0769e40 r7 = 0xc073cb53
r8 = 0xe0769e50 r9 = 0x00000100
r10 = 0xc0afde44
taskqueue_thread_loop() at taskqueue_thread_loop+0x108
pc = 0xc0351560 lr = 0xc02a384c (fork_exit+0xa0)
sp = 0xe014ae20 fp = 0xe014ae38
r4 = 0xe0773ba0 r5 = 0xc0ada560
r6 = 0xc0351458 r7 = 0xe0993f94
r8 = 0xe014ae40 r9 = 0xc0afab7c
fork_exit() at fork_exit+0xa0
pc = 0xc02a384c lr = 0xc05ef640 (swi_exit)
sp = 0xe014ae40 fp = 0x00000000
r4 = 0xc0351458 r5 = 0xe0993f94
r6 = 0xc0942429 r7 = 0xc72f21d0
r8 = 0xc0ada900 r10 = 0xc0afde44
swi_exit() at swi_exit
pc = 0xc05ef640 lr = 0xc05ef640 (swi_exit)
sp = 0xe014ae40 fp = 0x00000000
KDB: enter: panic
I've reported another backtrace previously that
I'll not repeat here. But such was for my personal
build context, unlike here.
"'Alignment Fault' on read" happens even on the cortex-A7
system, no lib32 involved, no chroot involved. The details
may vary for the backtrace across the contexts.
NON-FAILURE EXAMPLE for the cortex-A7 context:
In my in-armv7 chroot on aarch64 and/or lib32 based kyua,
testing I got crashes for the below type of test that I'm
not seeing in this cortex-A7 armv7 context:
# kldload -v -n if_bridge.ko
Loaded if_bridge.ko, id=5
# /usr/bin/kyua test -k /usr/tests/Kyuafile sys/net/if_bridge_test:gif
sys/net/if_bridge_test:gif -> failed: atf-check failed; see the output of the
test for details [12.344s]
Results file id is usr_tests.20230806-005112-971198
Results saved to /root/.kyua/store/results.usr_tests.20230806-005112-971198.db
0/1 passed (1 failed)
I'll have to continue to look into it for armv7 chroot on aarch64 and
in the hackish lib32-involved kyua-based testing. The overall status
suggests that for armv7 chroot and/or lib32, if_bridge.ko involvement
leads to panics.
OTHER POINTS beyond the 3 items . . .
GDB HANDLING OF SYSTEM DUMP FOR /var/crash/core.txt.* :
/var/crash/core.txt.0 ends up with gdb generated material that is
basically useless:
generic dumped core - see /var/crash/vmcore.0
Sun Aug 6 00:32:59 UTC 2023
FreeBSD generic 14.0-CURRENT FreeBSD 14.0-CURRENT armv7 1400093 #0
main-n264491-8a5c836b51ce: Thu Aug 3 12:10:56 UTC 2023
r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm.armv7/sys/GENERIC arm
panic: Fatal abort
GNU gdb (GDB) 13.1 [GDB v13.1 for FreeBSD]
. . .
Reading symbols from /boot/kernel/kernel...
Reading symbols from /usr/lib/debug//boot/kernel/kernel.debug...
warning: kld_current_sos: Can't read filename
/wrkdirs/usr/ports/devel/gdb/work-py39/gdb-13.1/gdb/thread.c:1337:
internal-error: switch_to_thread: Assertion `thr != NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
----- Backtrace -----
0xca962b ???
0x11880a7 ???
---------------------
/wrkdirs/usr/ports/devel/gdb/work-py39/gdb-13.1/gdb/thread.c:1337:
internal-error: switch_to_thread: Assertion `thr != NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) [answered Y; input not from terminal]
This is a bug, please report it. For instructions, see:
<https://www.gnu.org/software/gdb/bugs/>.
/wrkdirs/usr/ports/devel/gdb/work-py39/gdb-13.1/gdb/thread.c:1337:
internal-error: switch_to_thread: Assertion `thr != NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) [answered Y; input not from terminal]
Abort trap (core dumped)
NOTE: I ignored the rest of core.txt.0 after seeing the above.
KYUA LACKS INDICATIONS ABOUT PORTS TO INSTALL AND KERNEL MODULES TO PREINSTALL :
Various kyua tests depend on kernel modules that are not automatically loaded.
Various kyua tests depend on various ports, none of which are automatically
installed.
It looks to me like the appropriateness of various such things depends on
context,
so that only a subset might be appropriate by default (without extra
configuration).
No information about this seems to be present.
I'll note that running kyua inside an armv7 chroot leads to most kernel modules
needing to be preloaded outside the chroot in order for them to be available
to the chroot's kyua run. The armv7 ports need to be installed in the chroot
as well.
What I've done so far may well not be close to an optimal default. I'll not
get into the details of what I've done here.
===
Mark Millard
marklmi at yahoo.com
