From nobody Fri Nov 08 03:15:18 2024 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 4Xl3wn6hzgz5bwvX for ; Fri, 08 Nov 2024 03:15:37 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-8.consmr.mail.gq1.yahoo.com (sonic315-8.consmr.mail.gq1.yahoo.com [98.137.65.32]) (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 4Xl3wm4hzvz4lNx for ; Fri, 8 Nov 2024 03:15:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=klW05NnE; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.32 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=1731035734; bh=4IVonQrmhQ4Iipd/TAerbhtoTEy/ta5awMv2GP7cFUs=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=klW05NnEJ+WLt9MAdo12Y2ha3JTIzbx0LKtyYUXOrp0+SS/W9RqVmzDpdS68d5wdlP1nzmjK9CcGyW7ZPjGucszW7BkO6B/NE4tLX5p0vKHbgkDOZyCXznndzr+eX5nnOR/AToPcvuAqVK+1ydTIuYW44JFsDlCRKKV2Nm1M0FTp7Rle1jO9/BV7/SF6bHB3sD27j2LUkbeI7alM9AOyVI3JT42Etueaz41Ha/4qAN/KpPIsQYfsRw/CR622c1ea7YR2qx0SNK7fXcRrp6jc8ge+FIsJgJ//p/9h1l3hpawO+V24eoTESEbG47y1teqOK2nnzJub8Fi8OMbAvLEl7w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1731035734; bh=vHaBVrtgYcX5VOu4w1m59Hz6+oyDiwt7locjRkvWxrW=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=j8HzTFpcyturxWTtCH26j6jmV5wY4kN/Zarvt/4hLaI8TuYu4Qs4I4f9dx78UzG6kju5+i2V4IFPF/IWYz/6oBlj/3+zQEx7Sn1L/vwRDaCZbHETAmYJZKq2Xuw0Ue07PYD/m1Qr+yMUsU81Pyu05GH+rzJYYJXvYMcLlEjXCzDwGYxKStQXaVblBA2ZBLkPdwUdb/ZTKpF/SOiBfB14yJTFlIcKzqtj/j8Fz7p4Uu+XjC26E1/GYu8VhxamjrOgIyU4LZmHm/aQA/9Djhe/chc0zN6I7Uvr/Gls1jmxyphCujv+E/6BF+UmF2PvYrw24hYpDb8yG2Dj9L4fIv57+A== X-YMail-OSG: WbrGo9EVM1lb5ABs6854WfstEI6uqCbz5JieN9Dc4rHtiEBk6Oz66LjmrzjKGfk _pzbsN8XawG6aMpB4nDHJzFMG5I.sCJQcja.eWMQrkJsKINTGdEDDTCZPCWgbgqu0oQWI73r2kLC vFLahp4KDWIdUrmvPQNclCIQTRg1cQQaxJYbCABrWs4VSu4ZBm.FZS.X1DzLxbaP5yhPkTivvBar M54DOPG_aXszJvw4aJ3zVAy8Fh2Qk87YYW0c28vwS9bEr6lbSPjkaF7kpjYvbPNxOuZuoNuOvoQt zAKVsI9fd6uqXXizgv08ctMkyeb.F0xCX1Ar8YHkt5ay18smQfq49fec9dNFoHxTXAClQVa_7Sti sPseRAVMh0QHq5anBjpWiIwHHi.tRcRRpi7Jq.rrLeW93XXQz.w8OP2jFcihA2S6icARpwtmn9vW qO7KnWUGow.QpBpO1qhzfzOY0zs8b7ohvwK55yQK8Ttom.5FfEHNICoEjBpuN_4vktyCYiQjq3uT eC9ozOkHXWqJkCJ6Iu92N0yNMzLk.9xJ4TKigRbOhk9TS9M849fa5GulXVZXAtqLZRbPMBXXPQ96 Oe_OKoVIZ.DGG3DZDhNR9VvMdz5CNnYNgO8oXJpuQRoyVgb6dyNF_8MTDwYIKDzEx_iZRGsdyd_E suPFFof6nSiU19i75r0r3cZfRrTFhBh7skHSx6lREFKZSaX__2x9Qpio1Ny2PMszDqWp.3BeJjTg 2XzbYzBnwyNCrW_A5oHl6ydGSlK6EC4Xv7DuxLAud2BJTLtcYX.ZTgo6FmdVzuWHKUm4lNNdyEh9 dlc0Q_sbbhscUxT7FarONRXQETlqo_iFcmrxSmVIBg8scXCOCrOW40Yv11SQjk2CQLiZ_Xdyj_sK gyrOhMl66UTx5mNkhmePN7l2gA562C8Nl_mzAwM89rwqDVMUyDxY7EQW82r3XW2MAqjA3rcUEigl bLYNWfnfiM4dlIo4honIABaR5lFzJIWbU6aZRfNSPZd7CyAefGizW8lDPClfzSmyDMoUMcJC2S6E Xkomf.KDoiQIF2toI7Fei8hTaLpib7AuURFFaeCY0awRsMTehqxT80FM90DSPlccOrJQvoLxdcox m7q1CKefHWl9YK.808JPYCrLDf7D2dZWXzTBAADVltfHAOE6LqHEKwKZrU0vesT5enwGGLlJ_8QB mi5c_41EQYZNWIS3PjwW8xOM3on4Y1TjkTG3JU_npc1zzEg6gikE6WxYq.e5CDAvzY52RWWIXNwH x_vZyr2OXjAazj0heuxyuZtjm_33W3uW2jdDIiKXFIpEpXgnyWicm66df0SOCyihAC7G1axtmoRH 5Dn34YNJn8F8I6n43_.bN45M701spS_P5L57IPBlper53Fr6zuHx5X_s3_..AQZqhu9bKY2Xwlds cGOMyYIZ6PLHe5PF_XhxN5oWykFYAt62Jfpn95U7NOepiznNjamxVUELmN3I0gBg5iSt7km.U3tB 1f0vxBjDskCM94n434rxD7p1aHgdd__9P6RXWfFAGEL481BqkgSEQHCmV0HTHcYB.jRIdOuiMb9w CmY904eVi_gb_7ER37Hku.Y6QhOzjXxz8jN_qZ7GKX9OB20bOhdU19BtQAm4LT0xEWE_tp0yIJfP PYAuADPLSpBBY62gO2Kau0wWcsX3Fa7uZ1_3rpJTxhaMhct46iGCt3RRMEcVZbQsq1aQsnnn5Ln0 D2w1VuNOIFt8LTz6oPA5Ui8HIpOrW0vgX6Hjvr8ImjNBQQxUUp5AZ8C16yqYxF2E4pbFqLO2_epP HGCJUuiYwiOtjL194gWI0dqjSExU_3kA.FJid3Od5R2U2cxrCe6mNRBacjjJMospADbM2ullzOB2 axdlIpjMNJVURrOibozCNaMoGFxzjMMC5j1K5iSducBqmNWwlkhSlnj8fTwhfRBi8lkGufjOK60L ie1ZeNlYoumgjFWQfea6WMyI.3drR1yW17SE5Cg7r2N8h4WGrES7EE3aIhF.ud4z8TyW8WqndPX8 x1K2Dj7Hz5OA6.DwA4HkQMNlG.Hem3hAa.5UVBNGnCIDqJcq.jcNrdCO1Rp0VF_Iz4YSiGwnZjwU Qyn.a0p1CcyZPiqG7Z_sc5XPSO7TPFTF6WxUxBox_wPvOyDXikbc1Lb0CDBZHVEf2Eh.mmqx48bv 7thuxx7FrCHpM0qKcSFRf7K6N18RVbav.cwNtBzS59uGlondjxdjZiYzoVw9845w0JDIwuAmmxyX MBz_Tv0R9352oQ1m4T_yrmmQG14729ddRqIjMyUsSJIvPf2qaNgnw5xSp9CiZfZmzGksuJ5Ak2Jm _q80jrLOnZKjejUDE X-Sonic-MF: X-Sonic-ID: 2f6959b0-4c57-41fd-9672-c5071359c1f1 Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Fri, 8 Nov 2024 03:15:34 +0000 Received: by hermes--production-gq1-5dd4b47f46-n48bg (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID b082948f48ce2adb44549802e6fb55f7; Fri, 08 Nov 2024 03:15:29 +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 \(3776.700.51\)) Subject: Re: Official armv7 PkgBase kernel-NODEBUG installation's USB2 boot gets "Fatal kernel mode data abort: 'Alignment Fault' on write" very early, at least on an OrangePi+ 2ed From: Mark Millard In-Reply-To: <74468E62-5A74-4FB4-94F6-599E5BA3A9A1@yahoo.com> Date: Thu, 7 Nov 2024 19:15:18 -0800 Cc: Dimitry Andric , "dougm@freebsd.org" , Kyle Evans Content-Transfer-Encoding: quoted-printable Message-Id: References: <74468E62-5A74-4FB4-94F6-599E5BA3A9A1@yahoo.com> To: FreeBSD ARM List , Current FreeBSD , FreeBSD Toolchain X-Mailer: Apple Mail (2.3776.700.51) X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_DN_EQ_ADDR_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.32:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.32:from]; RCPT_COUNT_FIVE(0.00)[6] X-Rspamd-Queue-Id: 4Xl3wm4hzvz4lNx X-Spamd-Bar: --- [I narrowed the artifact kernel range for the change in the type of failure that happens.] On Nov 7, 2024, at 17:43, Mark Millard wrote: > [The change to LLVM 19 is what leads to the Alignment > Fault' on write failure. Details later below.] >=20 > On Nov 7, 2024, at 01:42, Mark Millard wrote: >=20 >> Note: Unfortunately, the panics here are too early for a >> dump device to be available. >>=20 >> Context started PkgBase upgrade from: >>=20 >> # uname -apKU >> FreeBSD OPiP2E-RPi2v1p1 15.0-CURRENT FreeBSD 15.0-CURRENT = main-n272821-37798b1d5dd1 GENERIC-NODEBUG arm armv7 1500025 1500025 >>=20 >> Installed packages to be UPGRADED: >> FreeBSD-dtb: 15.snap20241009161500 -> 15.snap20241028121139 = [base] >> FreeBSD-kernel-generic: 15.snap20241011221604 -> = 15.snap20241106134422 [base] >> FreeBSD-kernel-generic-dbg: 15.snap20241011221604 -> = 15.snap20241106134422 [base] >> FreeBSD-kernel-generic-mmccam: 15.snap20241011221604 -> = 15.snap20241106134422 [base] >> FreeBSD-kernel-generic-mmccam-dbg: 15.snap20241011221604 -> = 15.snap20241106134422 [base] >> FreeBSD-kernel-generic-nodebug: 15.snap20241011221604 -> = 15.snap20241106134422 [base] >> FreeBSD-kernel-generic-nodebug-dbg: 15.snap20241011221604 -> = 15.snap20241106134422 [base] >> FreeBSD-src-sys: 15.snap20241011221604 -> 15.snap20241106160110 = [base] >>=20 >> (Those were installed but the FreeBSD-dtb had linux 6.4 >> dtb files, not the 6.8 ones. 6.8 ones from a personal build >> were copied to where they need to be. I've separately >> reported the 6.4 vs. 6.8 issue.) >>=20 >> # ~/pkgbase-snapshot-list.sh >> Via pkg-static info -C -x '^FreeBSD-' . . . >> 1 FreeBSD-*-15.snap20241106160110 >> 6 FreeBSD-*-15.snap20241106134422 >> 1 FreeBSD-*-15.snap20241028121139 >> 3 FreeBSD-*-15.snap20241011221604 >> 2 FreeBSD-*-15.snap20241011210446 >> 38 FreeBSD-*-15.snap20241011182434 >> 4 FreeBSD-*-15.snap20241011073851 >> 5 FreeBSD-*-15.snap20241010141501 >> 1 FreeBSD-*-15.snap20241010120743 >> 296 FreeBSD-*-15.snap20241009161500 >> Instead via /var/cache/pkg/*.snap*.pkg . . . >> 1 FreeBSD-*-15.snap20241106160110 >> 6 FreeBSD-*-15.snap20241106134422 >> 1 FreeBSD-*-15.snap20241028121139 >> 10 FreeBSD-*-15.snap20241011221604 >> 2 FreeBSD-*-15.snap20241011210446 >> 38 FreeBSD-*-15.snap20241011182434 >> 4 FreeBSD-*-15.snap20241011073851 >> 5 FreeBSD-*-15.snap20241010141501 >> 1 FreeBSD-*-15.snap20241010120743 >> 297 FreeBSD-*-15.snap20241009161500 >>=20 >>=20 >> The failure (kernel-GENERIC-NODEBUG): >>=20 >> . . . >> Root mount waiting for: usbus3 CAM >> Fatal kernel mode data abort: 'Alignment Fault' on write >> trapframe: 0xc6c9ac10 >> FSR=3D00000801, FAR=3Ddb23209b, spsr=3D20000013 >> r0 =3Ddb232080, r1 =3D00000000, r2 =3D00000006, r3 =3D00000024 >> r4 =3Ddb19e280, r5 =3D00000000, r6 =3D00000001, r7 =3D00000006 >> r8 =3Dc6c9ad20, r9 =3Dc0b7973c, r10=3Dc092074c, r11=3Dc6c9acb8 >> r12=3D00000000, ssp=3Dc6c9aca0, slr=3Dc01b01d8, pc =3Dc01aff88 >>=20 >> panic: Fatal abort >> cpuid =3D 1 >> time =3D 3 >> KDB: stack backtrace: >> db_trace_self() at db_trace_self >> pc =3D 0xc0667004 lr =3D 0xc0078630 = (db_trace_self_wrapper+0x30) >> sp =3D 0xc6c9a9c8 fp =3D 0xc6c9aae0 >> db_trace_self_wrapper() at db_trace_self_wrapper+0x30 >> pc =3D 0xc0078630 lr =3D 0xc0328db8 (vpanic+0x140) >> sp =3D 0xc6c9aae8 fp =3D 0xc6c9ab08 >> r4 =3D 0x00000100 r5 =3D 0x00000000 >> r6 =3D 0xc084d1f1 r7 =3D 0xc0b69a94 >> vpanic() at vpanic+0x140 >> pc =3D 0xc0328db8 lr =3D 0xc0328c78 (vpanic) >> sp =3D 0xc6c9ab10 fp =3D 0xc6c9ab14 >> r4 =3D 0xc6c9ac10 r5 =3D 0x00000013 >> r6 =3D 0xdb23209b r7 =3D 0x00000001 >> r8 =3D 0x00000801 r9 =3D 0x00000013 >> r10 =3D 0xdb23209b >> vpanic() at vpanic >> pc =3D 0xc0328c78 lr =3D 0xc068c8e8 (abort_align) >> sp =3D 0xc6c9ab1c fp =3D 0xc6c9ab48 >> r4 =3D 0x00000001 r5 =3D 0x00000801 >> r6 =3D 0x00000013 r7 =3D 0xdb23209b >> r8 =3D 0xc6c9ab14 r9 =3D 0xc0328c78 >> r10 =3D 0xc6c9ab1c >> abort_align() at abort_align >> pc =3D 0xc068c8e8 lr =3D 0xc068c958 (abort_align+0x70) >> sp =3D 0xc6c9ab50 fp =3D 0xc6c9ab68 >> r4 =3D 0xc6d21c00 r10 =3D 0xdb23209b >> abort_align() at abort_align+0x70 >> pc =3D 0xc068c958 lr =3D 0xc068c5e0 (abort_handler+0x430) >> sp =3D 0xc6c9ab70 fp =3D 0xc6c9ac08 >> r4 =3D 0x00000000 r10 =3D 0xdb23209b >> abort_handler() at abort_handler+0x430 >> pc =3D 0xc068c5e0 lr =3D 0xc0669868 (exception_exit) >> sp =3D 0xc6c9ac10 fp =3D 0xc6c9acb8 >> r4 =3D 0xdb19e280 r5 =3D 0x00000000 >> r6 =3D 0x00000001 r7 =3D 0x00000006 >> r8 =3D 0xc6c9ad20 r9 =3D 0xc0b7973c >> r10 =3D 0xc092074c >> exception_exit() at exception_exit >> pc =3D 0xc0669868 lr =3D 0xc01b01d8 (usb_msc_auto_quirk+0xfc) >> sp =3D 0xc6c9aca0 fp =3D 0xc6c9acb8 >> r0 =3D 0xdb232080 r1 =3D 0x00000000 >> r2 =3D 0x00000006 r3 =3D 0x00000024 >> r4 =3D 0xdb19e280 r5 =3D 0x00000000 >> r6 =3D 0x00000001 r7 =3D 0x00000006 >> r8 =3D 0xc6c9ad20 r9 =3D 0xc0b7973c >> r10 =3D 0xc092074c r12 =3D 0x00000000 >> bbb_command_start() at bbb_command_start+0x4c >> pc =3D 0xc01aff88 lr =3D 0xc01b01d8 (usb_msc_auto_quirk+0xfc) >> sp =3D 0xc6c9acc0 fp =3D 0xc6c9acf8 >> r4 =3D 0xdb16d800 r5 =3D 0xdb19e280 >> r6 =3D 0x00000001 r10 =3D 0xc092074c >> usb_msc_auto_quirk() at usb_msc_auto_quirk+0xfc >> pc =3D 0xc01b01d8 lr =3D 0xc01a4bd8 (usb_alloc_device+0x9c4) >> sp =3D 0xc6c9ad00 fp =3D 0xc6c9ad68 >> r4 =3D 0x00000000 r5 =3D 0x00000001 >> r6 =3D 0x00000000 r7 =3D 0x00000002 >> r8 =3D 0xdb16d800 r9 =3D 0xda241c78 >> r10 =3D 0x000003ee >> usb_alloc_device() at usb_alloc_device+0x9c4 >> pc =3D 0xc01a4bd8 lr =3D 0xc01ad16c (uhub_explore+0x494) >> sp =3D 0xc6c9ad70 fp =3D 0xc6c9adc0 >> r4 =3D 0x00000000 r5 =3D 0x00000000 >> r6 =3D 0xdb16e800 r7 =3D 0x00000000 >> r8 =3D 0xdb18c200 r9 =3D 0x00000001 >> r10 =3D 0x00000000 >> uhub_explore() at uhub_explore+0x494 >> pc =3D 0xc01ad16c lr =3D 0xc0198654 (usb_bus_explore+0x1d4) >> sp =3D 0xc6c9adc8 fp =3D 0xc6c9add8 >> r4 =3D 0xda241c78 r5 =3D 0xdb16e800 >> r6 =3D 0x00000000 r7 =3D 0xda241d6c >> r8 =3D 0xc09b0b5f r9 =3D 0x00000001 >> r10 =3D 0xda241d1c >> usb_bus_explore() at usb_bus_explore+0x1d4 >> pc =3D 0xc0198654 lr =3D 0xc01b22d0 (usb_process+0x124) >> sp =3D 0xc6c9ade0 fp =3D 0xc6c9ae10 >> r4 =3D 0xda241d0c r5 =3D 0xda241d14 >> usb_process() at usb_process+0x124 >> pc =3D 0xc01b22d0 lr =3D 0xc02da4f0 (fork_exit+0xb0) >> sp =3D 0xc6c9ae18 fp =3D 0xc6c9ae38 >> r4 =3D 0xc6c9ae40 r5 =3D 0xc6d21c00 >> r6 =3D 0xc6d08740 r7 =3D 0xda241d0c >> r8 =3D 0xc01b21ac r9 =3D 0x00000000 >> r10 =3D 0x00000000 >> fork_exit() at fork_exit+0xb0 >> pc =3D 0xc02da4f0 lr =3D 0xc06697fc (swi_exit) >> sp =3D 0xc6c9ae40 fp =3D 0x00000000 >> r4 =3D 0xc01b21ac r5 =3D 0xda241d0c >> r6 =3D 0x00000000 r7 =3D 0x00000000 >> r8 =3D 0x00000000 r10 =3D 0x00000000 >> swi_exit() at swi_exit >> pc =3D 0xc06697fc lr =3D 0xc06697fc (swi_exit) >> sp =3D 0xc6c9ae40 fp =3D 0x00000000 >> KDB: enter: panic >> [ thread pid 14 tid 100069 ] >> Stopped at kdb_enter+0x54: ldrb r15, [r15, r15, ror r15]! >> db> >=20 > Using just available official artifact kernels for testing > I've established that 0953460ce149 (and various from before > that) does not have the problem:=20 >=20 > Wed, 23 Oct 2024 > =E2=80=A2 git: 5c92f84bb607 - main - LinuxKPI: update = rcu_dereference_*() and lockdep_is_held() Bjoern A. Zeeb > =E2=80=A2 git: 6fa91acca40d - main - conf/NOTES: Remove trailing = whitespace Li-Wen Hsu=20 > =E2=80=A2 git: 91b7b225b2ce - main - LINT: Add mac_do Li-Wen Hsu=20 > =E2=80=A2 git: 419249c1cacc - main - Revert "LINT: Add mac_do" = Li-Wen Hsu=20 > =E2=80=A2 Re: git: 419249c1cacc - main - Revert "LINT: Add mac_do" = Baptiste Daroussin=20 > =E2=80=A2 Re: git: 13da1af1cd67 - main - libcxxrt: Update to = upstream 698997bfde1f John Baldwin=20 > =E2=80=A2 Re: git: 419249c1cacc - main - Revert "LINT: Add mac_do" = John Baldwin=20 > =E2=80=A2 git: 0953460ce149 - main - libc: fix access mode tests in = fmemopen(3) Ed Maste >=20 > So the above one worked. >=20 > The next available kernel to test was f3dbef108212 (the bump for = LLVM19 > at the end of the below): >=20 > =E2=80=A2 RE: git: 6a07e67fb7a8 - main - vm_meter: Fix laundry = accounting Mark Millard=20 > =E2=80=A2 git: 6b9f7133aba4 - main - libc: Add one more check in = new fmemopen test Ed Maste=20 > =E2=80=A2 git: 0fca6ea1d4ee - main - Merge llvm-project main = llvmorg-19-init-18630-gf2ccf80136a0 Dimitry Andric=20 > =E2=80=A2 git: 36b606ae6aa4 - main - Merge llvm-project = release/19.x llvmorg-19.1.0-rc1-0-ga4902a36d5c2 Dimitry Andric=20 > =E2=80=A2 git: 3f157662c0ef - main - Tentatively apply = https://github.com/llvm/llvm-project/pull/101403 Dimitry Andric=20 > =E2=80=A2 git: d575077527d4 - main - bsd.sys.mk: for clang >=3D 19, = similar to gcc >=3D 8.1, turn off -Werror for = -Wcast-function-type-mismatch. Dimitry Andric=20 > =E2=80=A2 git: 36d486cc2ecd - main - Fix enum warning in ath_hal's = ar9002 Dimitry Andric=20 > =E2=80=A2 git: 6846ab2fb663 - main - libcxx simd_utils.h: only = enable _LIBCPP_HAS_ALGORITHM_VECTOR_UTILS for clang >=3D 15, since older = versions do not support the required builtins. Dimitry Andric=20 > =E2=80=A2 git: 81e300df5e65 - main - libcxx atomic_ref.h: add = typename keyword for difference_type declarations, otherwise older clang = versions cannot compile this header. Dimitry Andric=20 > =E2=80=A2 git: 6b4981df6008 - main - libcxx cstdlib, cwchar: avoid = using long long functions if not supported, even for older compilers = that do not support the using_if_exists attribute. Dimitry Andric=20 > =E2=80=A2 git: 2f6d6eaf2d51 - main - libcxx-compat: revert = llvmorg-19-init-18063-g561246e90282: Dimitry Andric=20 > =E2=80=A2 git: 04f5b79cfa49 - main - libcxx-compat: revert = llvmorg-19-init-18062-g4dfa75c663e5: Dimitry Andric=20 > =E2=80=A2 git: e8054e44f4ca - main - libcxx-compat: revert = llvmorg-19-init-17853-g578c6191eff7: Dimitry Andric=20 > =E2=80=A2 git: 0bec0529b1d7 - main - libcxx-compat: revert = llvmorg-19-init-17728-g30cc12cd818d: Dimitry Andric=20 > =E2=80=A2 git: e8847079df1b - main - libcxx-compat: revert = llvmorg-19-init-17727-g0eebb48fcfbc: Dimitry Andric=20 > =E2=80=A2 git: 2f2ebe758bea - main - libcxx-compat: revert = llvmorg-19-init-17473-g69fecaa1a455: Dimitry Andric=20 > =E2=80=A2 git: 1199d38d8ec7 - main - libcxx-compat: revert = llvmorg-19-init-8667-g472b612ccbed: Dimitry Andric=20 > =E2=80=A2 git: a7b2d7f261b8 - main - libcxx-compat: revert = llvmorg-19-init-5639-ga10aa4485e83: Dimitry Andric=20 > =E2=80=A2 git: f3859a1a13a1 - main - libcxx-compat: revert = llvmorg-19-init-4504-g937a5396cf3e: Dimitry Andric=20 > =E2=80=A2 git: 072b5fb698ab - main - libcxx-compat: revert = llvmorg-19-init-4003-g55357160d0e1: Dimitry Andric=20 > =E2=80=A2 git: b60301d8b594 - main - libcxx-compat: don't remove = headers that were reintroduced by reverts Dimitry Andric=20 > =E2=80=A2 git: 2e861daab905 - main - libcxx-compat: install headers = that were reintroduced by reverts Dimitry Andric=20 > =E2=80=A2 git: ff6c8447844b - main - libcxx-compat: update = libcxx.imp for headers that were reintroduced by reverts Dimitry Andric=20= > =E2=80=A2 git: 52418fc2be8e - main - Merge llvm-project = release/19.x llvmorg-19.1.0-rc2-0-gd033ae172d1c Dimitry Andric=20 > =E2=80=A2 git: 62987288060f - main - Merge llvm-project = release/19.x llvmorg-19.1.0-rc3-0-g437434df21d8 Dimitry Andric=20 > =E2=80=A2 git: 6c4b055cfb6b - main - Merge llvm-project = release/19.x llvmorg-19.1.0-rc4-0-g0c641568515a Dimitry Andric=20 > =E2=80=A2 git: 835c3a3e69af - main - Merge commit 6dbdb8430b49 from = llvm git (by Nikolas Klauser): Dimitry Andric=20 > =E2=80=A2 git: c80e69b00d97 - main - Merge llvm-project = release/19.x llvmorg-19.1.0-0-ga4bf6cd7cfb1 Dimitry Andric=20 > =E2=80=A2 git: 6e516c87b6d7 - main - Merge llvm-project = release/19.x llvmorg-19.1.1-0-gd401987fe349 Dimitry Andric=20 > =E2=80=A2 git: 5deeebd8c6ca - main - Merge llvm-project = release/19.x llvmorg-19.1.2-0-g7ba7d8e2f7b6 Dimitry Andric=20 > =E2=80=A2 git: f3dbef108212 - main - Bump __FreeBSD_version for = llvm 19.1.2 merge Dimitry Andric=20 >=20 > f3dbef108212 gets the: >=20 > "Fatal kernel mode data abort: 'Alignment Fault' on write" >=20 > boot failure for artifact kernel. 6b9f7133aba4 does nit > seem a likely source of the problem, basically leaving the > LLVM changes as what is at issue. >=20 > I'll note that artifact kernels are witness kernels. So > this exploration adds to the distinctions observed > compared to the prior notes. >=20 >> Looking at bbb_command_start() 's pc: >>=20 >> # llvm-addr2line -e /boot/kernel.GENERIC-NODEBUG/kernel 0xc01aff88 >> /home/pkgbuild/worktrees/main/sys/dev/usb/usb_msctest.c:554 >>=20 >> What leads to that line is: >>=20 >> = /*------------------------------------------------------------------------= * >> * bbb_command_start - execute a SCSI command synchronously =20 >> * =20 >> * Return values >> * 0: Success >> * Else: Failure >> = *------------------------------------------------------------------------*= / >> static int >> bbb_command_start(struct bbb_transfer *sc, uint8_t dir, uint8_t lun, = =20 >> void *data_ptr, size_t data_len, void *cmd_ptr, size_t cmd_len, >> usb_timeout_t data_timeout) >> { >> sc->lun =3D lun; >> sc->dir =3D data_len ? dir : DIR_NONE; >> sc->data_ptr =3D data_ptr; >> sc->data_len =3D data_len; >> sc->data_rem =3D data_len; >> sc->data_timeout =3D (data_timeout + USB_MS_HZ); >> sc->actlen =3D 0; >> sc->error =3D 0; >> sc->cmd_len =3D cmd_len; >> memset(&sc->cbw->CBWCDB, 0, sizeof(sc->cbw->CBWCDB)); >>=20 >> The memset line is line 554 of sys/dev/usb/usb_msctest.c . >=20 > The below looks to be a separate problem based on > some later FreeBSD kernel update than the above. >=20 >> I'll note that attempting to use the WITNESS variant of the kernel >> ( /boot/kernel/ ) gets a different, even earlier failure: >>=20 >> . . . >> VT: init without driver. >> panic: acquiring blockable sleep lock with spinlock or critical = section held (sleep mutex) pmap @ = /home/pkgbuild/worktrees/main/sys/arm/arm/pmap-v6.c:6455 >=20 > I do know that d021d3b3c675 at the end of the below > shows this failure --before the system has a chance > to get the usb related write alignment failure > reported above. >=20 > I have not explored where in the below range the > behavior changes (for what is available as an > official artifact kernel). It seems unlikely that > any of the below would actually boot: it is likely > a question of which of the 2 (or more) failure > types happen for each instead. The last before "Thu, 24, Oct 2024" was: =E2=80=A2 git: 8b2e7da70855 - main - llvm19: permit incremental = builds from llvm18 Brooks Davis=20 That is the last available artifact kernel that gets the original usb related write alignment type of failure. > Thu, 24 Oct 2024 > =E2=80=A2 git: 34951b0b9e78 - main - swap_pager: move = scan_all_shadowed, use iterators Doug Moore=20 > =E2=80=A2 git: 2ac21f2c98ed - main - x86 specialreg.h: visually = align %cr4 and MSR_EFER bit mask definitions Konstantin Belousov=20 > =E2=80=A2 git: cc11bc1150d5 - main - x86 specialreg.h: add all = defined bits for %cr4 Konstantin Belousov=20 > =E2=80=A2 git: cc4b25f10211 - main - x86 specialreg: reorder %cr3 = bits masks definitions by value Konstantin Belousov=20 > =E2=80=A2 git: 5999b74e9637 - main - x86 specialreg: add bit masks = definitions for LAM in %cr3 Konstantin Belousov=20 > =E2=80=A2 git: 6308db659f2a - main - x86 specialreg: add bit masks = definitions for EFER features Konstantin Belousov=20 > =E2=80=A2 git: 9f718b57b846 - main - x86 specialreg: add bit masks = definitions for LASS and LAM features Konstantin Belousov=20 > =E2=80=A2 git: 3360a15898ce - main - net: route: convert routing = statistics to a sysctl Kyle Evans=20 > =E2=80=A2 Re: git: 3360a15898ce - main - net: route: convert = routing statistics to a sysctl Kyle Evans=20 > =E2=80=A2 git: 77b70ad751df - main - e1000: Move I219 LM19/V19 to = ADL Kevin Bowling The last above is the first available artifact kernel that that gets the different error. There are no armv7 artifact kernels between 8b2e7da70855 and 77b70ad751df . So something from 34951b0b9e78 .. 77b70ad751df leads to the change in the type of failure. I've no clue what. It looked to me like the x86 commits and e1000 commit had no chance of contributing to the armv7 context. Thus who I added to the CC vs. did not add. > =E2=80=A2 git: d64442a89896 - main - arm{,64}: use genassym for = INTR_ROOT_* values Kyle Evans=20 > =E2=80=A2 git: 536c8d948e85 - main - intrng: change multi-interrupt = root support type to enum Kyle Evans=20 > =E2=80=A2 git: 4f12b529f404 - main - sys/intr.h: formally depend on = machine/intr.h Kyle Evans=20 > =E2=80=A2 git: a5b1eecbed07 - main - Apply workaround for building = llvm-project with WITHOUT_LLVM_ASSERTIONS Dimitry Andric=20 > =E2=80=A2 git: 1c83996beda7 - main - Adjust = LLVM_ENABLE_ABI_BREAKING_CHECKS depending on NDEBUG Dimitry Andric=20 > =E2=80=A2 git: b2dd4970c7b5 - main - dev/gpio: Mask all pl011 = interrupts Andrew Turner=20 > =E2=80=A2 git: 3b03e1bb8615 - main - intrng: Store the IPI priority = Andrew Turner=20 > =E2=80=A2 git: 6204391e99ca - main - arm64: Check TDP_NOFAULTING in = a data abort Andrew Turner=20 > =E2=80=A2 git: a84653c5db25 - main - arm64: Don't enable interrupts = when in a spinlock Andrew Turner=20 > =E2=80=A2 git: d7f930b80e89 - main - arm64: Implement = efi_rt_arch_call Andrew Turner=20 > =E2=80=A2 git: 8efb1500d4f1 - main - arm64: Enable handling EFI = runtime service faults Andrew Turner=20 > =E2=80=A2 git: 9693241188aa - main - sound: Call DSP_REGISTERED = before PCM_DETACHING Christos Margiolis=20 > =E2=80=A2 git: bb5e3ac1a7b7 - main - sound: Use DSP_REGISTERED in = dsp_clone() Christos Margiolis=20 > =E2=80=A2 git: a4111e9dc722 - main - sound: Change PCMDIR_* = numbering Christos Margiolis=20 > =E2=80=A2 git: 802c78f5194e - main - sound: Untangle dsp_cdevs[] = and dsp_unit2name() confusion Christos Margiolis=20 > =E2=80=A2 git: b1bb6934bb87 - main - sound: Fix build error in = chm_mkname() KASSERT Christos Margiolis=20 > =E2=80=A2 git: ce20b48a60fb - main - sctp: improve debug output = Michael Tuexen=20 > =E2=80=A2 git: e4ac0183a1a8 - main - sctp: cleanup Michael Tuexen=20= > =E2=80=A2 git: 8c8ebbb04518 - main - bhyve ahci: Improve robustness = of TRIM handling John Baldwin=20 > =E2=80=A2 git: f0bc751d6fb4 - main - csa: Use pci_find_device to = simplify clkrun_hack John Baldwin=20 > =E2=80=A2 git: d96ba5a62365 - main - config: Remove a stray = semicolon Zhenlei Huang=20 > =E2=80=A2 git: 56b17de1e836 - main - makefs: Remove a stray = semicolon Zhenlei Huang=20 > =E2=80=A2 git: 88b71d1fe054 - main - arm64: rockchip: Remove a = stray semicolon Zhenlei Huang=20 > =E2=80=A2 git: b4856b8e9d87 - main - LinuxKPI: Remove stray = semicolons Zhenlei Huang=20 > =E2=80=A2 git: 75ff90814aec - main - enic: Remove a stray semicolon = Zhenlei Huang=20 > =E2=80=A2 git: 6ccf4f4071c5 - main - mana: Remove stray semicolons = Zhenlei Huang=20 > =E2=80=A2 git: 86a2c910c05c - main - mpi3mr: Remove a stray = semicolon Zhenlei Huang=20 > =E2=80=A2 git: 36756195a342 - main - ocs_fc: Remove a stray = semicolon Zhenlei Huang=20 > =E2=80=A2 git: 2f395cfda8b5 - main - tcp cc: Remove a stray = semicolon Zhenlei Huang=20 > =E2=80=A2 git: f3a097d0312c - main - netstat: switch to using the = sysctl-exported stats for live stats Kyle Evans=20 > =E2=80=A2 git: 656991b0c629 - main - locks: augment lock_class with = lc_trylock method Gleb Smirnoff=20 > =E2=80=A2 git: efcb2ec8cb81 - main - callout: provide = CALLOUT_TRYLOCK flag Gleb Smirnoff=20 > =E2=80=A2 git: bffebc336f4e - main - tcp: use CALLOUT_TRYLOCK for = the TCP callout Gleb Smirnoff=20 > =E2=80=A2 git: d021d3b3c675 - main - tcp: get rid of = TDP_INTCPCALLOUT Gleb Smirnoff >> cpuid =3D 0 >> time =3D 1 >> KDB: stack backtrace: >> Fatal kernel mode data abort: 'Translation Fault (L1)' on read >> trapframe: 0xc0f14568 >> FSR=3D00000005, FAR=3Ddb7fcfb1, spsr=3D200001d3 >> r0 =3Dc0f1465c, r1 =3D00000001, r2 =3Ddb7fcfae, r3 =3D1b000a4e >> r4 =3Dc07fc55c, r5 =3D8fce1b89, r6 =3D00006f3e, r7 =3D81000000 >> r8 =3Dc07c4b6c, r9 =3Dc094ace8, r10=3Dc09741d8, r11=3Dc0f14618 >> r12=3Dc0f146c4, ssp=3Dc0f145fc, slr=3Dc0601428, pc =3Dc062686c >>=20 >> panic: Fatal abort >> cpuid =3D 0 >> time =3D 1 >> KDB: stack backtrace: >> Fatal kernel mode data abort: 'Translation Fault (L1)' on read >> trapframe: 0xc0f141f0 >> FSR=3D00000005, FAR=3Ddb7fcfb1, spsr=3D200001d3 >> r0 =3Dc0f142e4, r1 =3D00000001, r2 =3Ddb7fcfae, r3 =3D1b000a4e >> r4 =3Dc07fc55c, r5 =3D8fce1b89, r6 =3D00006f3e, r7 =3D81000000 >> r8 =3Dc07c4b6c, r9 =3Dc094ace8, r10=3Dc09741d8, r11=3Dc0f142a0 >> r12=3Dc0f1434c, ssp=3Dc0f14284, slr=3Dc0601428, pc =3Dc062686c >>=20 >> panic: Fatal abort >> cpuid =3D 0 >> time =3D 1 >> KDB: stack backtrace: >> Fatal kernel mode data abort: 'Translation Fault (L1)' on read >> trapframe: 0xc0f13e78 >> FSR=3D00000005, FAR=3Ddb7fcfb1, spsr=3D200001d3 >> r0 =3Dc0f13f6c, r1 =3D00000001, r2 =3Ddb7fcfae, r3 =3D1b000a4e >> r4 =3Dc07fc55c, r5 =3D8fce1b89, r6 =3D00006f3e, r7 =3D81000000 >> r8 =3Dc07c4b6c, r9 =3Dc094ace8, r10=3Dc09741d8, r11=3Dc0f13f28 >> r12=3Dc0f13fd4, ssp=3Dc0f13f0c, slr=3Dc0601428, pc =3Dc062686c >>=20 >> panic: Fatal abort >> cpuid =3D 0 >> time =3D 1 >> KDB: stack backtrace: >> Fatal kernel mode data abort: 'Translation Fault (L1)' on read >> trapframe: 0xc0f13b00 >> FSR=3D00000005, FAR=3Ddb7fcfb1, spsr=3D200001d3 >> r0 =3Dc0f13bf4, r1 =3D00000001, r2 =3Ddb7fcfae, r3 =3D1b000a4e >> r4 =3Dc07fc55c, r5 =3D8fce1b89, r6 =3D00006f3e, r7 =3D81000000 >> r8 =3Dc07c4b6c, r9 =3Dc094ace8, r10=3Dc09741d8, r11=3Dc0f13bb0 >> r12=3Dc0f13c5c, ssp=3Dc0f13b94, slr=3Dc0601428, pc =3Dc062686c >>=20 >> panic: Fatal abort >> cpuid =3D 0 >> time =3D 1 >> KDB: stack backtrace: >> Fatal kernel mode data abort: 'Translation Fault (L1)' on read >> trapframe: 0xc0f13788 >> FSR=3D00000005, FAR=3Ddb7fcfb1, spsr=3D200001d3 >> r0 =3Dc0f1387c, r1 =3D00000001, r2 =3Ddb7fcfae, r3 =3D1b000a4e >> r4 =3Dc07fc55c, r5 =3D8fce1b89, r6 =3D00006f3e, r7 =3D81000000 >> r8 =3Dc07c4b6c, r9 =3Dc094ace8, r10=3Dc09741d8, r11=3Dc0f13838 >> r12=3Dc0f138e4, ssp=3Dc0f1381c, slr=3Dc0601428, pc =3Dc062686c >>=20 >> . . . >>=20 >> Looking: >>=20 >> # llvm-addr2line -e /boot/kernel.GENERIC-NODEBUG/kernel 0xc062686c >> /home/pkgbuild/worktrees/main/sys/vm/uma_core.c:5676 >>=20 >> static int >> sysctl_handle_uma_zone_frees(SYSCTL_HANDLER_ARGS) >> { >> uma_zone_t zone =3D arg1; >> uint64_t cur; >>=20 >> cur =3D uma_zone_get_frees(zone); >> return (sysctl_handle_64(oidp, &cur, 0, req)); >> } >>=20 >> The "return" line is 5676 of sys/vm/uma_core.c . >>=20 >>=20 >> Also, for what leads up to: >>=20 >> /home/pkgbuild/worktrees/main/sys/arm/arm/pmap-v6.c:6455 >>=20 >> /* =20 >> * The implementation of pmap_fault() uses IN_RANGE2() macro which >> * depends on the fact that given range size is a power of 2. >> */ >> CTASSERT(powerof2(NB_IN_PT1)); >> CTASSERT(powerof2(PT2MAP_SIZE)); >>=20 >> #define IN_RANGE2(addr, start, size) \ >> ((vm_offset_t)(start) =3D=3D ((vm_offset_t)(addr) & ~((size) - 1))) >>=20 >> /* >> * Handle access and R/W emulation faults. >> */ >> int >> pmap_fault(pmap_t pmap, vm_offset_t far, uint32_t fsr, int idx, bool = usermode) >> { >> pt1_entry_t *pte1p, pte1; >> pt2_entry_t *pte2p, pte2; >>=20 >> if (pmap =3D=3D NULL) >> pmap =3D kernel_pmap; >>=20 >> /* >> * In kernel, we should never get abort with FAR which is in = range of >> * pmap->pm_pt1 or PT2MAP address spaces. If it happens, stop = here >> * and print out a useful abort message and even get to the = debugger >> * otherwise it likely ends with never ending loop of aborts. >> */ =20 >> if (__predict_false(IN_RANGE2(far, pmap->pm_pt1, NB_IN_PT1))) { >> /* >> * All L1 tables should always be mapped and present. >> * However, we check only current one herein. For user = mode, =20 >> * only permission abort from malicious user is not = fatal. >> * And alignment abort as it may have higher priority. >> */ >> if (!usermode || (idx !=3D FAULT_ALIGN && idx !=3D = FAULT_PERM_L2)) { >> CTR4(KTR_PMAP, "%s: pmap %#x pm_pt1 %#x far = %#x", >> __func__, pmap, pmap->pm_pt1, far); >> panic("%s: pm_pt1 abort", __func__); >> } >> return (KERN_INVALID_ADDRESS); >> }=20 >> if (__predict_false(IN_RANGE2(far, PT2MAP, PT2MAP_SIZE))) { >> /* >> * PT2MAP should be always mapped and present in = current >> * L1 table. However, only existing L2 tables are = mapped >> * in PT2MAP. For user mode, only L2 translation abort = and >> * permission abort from malicious user is not fatal. >> * And alignment abort as it may have higher priority. >> */ >> if (!usermode || (idx !=3D FAULT_ALIGN && >> idx !=3D FAULT_TRAN_L2 && idx !=3D FAULT_PERM_L2)) = { >> CTR4(KTR_PMAP, "%s: pmap %#x PT2MAP %#x far = %#x", >> __func__, pmap, PT2MAP, far); >> panic("%s: PT2MAP abort", __func__); >> } >> return (KERN_INVALID_ADDRESS); >> } >>=20 >> /* >> * A pmap lock is used below for handling of access and R/W = emulation >> * aborts. They were handled by atomic operations before so = some >> * analysis of new situation is needed to answer the following = question: >> * Is it safe to use the lock even for these aborts? >> * >> * There may happen two cases in general: >> * >> * (1) Aborts while the pmap lock is locked already - this = should not >> * happen as pmap lock is not recursive. However, under pmap = lock only >> * internal kernel data should be accessed and such data should = be >> * mapped with A bit set and NM bit cleared. If double abort = happens, >> * then a mapping of data which has caused it must be fixed. = Further, >> * all new mappings are always made with A bit set and the bit = can be >> * cleared only on managed mappings. >> * >> * (2) Aborts while another lock(s) is/are locked - this = already can >> * happen. However, there is no difference here if it's either = access or >> * R/W emulation abort, or if it's some other abort. >> */ >>=20 >> PMAP_LOCK(pmap); >>=20 >> That "PMAP_LOCK(pmap);" line is line 6455 of sys/arm/arm/pmap-v6.c . >>=20 >>=20 >> FYI: Running the prior kernel.GENERIC-NODEBUG/ ( called >> kernel.GENERIC-NODEBUG.good/ ) continues to operate >> normally. I do not have the older PkgBase kernel/ around >> to try, unfortunately. I'll remind that this is from using official FreeBSD builds of the kernel versions that I tested, not from my personal build context. =3D=3D=3D Mark Millard marklmi at yahoo.com