From nobody Sat Aug 05 21:40: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 4RJGH01H5lz4TmkZ for ; Sat, 5 Aug 2023 21:41:00 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-25.consmr.mail.gq1.yahoo.com (sonic304-25.consmr.mail.gq1.yahoo.com [98.137.68.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 4RJGGy6JwGz3R98 for ; Sat, 5 Aug 2023 21:40:58 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=oNNfxPwN; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.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=1691271656; bh=HGf+x95fMZy+uRWb6BG5VmxXneaf7KDZL1ENnRZxUvA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=oNNfxPwNdYuRWQEfPHXX7dYqs2fbiKDMKYQ7ho/f01WaZSfDG6NsN6AWVDcTDOLOXSeUgdvMkuBqEejnzOgZlx0PR+qT0E5D5G7lu622lEE1EZLCuEUVDiWdSVlS/g/hxiVs/GPC9IM49kkxXnEphwnDIgnPjCZAJEbcz3GGVFr3m9YaTyABoh4dA8xcqejjsk3i6mpypSy4oBDNnhSETMUyenscP1dmhcYZPA93VZ6imiPiexZH69KU9SmC/B92lh21bU0nCKbcd+BT2YM4p3hWgC+O4+Ytn0q0pT/JKoj1JIvO92Qf7VgxxZdZquWzICX5RIT8pz6hGqdqkWxfQw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1691271656; bh=XxJM/mwSdpz0nQADqaRaUqEcE5vvkc8wZrHK9a1twLr=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=NvWK/Wui8VdvNNuDaPFAnYERJWwbPktDM9vN0fp3xsZe7tqKJH9/WCW3h0Zrr2Zr/hpxcntoG1wjHYaNmEbCjR7Xp5gNivbx4KJf31pmYNNoKt3CdzG2vkwz0W99RL8YLfMeCZRi3ZUPOB046EhY62IrLVXl3WbKnf3eWBQ9vYCKu3mh92ug/2kXEPo32ksemX3/aPg7O7Iqxw3Z2dCzsicZ41OVcsziyQC3BDz9ZSuj5O2PD6fyVBFxZGe3yKHxykIcRkDOWoZlpUhL+xmEXGz9sbtcGiNNUu9rrQTBfcZvrYtzSlZ00DTNH6a/tTV1bFanVd/Ssp1Iz3mE3ccfjg== X-YMail-OSG: VFzTxrwVM1myELjpMALcSUjTytBubn0Or20eoe0KRutASkH6IxImIu.RKl4EPQS 8ngKpiHr8OdEFkoCxWZA9WjX5aDVLUvqm2C.6EkMDzLnN03a1bXZjJ8EF218NL87PjIgFKaoi54S GfqMKbAbQsYouU1BSOPW8lPmkOYmrNj8xhzKMZnJSder4HXBSW6iq_CHOvNV0uFDdhLZWfcmKHJ9 .qhLQpKd2UNOmanKvirYvvFTV81jx.fXf_j03shYmbuTgsZDpiH.kSWxTEmDQmryyRogfDF86eE0 WERa8Re346aRac5jPwBs0tB1QrYGPmlGdoLdAkxygO6efaLh09jygh1KHMcKFYSzq7pXS7qN3lmi 1Ep_k6c.GSlu6IT2FWNRFaXKfpYBrKdBOXOv3w9gJGoAmDVrMqG45Q4aoesvdnaLRcW4XkZCiiQu Y2ZVGtOIHcRrocGnxCYcfz5EeISSW2neAJMd0w1gZG4Iw62ognVUgEcnobuu91fsBdjdg0R9h2IR jnwYt4dsROBZyZ3mtbZPdixKbR7pnnQZQZBqv_QPPUqwtv6LxDDoByin3M09cavXdLzMbywWOVvW Q7QOqo5QDJlMt1LqiXNQjZqFtTQmccLU7.85Igeqe_xMMtNmlBBlOZufBkqH4VBRwtbkjg0yEF0l _pNueTuKdiG9tty6MuCtYQi1kYm8wEts0D59NElNKusONfn8otucjjv8mcaI_QOuNf6M6XHbbgun 5NSUi_P6m5u4eHjh.v3gx43V1lBKudXXq735ej44C0llyAvmutg8Fyinx5.NfUinZDExJubK1Y5d hdWYuZH9FAMCBEe4joNN7aSCUyiLBMEQOH8ebOZqFtgK2HtHdOqTrzYSHOsfP8uurPtAk3UagA5P eFs6NsX3wiVXJGLX.8FHCbWQSd4jlsOPOLpWtUnY7NgEvRrDAtnzmrze2aYGNUDsn5rdW2SVTv1x kPvkIggxCBkS7JKry3bhKEoQSY_TbqgSn1zGFwxm94U2S0Fkk9lmSObCUFNqhZvxKz8fqUtjiTSf 6dbAsIzpKPN6TqZlDmK2KtwiSiWAE4aBbgnVND9W9xrvle4WfUVkpujtZMExCsOvZC3NHoSFG_Dz EgvSLv.GCuEXPOQlj7sSxH.3ZQVHngsETvUgpn8M1SnRLEb4PYEq1AxCkeuszKCyro63H83Ocvn1 jS9vYkvdmxOfuSM9j4QiDT3S9bCRZB4WRxmHdd3hqEz_NL9_TWpZD_VgAMdkKMSglSe2vAyVd47H lr.v17vmNyZuefpE89AuKHyT3zjkfx4Jz.U0y19DbW1GjKThhfK4ME7Q5hK9FO5cOJrtcgNUBTZL 3fAfVBnl2J50sjSJ.8BYMYsRxyZZar5gRpwSkHzjzQ4hEgGipUwgWax7tqiBpqh4vyvnOU6zzfuG VlxxPmjkMvOHmz1kSd5GYgyrthxJcQZOqFisyYsKhOSYGpoeGcNbmawSUz2RynqtQlIH8odkarzX SjNj88N0EkU_pAeIXv9omGJED5cZq8LI8sxkwVTuecXw6aNFaAVefC7YCOhMzg5yHN43NFJGF7Aw jQnqmTfC3mK8hMgZVBEYvvDufUK8FhQtUNmIqbR8oB8MCxrtHHg7hGPJhE.IJYFgGFELcZiOwQHF EUA2qyex11.9JZiB2gIgQ8jAOU67xeU6t.Rz1UgMTLYg2SKFSB8S7.rf3BPqsFro.zNnjWyeEpVA ZH03pcO5Ssjte10UD2epRPk82XWKrZIWZIbQCWeoQnKLT8lkmX_J2CV_3NjsHM8qHyXE9wDsPIu6 dRN1aQPP2kMwc5Fp6IqnKkjQgq6PwDk2jeU3CPssnkle5GA4USOmauTb0_iJzvRn9Wn.ZuFk6QcE p7ue95ebDs0.1p_hAgA89CKrmLFZsreRYi1gXz3OHjHgCvr.vI.sK28Ab.332NkJgv5yAaek5nHm kEolZt7fsoSz9kzO.XfPpSeebbIUdR38GgyywNuz_s40.XTRbYUlXsMcGCz5jaZFmxOo56UA0YTp HZYBcAL6q.0YBCONzR6Iel7fHLs8Q8NiZmt2N75Wuki8k0bwt74jQfmE9.xsYA2QewkK98m18tnl 9Um3EpSKx8Vbs6UQpR5DS.XdZs3u_oAyjIaLPv7raBu1Y.V3kj1n8eSkFHOgUTpuIg4.N3Cmgc0d e38w0n9nyBCvzHjpodGe92sv3yOMqJ7nkCVehIRTTUw7g.5BJWtn.7tFYWkfGFghptLFWqtT0.GS ggpyQ5ag8tJGEPzkZ5pp1QfZhDjcCpIYhSCftYN8Zqe3efZ8Lxd7oiddSPJAk1a4sGuHPJoEIwMg - X-Sonic-MF: X-Sonic-ID: 19923d52-0811-4d5e-9ec7-7fb5747a07c6 Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Sat, 5 Aug 2023 21:40:56 +0000 Received: by hermes--production-gq1-7d844d8954-psjqr (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID c9a0084abba49ae228b3aaa237931158; Sat, 05 Aug 2023 21:40:52 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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: <8CDB7543-E21C-47BC-AB18-52D24ED855ED@yahoo.com> Date: Sat, 5 Aug 2023 14:40:41 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <6F3ED262-F0EA-4FCA-AEF1-CD785E44E068@yahoo.com> References: <466233a6-f904-f2f4-ac9e-7476965e97c2@gmail.com> <8CDB7543-E21C-47BC-AB18-52D24ED855ED@yahoo.com> To: meloun.michal@gmail.com X-Mailer: Apple Mail (2.3731.700.6) X-Spamd-Result: default: False [-2.43 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.93)[-0.926]; 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.68.206:from]; MID_RHS_MATCH_FROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.206: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: 4RJGGy6JwGz3R98 On Aug 5, 2023, at 14:04, Mark Millard wrote: > On Aug 5, 2023, at 11:27, Michal Meloun = wrote: >=20 >> Hi Mark, >> can you please try a this patch? >> = https://github.com/strejda/tegra/commit/bd4390c5f6a8b66b2fc83966d4fadb945a= 19dc23 >=20 > I'll take a stab at testing it. >=20 > But I'll note that description of the patch is somewhat odd: >=20 > 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 >=20 > __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. >=20 > 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.) >=20 >> 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. >=20 [Older history deleted.] No notable change in behavior, I'm afraid . . . sys/netinet6/exthdr:exthdr -> =20 Fatal kernel mode data abort: 'Alignment Fault' on read trapframe: 0xc51fbaa0 FSR=3D00000001, FAR=3Ddaed4476, spsr=3D60000013 r0 =3Ddaf787c0, r1 =3Dc51fbb34, r2 =3D00000000, r3 =3D00000000 r4 =3D00000000, r5 =3D00000000, r6 =3Ddaed4476, r7 =3Ddaed4466 r8 =3Dc0965c3c, r9 =3D00000000, r10=3Ddb0e4400, r11=3Dc51fbb60 r12=3D00000000, ssp=3Dc51fbb30, slr=3Dc0b524c0, pc =3Dc04e8e78 panic: Fatal abort cpuid =3D 1 time =3D 1691270886 KDB: stack backtrace: db_trace_self() at db_trace_self pc =3D 0xc0661824 lr =3D 0xc007db80 = (db_trace_self_wrapper+0x30) sp =3D 0xc51fb858 fp =3D 0xc51fb970 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc =3D 0xc007db80 lr =3D 0xc031a834 (vpanic+0x140) sp =3D 0xc51fb978 fp =3D 0xc51fb998 r4 =3D 0x00000100 r5 =3D 0x00000000 r6 =3D 0xc07c5a9a r7 =3D 0xc0b36e58 vpanic() at vpanic+0x140 pc =3D 0xc031a834 lr =3D 0xc031a6f4 (vpanic) sp =3D 0xc51fb9a0 fp =3D 0xc51fb9a4 r4 =3D 0xc51fbaa0 r5 =3D 0x00000013 r6 =3D 0xdaed4476 r7 =3D 0x00000001 r8 =3D 0x00000001 r9 =3D 0xdaf787c0 r10 =3D 0xdaed4476 vpanic() at vpanic pc =3D 0xc031a6f4 lr =3D 0xc0686ddc (abort_align) sp =3D 0xc51fb9ac fp =3D 0xc51fb9d8 r4 =3D 0x00000001 r5 =3D 0x00000001 r6 =3D 0xdaf787c0 r7 =3D 0xdaed4476 r8 =3D 0xc51fb9a4 r9 =3D 0xc031a6f4 r10 =3D 0xc51fb9ac abort_align() at abort_align pc =3D 0xc0686ddc lr =3D 0xc0686e50 (abort_align+0x74) sp =3D 0xc51fb9e0 fp =3D 0xc51fb9f8 r4 =3D 0x00000013 r10 =3D 0xdaed4476 abort_align() at abort_align+0x74 pc =3D 0xc0686e50 lr =3D 0xc0686aa8 (abort_handler+0x45c) sp =3D 0xc51fba00 fp =3D 0xc51fba98 r4 =3D 0x00000000 r10 =3D 0xdaed4476 abort_handler() at abort_handler+0x45c pc =3D 0xc0686aa8 lr =3D 0xc06640d8 (exception_exit) sp =3D 0xc51fbaa0 fp =3D 0xc51fbb60 r4 =3D 0x00000000 r5 =3D 0x00000000 r6 =3D 0xdaed4476 r7 =3D 0xdaed4466 r8 =3D 0xc0965c3c r9 =3D 0x00000000 r10 =3D 0xdb0e4400 exception_exit() at exception_exit pc =3D 0xc06640d8 lr =3D 0xc0b524c0 (__pcpu+0x200) sp =3D 0xc51fbb30 fp =3D 0xc51fbb60 r0 =3D 0xdaf787c0 r1 =3D 0xc51fbb34 r2 =3D 0x00000000 r3 =3D 0x00000000 r4 =3D 0x00000000 r5 =3D 0x00000000 r6 =3D 0xdaed4476 r7 =3D 0xdaed4466 r8 =3D 0xc0965c3c r9 =3D 0x00000000 r10 =3D 0xdb0e4400 r12 =3D 0x00000000 in6ifa_ifwithaddr() at in6ifa_ifwithaddr+0x30 pc =3D 0xc04e8e78 lr =3D 0xc04fb338 (ip6_input+0xd38) sp =3D 0xc51fbb68 fp =3D 0xc51fbc28 r4 =3D 0xdaed4476 r5 =3D 0xdaed445e r6 =3D 0x00000000 r7 =3D 0xdaed4466 ip6_input() at ip6_input+0xd38 pc =3D 0xc04fb338 lr =3D 0xc046d66c (netisr_dispatch_src+0xf8) sp =3D 0xc51fbc30 fp =3D 0xc51fbc58 r4 =3D 0xdaed4400 r5 =3D 0x00000006 r6 =3D 0x00000001 r7 =3D 0xc0b4dd50 r8 =3D 0xdaf9d900 r9 =3D 0xdaed4400 r10 =3D 0x00000086 netisr_dispatch_src() at netisr_dispatch_src+0xf8 pc =3D 0xc046d66c lr =3D 0xc04641b0 (ether_demux+0x18c) sp =3D 0xc51fbc60 fp =3D 0xc51fbc78 r4 =3D 0x00000006 r5 =3D 0x00001201 r6 =3D 0xdb0e4400 r7 =3D 0x000000ff r8 =3D 0xdaf9d900 r9 =3D 0xdaed4400 r10 =3D 0x00000086 ether_demux() at ether_demux+0x18c pc =3D 0xc04641b0 lr =3D 0xc0465880 (ether_nh_input+0x490) sp =3D 0xc51fbc80 fp =3D 0xc51fbce0 r4 =3D 0xdb0e4400 r5 =3D 0xdaed4400 r6 =3D 0xdaed4450 r10 =3D 0x00000086 ether_nh_input() at ether_nh_input+0x490 pc =3D 0xc0465880 lr =3D 0xc046d66c (netisr_dispatch_src+0xf8) sp =3D 0xc51fbce8 fp =3D 0xc51fbd10 r4 =3D 0xdaed4400 r5 =3D 0x00000005 r6 =3D 0x00000003 r7 =3D 0xc0b4dd30 r8 =3D 0xdaf9d900 r9 =3D 0xdaed4400 r10 =3D 0xc098f58f netisr_dispatch_src() at netisr_dispatch_src+0xf8 pc =3D 0xc046d66c lr =3D 0xc04645c4 (ether_input+0x50) sp =3D 0xc51fbd18 fp =3D 0xc51fbd48 r4 =3D 0xdaed4400 r5 =3D 0x00000000 r6 =3D 0x00008803 r7 =3D 0x00000000 r8 =3D 0xdaf9d900 r9 =3D 0xdaed4400 r10 =3D 0xc098f58f ether_input() at ether_input+0x50 pc =3D 0xc04645c4 lr =3D 0xdffb3f08 ($a.10+0x108) sp =3D 0xc51fbd50 fp =3D 0xc51fbd78 r4 =3D 0xdb0e4400 r5 =3D 0xdaff4000 r6 =3D 0xdaff4010 r7 =3D 0x00000000 r8 =3D 0x00000000 r10 =3D 0xc098f58f $a.10() at $a.10+0x108 pc =3D 0xdffb3f08 lr =3D 0xc038cb2c = (taskqueue_run_locked+0x1c4) sp =3D 0xc51fbd80 fp =3D 0xc51fbdd8 r4 =3D 0xdaff2100 r5 =3D 0xdaff402c r6 =3D 0xdaff2150 r7 =3D 0x00000001 r8 =3D 0x00000000 r9 =3D 0xc51fbd90 r10 =3D 0x00000001 taskqueue_run_locked() at taskqueue_run_locked+0x1c4 pc =3D 0xc038cb2c lr =3D 0xc038e4e4 = (taskqueue_thread_loop+0x1b0) sp =3D 0xc51fbde0 fp =3D 0xc51fbe10 r4 =3D 0xdaff2100 r5 =3D 0xdaff2140 r6 =3D 0xc07b18c4 r7 =3D 0x00000000 r8 =3D 0xc098f58f r9 =3D 0x00000100 r10 =3D 0xc0b268a0 taskqueue_thread_loop() at taskqueue_thread_loop+0x1b0 pc =3D 0xc038e4e4 lr =3D 0xc02cdf0c (fork_exit+0xc0) sp =3D 0xc51fbe18 fp =3D 0xc51fbe38 r4 =3D 0xdaf787c0 r5 =3D 0xc0b264e0 r6 =3D 0xc038e334 r7 =3D 0xdffc4f54 r8 =3D 0xc51fbe40 r9 =3D 0xc098f591 fork_exit() at fork_exit+0xc0 pc =3D 0xc02cdf0c lr =3D 0xc066406c (swi_exit) sp =3D 0xc51fbe40 fp =3D 0x00000000 r4 =3D 0xc038e334 r5 =3D 0xdffc4f54 r6 =3D 0xc0b48d84 r7 =3D 0xd73bd3e0 r8 =3D 0x00000001 r10 =3D 0xc0b268a0 swi_exit() at swi_exit pc =3D 0xc066406c lr =3D 0xc066406c (swi_exit) sp =3D 0xc51fbe40 fp =3D 0x00000000 KDB: enter: panic [ thread pid 0 tid 100226 ] I've just restored the sources involved but still have the .diff I that got via github. =3D=3D=3D Mark Millard marklmi at yahoo.com