From nobody Sat Aug 05 21:04:41 2023 X-Original-To: freebsd-arm@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 4RJFTS6bvXz4TkSd for ; Sat, 5 Aug 2023 21:05:00 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-24.consmr.mail.gq1.yahoo.com (sonic312-24.consmr.mail.gq1.yahoo.com [98.137.69.205]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4RJFTR3B68z3PDh for ; Sat, 5 Aug 2023 21:04:59 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=DOZrFrnE; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1691269497; bh=GGPiYQ02pcarAZnwfPpy+gAK+I2Bu7AloRJNZ5Sh/2A=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=DOZrFrnEDqISEbc1pIyZAW4HJ+CgUQ6Lb46rtlJaoJC8ai0OqYGA4SkUdYcEC0iGiXRa0aywRhVt5Dqt/T/LEHVQCIIw6QX8GOeHY5f7VrCtXioyMxoRk4ZWa+0siYKrN9XufLv7cYMSqoOvZW2fuEMph+oDRNbrKFEmsFIO/x+dkz3j0btGTebxm5Csq59XaX1yDzlPyAKNBueyIASSEEs/arjvN9mAyIV4+6hVTWwEgzqjqupdsUAD5WOiZkLcpwp7fJBwC5UVKF6vAn77o2qasS+sxHyRiaYL34Xc2Fm8ZKqC3wGAMdYO2kb4UhMMPObFA77ub+q1TDm0hB1DrA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1691269497; bh=DSl9Alg06QY+u68T7jglkem0Z6UKzwdHl0y1/pV+L75=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=gdGPRa5BosA/D74vtxvovXGoNLyFF1u4/4N2MEAxrjIexCoOoUO11mOcqYBH20GVTPM/7FpAcvtsRHYhPmeDDsPT2NM06SqDY3v8VfBVrknbpfEJMApM9S5t1B/Zj7mhALRlaoSQA4zvSBosVBnLfHP1HrTCaDba4p6golQVv8+Ywb0W7yqtBk8nJ7cJpW2pckAeSZPtf2C+1VQoBK98wTQi2aGKxb/k+ZQMr18kOGTM1fXvM78CbhRIJB8JY+P7WvJriZ5T1EUw4OF/GXmmxFdylUNgy7tV/CVzdLk2OWAuurgkLVPo+IrDWwN7M9eSX7IF7fBDk1cDUKMGDJ1s+A== X-YMail-OSG: BfwqYt0VM1mFkeR.q3va71tWHWEZAAD7hG146Eu0EjHNcA5rQWSd_qna31tGmE5 mhXtGeCR_6BJHa.PEiZSLo.736JAVR1WDNozukV6gJPjmbk3f3SFC2VvS48oVKw8WsYdf1cOgKjG E6uMsRFSzK734s4WNjKEMvfoArSzU4kbj1yk4yE4LN8Q8icNgPVsSDIh.IkRKRgNMr8DedWQT7PW zMCKrD5bPK0HtxJqm1F8Op6PfSG6OWuY9pl2.d28OfxaWFum.iSvDaEYLLru1Yw3tNsUja1qAfmi PmVJisOYuSEldbjBtpfFnCj_3ls0oCkcoI4TTZa7Xg8MCbAmDFr8PNtuE7qJKCHOG6Ouk5XdloZM ij7jaZNrlcEkB4ccdBqD5w3F0plOS8RBm14heoFPWwPfC86i7Bj_xYQJG_O9zdhN4mnH4vvISsA5 stNkVJx9Uwf.VpNqPnfgvwwRA_YJVkPLjvqBRRLvCTnxKSaz4TyfExMLpg0wbx5QNj4OWY7C5jGT 2Eq8m6VWVc21YSDbz8tW1L0UMl6u91k4mx47g5unQrF7PR8tQhbPw8os5T7v6.Q2Bw65iVvBepAR i1GVNppnIMkwahQFN_PBz.g.VZ3qdBoi2NhFbztAq.v7iiqoq.XcaK5._tLu3Jc8nqe2VA34ools NHZr7WUDyKelmmJYvLHP2dlQDnJS8iR2A8FodTazvz89Z9O3closzx9lmrpYmKy.EXN2yzHv1dRN qgGw8e8_HLoGHUaByBLOlD5jri9CAQuFSQRRrGCb5cYMor5m.JGVv4g9j_uzAExiHGOzQTMc.0tY UAmmoI2M.ao1NzCu.G5KMZ4RZpJzMs7HoWWxoZAxJh.L769IXXQKbHGmbdSe5kheUSxjmQfAxbkB F7nkExnW5Gi17Q2xBwkulZ5G.cmXkqbDPxdcnPwVr9yKTQzlikUrHU69s45ntsRwrwTqjO_o3eIT kocEOh.Q.l4YpP7j2jf2ErMJt7MtFaFRcOEGZJcKJssDBRFxo6G22PXRmck_E2utXqJKA.7o8roV Ps79rBwVu0sf4jbGITmTDUk54HtdI7IzCOSAN3KH_RjkL7gQ_ZOCNs5BOeVCIalIyRN4ldup3BDF aSJHX6ZW1__tYswQ6c7.CgfNsoIB3_8c80gQ_cex0Zxa62D0Bgs.FDS7CMv_YOPKjKoOVOb6FtOh VT_xQMKQhPEzG8NqbN9CNPPHThAzVKgZiiJSgFN0.Y2Ur1UIza27PqZu3ksFK40O84qmGaXBBgMS _RlER8UpVCgIvwvOqQkY_8WC5aVLF9swhTl7K7zTUIHjX6sm5_5LeFnixWNsv0MIxgyRSHxyvC8x rtD4HLwlaNuKhhR8B_c3ml8II7V_Dfbmn0WDPsWAedFlZplXyQupXEcEBGSxbN7ODb6tTYsoncMd bpGACID46k1QYPinC9LlumoAQpnAkEdkXetjhs1JFbgAdXmorf3DSfEOVMAwR4xCaU1bia8hXnHH xBKkEDQiiT97XJAloIIhHk0VOU5KZNZDnABb4Bp9q01.FCAgh009LfULD8RF4EC6yFfr6c.q40wN MCpd_j11UT7OMrChZ_.Tvi9ZLYNrJsYYeSD0e_NkyMk9igJ3CTgEwQ27sZRPTEo.WpeA6dx1xOPp SdXUVMWrMF5ckekOplCA.clZkIPLvf8arbtr9etTXuiaUzQ5ZXjR0RsaB_.JiuJhScgonv_eALTm 6oiL_tQWv6V8qProKyAG4z5hZ9jY.Ma8KrMB903xctshAawM49iCjsK92nd.8Qwhg_x8D9crIpGU 3NGfDVvJJJ_kjOkz9nroD2DUx1A_iT_ZT7TIFXFlTRR_IIWWMR67Zm_KzTuWuWH5LHjzcGHlOilG fngbS0Fbt7qo19Vs5uUy1tgznY3zZXIpUzS75acNHQBoyNe81JBbpqLqrQIbDK0NoIRmiDoEtgty 975ImoKu3YUePrIe8Lw3As2FuIS5626YXh8CBetLcvgG7fOH293UVUyMcpuSxvR7NlHhrFfe1BFG zdVowvA6heDjLSC635KTqthclwxjBz5.spUaMwVTIl0j9mf_KlEiMUGfKhWzqPNlycUyh3ND9IpH a2HqmqKPqVSuxD8RGkv3RJtOwC9Nw90rxfg3W05hR.nV_P5DU7F74EcOxU6QzElUI94uSEDsd2wE dCfGO1brKXW468EMuxTm0vPxMDOB5Ru5KrBgTlEEiYaWviDBFrFD7DrzvhjfdHmuR1YFL0dd9WqI zq1XSUFGK1Z.Fs.KXZY1v.7OzDnTRdqWn2keCV.Tj9ZUNOiVKP8JN7liU5mYvDJtRdxbRGNEP50O P X-Sonic-MF: X-Sonic-ID: 7b3e4617-6db5-4417-a75a-89f78968edcd Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Sat, 5 Aug 2023 21:04:57 +0000 Received: by hermes--production-bf1-7c4db57b6-q87r5 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 60564811b863437ea87695e7d3c164a3; Sat, 05 Aug 2023 21:04:53 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: Re: A native armv7 panic during kyua runs: sys/netinet6/exthdr:exthdr -> Fatal kernel mode data abort: 'Alignment Fault' on read From: Mark Millard In-Reply-To: <466233a6-f904-f2f4-ac9e-7476965e97c2@gmail.com> Date: Sat, 5 Aug 2023 14:04:41 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <8CDB7543-E21C-47BC-AB18-52D24ED855ED@yahoo.com> References: <466233a6-f904-f2f4-ac9e-7476965e97c2@gmail.com> To: meloun.michal@gmail.com X-Mailer: Apple Mail (2.3731.700.6) X-Spamd-Result: default: False [-2.36 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.86)[-0.864]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TAGGED_RCPT(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.205:from]; MID_RHS_MATCH_FROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.205:from]; DKIM_TRACE(0.00)[yahoo.com:+]; TO_DN_NONE(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Spamd-Bar: -- X-Rspamd-Queue-Id: 4RJFTR3B68z3PDh On Aug 5, 2023, at 11:27, Michal Meloun wrote: > Hi Mark, > can you please try a this patch? > = https://github.com/strejda/tegra/commit/bd4390c5f6a8b66b2fc83966d4fadb945a= 19dc23 I'll take a stab at testing it. But I'll note that description of the patch is somewhat odd: QUOTE Pack IP structures directly used for access packet data. All structures used to access data in byte buffers shall be marked as packed. Otherwise, this is undefined behavior - formally on every platform. END QUOTE __packed (and whatever it might be a macro for) is not part of any vintage of the C standard, not even as explicitly implementation defined nor as explicitly undefined. (C23's "attribute specifier sequence" notation use would give an implementation defined status as an understand, but not via explicit identification of the concept of packed in the standard.) As far as the language is concerned, there is no guarantee that a code generator will ensure to break things up into aligned accesses with assembly of the overall value if the members are not aligned in the first place, __packed or not. Nor does the language guarantee pack of padding in the layout for __packed. Past that, it is toolchain specific if __packed would avoid unaligned accesses for simple member access notation bytes yet also avoid having pad bytes. We will see for this context. (My history suggests a lack of overall uniformity in the interpretations given to declaring struct's as packed --or analogous wording for other languages that are not explicit about it.) > I'm sorry, but I don't have the time or energy to fully test it... I = only hope the actual patch is much easier than the one listed in = PR271759. > On 05.08.2023 8:11, Mark Millard wrote: >> On Aug 4, 2023, at 20:58, Warner Losh wrote: >>> It might make sense to work up a patch that skips this test on armv7 = after filing a bug (the usual way).... >>>=20 >>> Warner >> Actually, looking at the backtrace, it seems I've previously >> listed the same sort of backtrace structure in: >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D271759 >> comment 12. Hans Petter Selasky had been working on that >> bugzilla entry. I'll add a note that this time I got it >> with the built-in EtherNet instead of the dongle used >> previously --and that sys/netinet6/exthdr:exthdr is a >> way of producing the panic. [Done.] >> In /usr/main-src/tests/sys/netinet6/exthdr.sh , commenting >> out one line would disable the specific test (leading >> whitespace might not be preserved below): >> atf_init_test_cases() >> { >> # atf_add_test_case "exthdr" >> } >> [FYI: All my kyua activity has been for FreeBSD main, >> generally targeting contexts with some armv7 code >> involved. It is associated with my having been an >> tester of early lib32 drafts.] >> I already have another commented out line for an armv7 >> panic (leading whitespace might not be preserved): >> # git -C /usr/main-src/ diff tests/sys/net/ >> diff --git a/tests/sys/net/if_bridge_test.sh = b/tests/sys/net/if_bridge_test.sh >> index eb3a792df449..dcdac75103cd 100755 >> --- a/tests/sys/net/if_bridge_test.sh >> +++ b/tests/sys/net/if_bridge_test.sh >> @@ -675,7 +675,7 @@ atf_init_test_cases() >> atf_add_test_case "delete_with_members" >> atf_add_test_case "mac_conflict" >> atf_add_test_case "stp_validation" >> - atf_add_test_case "gif" >> +# atf_add_test_case "gif" >> atf_add_test_case "mtu" >> atf_add_test_case "vlan" >> } >> In the original discovery, having if_bridge.ko already loaded was >> important to getting the "gif" panic. >> But I've not yet put effort into isolating a cleaner/simpler test >> than I got the failure with. Nor have a done a range of comparisons >> of differing contexts yet. >> There are other armv7 related issues, one in particular >> being: >> A) All the long timeouts [300s+] are for *.py style tests. (Lots of >> these.) >> B) All the *.py style tests that do not have long timeout have one = of: >> -> skipped: comment me to run the test >> -> 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 >> The are about 10 of the "comment me" ones and 1 each of the other >> (B) ones, if I remember right. >> In other words, basically all the *.py based tests are broken or >> skipped as kyua classifies things. >> I've no clue yet if (A) is tied to the ports': >> cryptography/hazmat/bindings/_openssl.abi3.so >> openssl 3 incompatibility or not. But I've only seen the >> issue in armv7 contexts so far. >> I've spent time today on this issue but have made no progress >> on identifying what leads to the kdump/truss-output being as >> it is. >> If the *.py tests were working, I'd not be surprised to then >> find more armv7 panics than is now possible via the kyua tests. >>> On Fri, Aug 4, 2023 at 12:59=E2=80=AFAM Mark Millard = wrote: >>> While discovered via an attempted overall kyua run, the following is >>> sufficient to get the crash in my native armv7 context: >>>=20 >>> # /usr/bin/kyua test -k /usr/tests/Kyuafile = sys/netinet6/exthdr:exthdr >>> sys/netinet6/exthdr:exthdr -> Fatal kernel mode data abort: = 'Alignment Fault' on read >>> trapframe: 0xdfb97aa0 >>> FSR=3D00000001, FAR=3Ddb43ab76, spsr=3D60000013 >>> r0 =3Ddfedd000, r1 =3Ddfb97b34, r2 =3D00000000, r3 =3D00000000 >>> r4 =3D00000000, r5 =3D00000000, r6 =3Ddb43ab76, r7 =3Ddb43ab66 >>> r8 =3Dc096383c, r9 =3D00000000, r10=3Ddb132400, r11=3Ddfb97b60 >>> r12=3D00000000, ssp=3Ddfb97b30, slr=3Dc0b4e2c0, pc =3Dc04e6b70 >>>=20 >>> panic: Fatal abort >>> cpuid =3D 0 >>> time =3D 1691131498 >>> KDB: stack backtrace: >>> db_trace_self() at db_trace_self >>> pc =3D 0xc065f414 lr =3D 0xc007db80 = (db_trace_self_wrapper+0x30) >>> sp =3D 0xdfb97858 fp =3D 0xdfb97970 >>> db_trace_self_wrapper() at db_trace_self_wrapper+0x30 >>> pc =3D 0xc007db80 lr =3D 0xc031a834 (vpanic+0x140) >>> sp =3D 0xdfb97978 fp =3D 0xdfb97998 >>> r4 =3D 0x00000100 r5 =3D 0x00000000 >>> r6 =3D 0xc07c369a r7 =3D 0xc0b32e58 >>> vpanic() at vpanic+0x140 >>> pc =3D 0xc031a834 lr =3D 0xc031a6f4 (vpanic) >>> sp =3D 0xdfb979a0 fp =3D 0xdfb979a4 >>> r4 =3D 0xdfb97aa0 r5 =3D 0x00000013 >>> r6 =3D 0xdb43ab76 r7 =3D 0x00000001 >>> r8 =3D 0x00000001 r9 =3D 0xdfedd000 >>> r10 =3D 0xdb43ab76 >>> vpanic() at vpanic >>> pc =3D 0xc031a6f4 lr =3D 0xc06849dc (abort_align) >>> sp =3D 0xdfb979ac fp =3D 0xdfb979d8 >>> r4 =3D 0x00000001 r5 =3D 0x00000001 >>> r6 =3D 0xdfedd000 r7 =3D 0xdb43ab76 >>> r8 =3D 0xdfb979a4 r9 =3D 0xc031a6f4 >>> r10 =3D 0xdfb979ac >>> abort_align() at abort_align >>> pc =3D 0xc06849dc lr =3D 0xc0684a50 (abort_align+0x74) >>> sp =3D 0xdfb979e0 fp =3D 0xdfb979f8 >>> r4 =3D 0x00000013 r10 =3D 0xdb43ab76 >>> abort_align() at abort_align+0x74 >>> pc =3D 0xc0684a50 lr =3D 0xc06846a8 (abort_handler+0x45c) >>> sp =3D 0xdfb97a00 fp =3D 0xdfb97a98 >>> r4 =3D 0x00000000 r10 =3D 0xdb43ab76 >>> abort_handler() at abort_handler+0x45c >>> pc =3D 0xc06846a8 lr =3D 0xc0661cc8 (exception_exit) >>> sp =3D 0xdfb97aa0 fp =3D 0xdfb97b60 >>> r4 =3D 0x00000000 r5 =3D 0x00000000 >>> r6 =3D 0xdb43ab76 r7 =3D 0xdb43ab66 >>> r8 =3D 0xc096383c r9 =3D 0x00000000 >>> r10 =3D 0xdb132400 >>> exception_exit() at exception_exit >>> pc =3D 0xc0661cc8 lr =3D 0xc0b4e2c0 (__pcpu) >>> sp =3D 0xdfb97b30 fp =3D 0xdfb97b60 >>> r0 =3D 0xdfedd000 r1 =3D 0xdfb97b34 >>> r2 =3D 0x00000000 r3 =3D 0x00000000 >>> r4 =3D 0x00000000 r5 =3D 0x00000000 >>> r6 =3D 0xdb43ab76 r7 =3D 0xdb43ab66 >>> r8 =3D 0xc096383c r9 =3D 0x00000000 >>> r10 =3D 0xdb132400 r12 =3D 0x00000000 >>> in6ifa_ifwithaddr() at in6ifa_ifwithaddr+0x30 >>> pc =3D 0xc04e6b70 lr =3D 0xc04f9030 (ip6_input+0xd38) >>> sp =3D 0xdfb97b68 fp =3D 0xdfb97c28 >>> r4 =3D 0xdb43ab76 r5 =3D 0xdb43ab5e >>> r6 =3D 0x00000000 r7 =3D 0xdb43ab66 >>> ip6_input() at ip6_input+0xd38 >>> pc =3D 0xc04f9030 lr =3D 0xc046d66c = (netisr_dispatch_src+0xf8) >>> sp =3D 0xdfb97c30 fp =3D 0xdfb97c58 >>> r4 =3D 0xdb43ab00 r5 =3D 0x00000006 >>> r6 =3D 0x00000007 r7 =3D 0xc0b49d50 >>> r8 =3D 0xdafea0c0 r9 =3D 0xdb43ab00 >>> r10 =3D 0x00000086 >>> netisr_dispatch_src() at netisr_dispatch_src+0xf8 >>> pc =3D 0xc046d66c lr =3D 0xc04641b0 (ether_demux+0x18c) >>> sp =3D 0xdfb97c60 fp =3D 0xdfb97c78 >>> r4 =3D 0x00000006 r5 =3D 0x00001201 >>> r6 =3D 0xdb132400 r7 =3D 0x000000ff >>> r8 =3D 0xdafea0c0 r9 =3D 0xdb43ab00 >>> r10 =3D 0x00000086 >>> ether_demux() at ether_demux+0x18c >>> pc =3D 0xc04641b0 lr =3D 0xc0465880 (ether_nh_input+0x490) >>> sp =3D 0xdfb97c80 fp =3D 0xdfb97ce0 >>> r4 =3D 0xdb132400 r5 =3D 0xdb43ab00 >>> r6 =3D 0xdb43ab50 r10 =3D 0x00000086 >>> ether_nh_input() at ether_nh_input+0x490 >>> pc =3D 0xc0465880 lr =3D 0xc046d66c = (netisr_dispatch_src+0xf8) >>> sp =3D 0xdfb97ce8 fp =3D 0xdfb97d10 >>> r4 =3D 0xdb43ab00 r5 =3D 0x00000005 >>> r6 =3D 0x0000000c r7 =3D 0xc0b49d30 >>> r8 =3D 0xdafea0c0 r9 =3D 0xdb43ab00 >>> r10 =3D 0xc098d18f >>> netisr_dispatch_src() at netisr_dispatch_src+0xf8 >>> pc =3D 0xc046d66c lr =3D 0xc04645c4 (ether_input+0x50) >>> sp =3D 0xdfb97d18 fp =3D 0xdfb97d48 >>> r4 =3D 0xdb43ab00 r5 =3D 0x00000000 >>> r6 =3D 0x00008803 r7 =3D 0x00000000 >>> r8 =3D 0xdafea0c0 r9 =3D 0xdb43ab00 >>> r10 =3D 0xc098d18f >>> ether_input() at ether_input+0x50 >>> pc =3D 0xc04645c4 lr =3D 0xdffb3f08 ($a.10+0x108) >>> sp =3D 0xdfb97d50 fp =3D 0xdfb97d78 >>> r4 =3D 0xdb132400 r5 =3D 0xdaff8b00 >>> r6 =3D 0xdaff8b10 r7 =3D 0x00000000 >>> r8 =3D 0x00000000 r10 =3D 0xc098d18f >>> $a.10() at $a.10+0x108 >>> pc =3D 0xdffb3f08 lr =3D 0xc038cb2c = (taskqueue_run_locked+0x1c4) >>> sp =3D 0xdfb97d80 fp =3D 0xdfb97dd8 >>> r4 =3D 0xe0145100 r5 =3D 0xdaff8b2c >>> r6 =3D 0xe0145150 r7 =3D 0x00000001 >>> r8 =3D 0x00000000 r9 =3D 0xdfb97d90 >>> r10 =3D 0x00000001 >>> taskqueue_run_locked() at taskqueue_run_locked+0x1c4 >>> pc =3D 0xc038cb2c lr =3D 0xc038e4e4 = (taskqueue_thread_loop+0x1b0) >>> sp =3D 0xdfb97de0 fp =3D 0xdfb97e10 >>> r4 =3D 0xe0145100 r5 =3D 0xe0145140 >>> r6 =3D 0xc07af4c4 r7 =3D 0x00000000 >>> r8 =3D 0xc098d18f r9 =3D 0x00000100 >>> r10 =3D 0xc0b228a0 >>> taskqueue_thread_loop() at taskqueue_thread_loop+0x1b0 >>> pc =3D 0xc038e4e4 lr =3D 0xc02cdf0c (fork_exit+0xc0) >>> sp =3D 0xdfb97e18 fp =3D 0xdfb97e38 >>> r4 =3D 0xdfedd000 r5 =3D 0xc0b224e0 >>> r6 =3D 0xc038e334 r7 =3D 0xdffc4f54 >>> r8 =3D 0xdfb97e40 r9 =3D 0xc098d191 >>> fork_exit() at fork_exit+0xc0 >>> pc =3D 0xc02cdf0c lr =3D 0xc0661c5c (swi_exit) >>> sp =3D 0xdfb97e40 fp =3D 0x00000000 >>> r4 =3D 0xc038e334 r5 =3D 0xdffc4f54 >>> r6 =3D 0xc0b45d84 r7 =3D 0xd73bcba0 >>> r8 =3D 0x00000001 r10 =3D 0xc0b228a0 >>> swi_exit() at swi_exit >>> pc =3D 0xc0661c5c lr =3D 0xc0661c5c (swi_exit) >>> sp =3D 0xdfb97e40 fp =3D 0x00000000 >>> KDB: enter: panic >>> [ thread pid 0 tid 100230 ] >>>=20 >>> For reference: >>>=20 >>> # uname -apKU >>> FreeBSD OPiP2E-RPi2v1p1 14.0-CURRENT FreeBSD 14.0-CURRENT armv7 = 1400093 #6 main-n264334-215bab7924f6-dirty: Tue Jul 25 23:11:39 PDT 2023 = = root@CA72-16Gp-ZFS:/usr/obj/BUILDs/main-CA7-nodbg-clang/usr/main-src/arm.a= rmv7/sys/GENERIC-NODBG-CA7 arm armv7 1400093 1400093 >>>=20 >>> The OrangePi+ 2Ed was the type of system booted and tested. >>>=20 =3D=3D=3D Mark Millard marklmi at yahoo.com