From nobody Sun Aug 06 01:56:59 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 4RJMyr0N0mz4m9sQ for ; Sun, 6 Aug 2023 01:57:24 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-25.consmr.mail.gq1.yahoo.com (sonic311-25.consmr.mail.gq1.yahoo.com [98.137.65.206]) (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 4RJMyl5G9Cz4JG5 for ; Sun, 6 Aug 2023 01:57:19 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=ODojWmIW; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.206 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=1691287036; bh=K7SsTSsVvdglCJhARp7YmlL2STiKFUBRmSEp02kIARo=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=ODojWmIWdgKqQ5HeonG+GydxYINDFXLS5/Bmzk28CBbWkFiAKUPymf/2odKLnS1ebwVlOH9lhoEIKZmB2yNKFEz9eoUYrTdw8jL/FZ/15l9lnLenLKzBFrqoDALjTg/FDGMFfV2MPC4hcH72koLZ5Imbfds4lL5S+Xg0SgKPJPCHgldiL0wjvqiUlDJ8owfS5wXVsgLayDpfaX8s41CMk/uIm+hMAZMhSN5THLOuqH/tfFGYW7C8y2Am8cTMrbaatjn2IfAwXLBTfLcrQdSURbsHDNrdUczX9+M1t3YQFi5HiyF9IvRwdLq9LzobiSs3gvBw6Sqr9sl0pKfTnfFedg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1691287036; bh=mctKiwSVK9u/S9ZljigScmXPGW3gRBgHOV+6oDMLGUb=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=C6NFszJpv6QfcEvreD6HwlxU7diUMOl2mReBYGyOZ9eV/ORIj32azLjbDF8uIPL8U/A+wZuLwe+9a2BslnuA4EGc+sBGdZ+mxufKllavk1m1gkVnsH5HO6i0S9WuR7bQZioHiuTwC6zSgqaUG6oUKdYW4YSxBUaivauQvbeQh+7YphO2cD7dpmPqj3/XJPCTZ1UWtNJfktWE54tcFEsoUGVhSe5C3zS6WY5TksvsC/ZgX7hAlbXJUBixtm1nmsfUiTXCIUFs7Lb2vnDX2QX7utZsHJh+EfIfasqc0Nwm9J3xvsEzMo4PYIfZUUkeybwBu2ujzNo3DKz5bSypb4j2PA== X-YMail-OSG: iW1JtKgVM1mXyaNbqPph9Fexqxa5EZWvr.OGZOiT50sPYZWEEnCGJRazT6c_.s2 LdfRxR6BcWdavhrJlQKimYC.9duax_kHHDllsU3K5gpv9X.VttK3FyaYK.iK68yRMlLsQouXz0Z6 2cLWalNEGNtBexOUbF5P27Sk66bYWKTTeUeMXIGdN4RYD4.uJwMTuDkXmkAUNLtWha6dLXM.NVzy RkbaDC6OkVOtstZZnIb2fQhy6KZnMzLf._8RbaP.2sthqGxYxZQUyhQlprRR9TJ53Rs_k33IBGA6 3HIrssowG3f.fU58RvyhcFRyGbWJE1PEoi6r6w3graLLWY_3HtDRN.CAJjp70Hev6hPj5YKpC5jw hwnwTsDkgNYURp8pwpV_Zy5JbGUu20SekDkoNuc1_3.FjraMobOEImgWydBhdmwsXLw9s6z4YTNK 753F0aD2paRWhmWk1EKtSHZzwfzlESf0HrdzTwcsMRpfrdrG9RTmQAwdEU5MwMSkn90QG7JxWhCM hVOME5dM_NdfilDOJpGXxHDQN4m4CFdiu05jEaFBYgjdwNfebpEqwu7.A85AJjP8xSqrOuPSO.ea KtT7Cs8gGkGXuTIX1yf9ZmNCy5W56zDHb5ObIOgJccOUf.u9n4Gg3zb5L5gZPdnWpbIfmzwWDD3Q dNz7wXH0TmzTBAfiFtKEyCxmiI9QUcaA_C1N.zSymwAPQUM8WWY8tvFmDGYZZkOg04cCO3ZgHxM5 gtrd.QjLG1KNIHp5beD_qv9.B737AgVjvwmaUaVRpRqJ0W3N2L5c1I2JsrNuzHvzqPcsqeMVX9ea o.UagkyQvtBId_oDteMfej.h1FHZGYwD8aObboss6LHUAgdtQeeLLZAS_Q6lw_XktnpY6r2vEWSb iR7bmP8DIsED0OwUkHtOBp1b80XVbSrySjcIMlzeDQ8mcCoQhNqYbb3Um1zEu0kuXOK9JjCHicWw mrYUHzHShOD95x3gDmJ42OPUQNjkEaJHZCkxo8cXfsmWkv6vJmZCKtrHzR3zqlZaJxRcH7i_oXcJ geOIS0Uhfv.sFgzR4UoEmdfG1iO.j_i1b1XnHEez0GVj4.rJxKM0PwpKajcw15jt80VhPfHrvxKb dRSD00fjQVT7d04xasi5mWt9J59xl0bYhFV1G_iFu2_2sVONXabwDB72KDW.iCBfVBPbpnb7w6Dw W8ZWBc0Y65cJ6TzMpvnUJteUUFrnJVfTt46fhxmw7mX4Pra50ZsnsA50bErbqpeEgyc9Kcpib6xm eQ8k40m46xPb7VhyT7va5RjCec35PQazPL7vm9Lp7cQc6CgUcuO1yBoZfa7dsNs6Do9qrwNKN7Gx wXqzJGynTZzOfTDwCxLD3ZC4GR4PfZrq6CucaFXBuDdGZrVkoiXxwyewFNaSCVSJR65ikBwicADp 6vkEufehNdJXAGsoFlV5RYjJH8zYcFsXEaR0wfcFcMJPMYTInMfZ3L6r6dwejyGdhGOsQbF3TaR2 YtvkJTMRR4Zs2.yW62DUkJOGWb66Oz.Kdo0At1xyDfPy0xaneSoSoYxeeY_Uc42pyMVWh4FWhfnH EuYM3LZ10070Bf4PG8mEHJMg1WQQGhOnTRSJb85v1yHe662ZcVdq8R8DpqKsouXNtGbkuvEnatgT QrE6vSok.KbG3u6f5.y9f6oRc20NSP9gFDqXv3Ei0xQho3xJVK2EVU8KyVO5WNxKSlxLA5j.Cgpx mZiIa53cGqjKgVzMWGhJKRxVjQJCegPnJhg2tLB.dkC1InJ2VpZ48uxn4I1BmTdOtk2yVCBsW5jC nRx2nI9gc7rTzn9lY4NwFx7rjZehtrpSrj.EidnQUFVwdO70pNSWbpFfSU.hccNt0da7yiZmiGWa qH3MfG35YlKYmvuUGf0h_NONi4znK22GSr3bKF0IJlMPQVjijkrcFpqCY1ha6pRe66wHI2aE64qz 8VNWpXIJ8Ahd1iYmovoFslR8zKjXGQP3pVNNAe2Nd9LFaRhpU7_y1LBy7a1qgImtHp0tkImBB8hw IMYp59K3hKGDWH8bE8yWIih.NWHSMQI6txeDkIsMLoT6HqJal.5nBoEkOE8o_PXXSS5Xew2UKNB4 iLIR3zGfgEwBIcdD8eRFc8SCGDujOgCwRlzCIPgzrYS46U7gW8E0d.A.h0Sxbs.t7N8SPhgiehVW 8jGQyxXfA0ie9pj5i7qj7nH5_7.fcGwqJSzLvENH0kSUGgdgAjiM6jh_E.oMHnF9ZfZGsRevZxDS sNDWV..fHNMFraj8J7Fx62p12kkk4oqPgK_JUuqZ_srdEziC_hRs86OiehfTjdJ6e7DdUQ3CMPR4 - X-Sonic-MF: X-Sonic-ID: 4eb6b044-aea4-461f-8fcc-1e9acd1f6c8f Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Sun, 6 Aug 2023 01:57:16 +0000 Received: by hermes--production-ne1-549c7f6c44-9w7gj (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 80d85e8c78fb7a6a30138502f3ad336f; Sun, 06 Aug 2023 01:57:11 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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: I've shown the following 3 items via kyua testing with the latest snapshot of armv7 14 on a OrangePi+2Ed (Cortex-A7), a panic included Message-Id: Date: Sat, 5 Aug 2023 18:56:59 -0700 To: Mike Karels , FreeBSD ARM List , Current FreeBSD X-Mailer: Apple Mail (2.3731.700.6) References: X-Spamd-Result: default: False [-2.47 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.97)[-0.972]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.206:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.206:from]; DKIM_TRACE(0.00)[yahoo.com:+]; TO_DN_ALL(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MID_RHS_MATCH_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_COUNT_TWO(0.00)[2] X-Spamd-Bar: -- X-Rspamd-Queue-Id: 4RJMyl5G9Cz4JG5 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=3D00000001, FAR=3Dda87f00e, spsr=3D20000013 r0 =3D00000000, r1 =3D00000001, r2 =3D00000001, r3 =3D00000134 r4 =3D00000000, r5 =3D00000134, r6 =3Dda87f00e, r7 =3Dda87f022 r8 =3D00000134, r9 =3Dc0918b04, r10=3D00000014, r11=3De014ac28 r12=3D00000000, ssp=3De014ab90, slr=3Dc04534f4, pc =3Dc048b34c panic: Fatal abort cpuid =3D 1 time =3D 1691281420 KDB: stack backtrace: db_trace_self() at db_trace_self pc =3D 0xc05ecde4 lr =3D 0xc0079c70 = (db_trace_self_wrapper+0x30) sp =3D 0xe014a8b8 fp =3D 0xe014a9d0 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc =3D 0xc0079c70 lr =3D 0xc02e99a0 (vpanic+0x140) sp =3D 0xe014a9d8 fp =3D 0xe014a9f8 r4 =3D 0x00000100 r5 =3D 0x00000000 r6 =3D 0xc07597e2 r7 =3D 0xc0aeaec8 vpanic() at vpanic+0x140 pc =3D 0xc02e99a0 lr =3D 0xc02e9780 (doadump) sp =3D 0xe014aa00 fp =3D 0xe014aa04 r4 =3D 0xe014ab00 r5 =3D 0x00000013 r6 =3D 0xda87f00e r7 =3D 0x00000001 r8 =3D 0x00000001 r9 =3D 0xe0773ba0 r10 =3D 0xda87f00e doadump() at doadump pc =3D 0xc02e9780 lr =3D 0xc0611184 (abort_align) sp =3D 0xe014aa0c fp =3D 0xe014aa38 r4 =3D 0xda87f00e r5 =3D 0xe014aa04 r6 =3D 0xc02e9780 r10 =3D 0xe014aa0c abort_align() at abort_align pc =3D 0xc0611184 lr =3D 0xc06111f8 (abort_align+0x74) sp =3D 0xe014aa40 fp =3D 0xe014aa58 r4 =3D 0x00000013 r10 =3D 0xda87f00e abort_align() at abort_align+0x74 pc =3D 0xc06111f8 lr =3D 0xc0610e18 (abort_handler+0x498) sp =3D 0xe014aa60 fp =3D 0xe014aaf8 r4 =3D 0x00000000 r10 =3D 0xda87f00e abort_handler() at abort_handler+0x498 pc =3D 0xc0610e18 lr =3D 0xc05ef6ac (exception_exit) sp =3D 0xe014ab00 fp =3D 0xe014ac28 r4 =3D 0x00000000 r5 =3D 0x00000134 r6 =3D 0xda87f00e r7 =3D 0xda87f022 r8 =3D 0x00000134 r9 =3D 0xc0918b04 r10 =3D 0x00000014 exception_exit() at exception_exit pc =3D 0xc05ef6ac lr =3D 0xc04534f4 (ip_input+0x404) sp =3D 0xe014ab90 fp =3D 0xe014ac28 r0 =3D 0x00000000 r1 =3D 0x00000001 r2 =3D 0x00000001 r3 =3D 0x00000134 r4 =3D 0x00000000 r5 =3D 0x00000134 r6 =3D 0xda87f00e r7 =3D 0xda87f022 r8 =3D 0x00000134 r9 =3D 0xc0918b04 r10 =3D 0x00000014 r12 =3D 0x00000000 udp_input() at udp_input+0x1c0 pc =3D 0xc048b34c lr =3D 0xc04534f4 (ip_input+0x404) sp =3D 0xe014ac30 fp =3D 0xe014ac70 r4 =3D 0x00000001 r5 =3D 0x00000000 r6 =3D 0x00000000 r7 =3D 0x01000193 r8 =3D 0xda87f00e r9 =3D 0xc094a938 r10 =3D 0x00000014 ip_input() at ip_input+0x404 pc =3D 0xc04534f4 lr =3D 0xc04235bc = (netisr_dispatch_src+0x100) sp =3D 0xe014ac78 fp =3D 0xe014aca0 r4 =3D 0x00000004 r5 =3D 0xda854000 r6 =3D 0x00000000 r7 =3D 0xc0b5a2f8 r8 =3D 0x00000000 r9 =3D 0xc57f7780 r10 =3D 0x00000008 netisr_dispatch_src() at netisr_dispatch_src+0x100 pc =3D 0xc04235bc lr =3D 0xc041a384 (ether_demux+0x1bc) sp =3D 0xe014aca8 fp =3D 0xe014acc0 r4 =3D 0xda854000 r5 =3D 0x00000001 r6 =3D 0xdb846400 r7 =3D 0x5e4a6f28 r8 =3D 0x00000000 r9 =3D 0xc57f7780 r10 =3D 0x00000008 ether_demux() at ether_demux+0x1bc pc =3D 0xc041a384 lr =3D 0xc041bb68 (ether_nh_input+0x3dc) sp =3D 0xe014acc8 fp =3D 0xe014acf0 r4 =3D 0xdb846400 r5 =3D 0xda854000 r6 =3D 0xda87f000 r10 =3D 0x00000008 ether_nh_input() at ether_nh_input+0x3dc pc =3D 0xc041bb68 lr =3D 0xc04235bc = (netisr_dispatch_src+0x100) sp =3D 0xe014acf8 fp =3D 0xe014ad20 r4 =3D 0x00000006 r5 =3D 0xda854000 r6 =3D 0x00000000 r7 =3D 0xc0b5a378 r8 =3D 0x5e4a6f28 r9 =3D 0xc57f7780 r10 =3D 0x00000000 netisr_dispatch_src() at netisr_dispatch_src+0x100 pc =3D 0xc04235bc lr =3D 0xc041a808 (ether_input+0xec) sp =3D 0xe014ad28 fp =3D 0xe014ad60 r4 =3D 0xdb846400 r5 =3D 0x00000000 r6 =3D 0xda854000 r7 =3D 0x00000000 r8 =3D 0x5e4a6f28 r9 =3D 0xc57f7780 r10 =3D 0x00000000 ether_input() at ether_input+0xec pc =3D 0xc041a808 lr =3D 0xe098310c ($a.10+0xbc) sp =3D 0xe014ad68 fp =3D 0xe014ad90 r4 =3D 0xdb846400 r5 =3D 0xdb7bf8c0 r6 =3D 0x00000000 r7 =3D 0xda854000 r8 =3D 0xe09724d3 r9 =3D 0xdb7bf8d0 r10 =3D 0x00000000 $a.10() at $a.10+0xbc pc =3D 0xe098310c lr =3D 0xc03504dc = (taskqueue_run_locked+0xb8) sp =3D 0xe014ad98 fp =3D 0xe014ade0 r4 =3D 0xe0769e00 r5 =3D 0xe0769e50 r6 =3D 0xdb7bf8ec r7 =3D 0x00000001 r8 =3D 0x00000001 r9 =3D 0xc0768ff7 r10 =3D 0x00000000 taskqueue_run_locked() at taskqueue_run_locked+0xb8 pc =3D 0xc03504dc lr =3D 0xc0351560 = (taskqueue_thread_loop+0x108) sp =3D 0xe014ade8 fp =3D 0xe014ae18 r4 =3D 0x00000000 r5 =3D 0xe0769e00 r6 =3D 0xe0769e40 r7 =3D 0xc073cb53 r8 =3D 0xe0769e50 r9 =3D 0x00000100 r10 =3D 0xc0afde44 taskqueue_thread_loop() at taskqueue_thread_loop+0x108 pc =3D 0xc0351560 lr =3D 0xc02a384c (fork_exit+0xa0) sp =3D 0xe014ae20 fp =3D 0xe014ae38 r4 =3D 0xe0773ba0 r5 =3D 0xc0ada560 r6 =3D 0xc0351458 r7 =3D 0xe0993f94 r8 =3D 0xe014ae40 r9 =3D 0xc0afab7c fork_exit() at fork_exit+0xa0 pc =3D 0xc02a384c lr =3D 0xc05ef640 (swi_exit) sp =3D 0xe014ae40 fp =3D 0x00000000 r4 =3D 0xc0351458 r5 =3D 0xe0993f94 r6 =3D 0xc0942429 r7 =3D 0xc72f21d0 r8 =3D 0xc0ada900 r10 =3D 0xc0afde44 swi_exit() at swi_exit pc =3D 0xc05ef640 lr =3D 0xc05ef640 (swi_exit) sp =3D 0xe014ae40 fp =3D 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=3D5 # /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 = root@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 !=3D 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 !=3D 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: . /wrkdirs/usr/ports/devel/gdb/work-py39/gdb-13.1/gdb/thread.c:1337: = internal-error: switch_to_thread: Assertion `thr !=3D 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. =3D=3D=3D Mark Millard marklmi at yahoo.com