From nobody Mon Jun 26 14:29:04 2023 X-Original-To: freebsd-current@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 4QqVbz6Gpzz4kGJ1 for ; Mon, 26 Jun 2023 14:29:51 +0000 (UTC) (envelope-from jfc@mit.edu) Received: from outgoing-exchange-5.mit.edu (outgoing-exchange-5.mit.edu [18.9.28.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.outgoing-exchange.mit.edu", Issuer "InCommon RSA Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QqVbz4H1nz4GD9 for ; Mon, 26 Jun 2023 14:29:51 +0000 (UTC) (envelope-from jfc@mit.edu) Authentication-Results: mx1.freebsd.org; none Received: from oc11exedge2.exchange.mit.edu (OC11EXEDGE2.EXCHANGE.MIT.EDU [18.9.3.18]) by outgoing-exchange-5.mit.edu (8.14.7/8.12.4) with ESMTP id 35QETcvN018300; Mon, 26 Jun 2023 10:29:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1687789788; bh=n1eeb31OuVcsDZa2KeMH/0oqPoCT3A0oHSOg+LvOMYg=; h=From:To:CC:Subject:Date:References:In-Reply-To; b=M3jx0NPkTxw66NbYeoy4bp1we81kJLKUBVv0tIg2Zhs2rqNNfAmHNkqNsNkdyS8Mr qzn7JNPVq0Do9w5VjjibVay/t0oReayywcMBi5gvKlCRuf1ZfW+szdpVCsSylY8iiP Uam8MU5YzG1BkkG3+YJbj0VSMPvWIgySbK99GVwFF8wdkdkp5uilS5EJxxjkSkozBQ hpD2un9J/pTp19DaZmitIhiycdPNZlpysHv2d7IntwOAghBc7CN8Gd2PIKq4wjSa/l YaPTIlKsaNov5Dko2hR/iH9XPzj4ie2DjhwRb0dP9TzaLO1w6br8rv6lE/mVj+s6Ox chhL+UIlxHCww== Received: from oc11expo23.exchange.mit.edu (18.9.4.88) by oc11exedge2.exchange.mit.edu (18.9.3.18) with Microsoft SMTP Server (TLS) id 15.0.1497.48; Mon, 26 Jun 2023 10:28:50 -0400 Received: from oc11exhyb1.exchange.mit.edu (18.9.1.60) by oc11expo23.exchange.mit.edu (18.9.4.88) with Microsoft SMTP Server (TLS) id 15.0.1497.42; Mon, 26 Jun 2023 10:29:06 -0400 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (104.47.58.109) by oc11exhyb1.exchange.mit.edu (18.9.1.60) with Microsoft SMTP Server (TLS) id 15.0.1497.48 via Frontend Transport; Mon, 26 Jun 2023 10:29:06 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=m10dDsKVRnML9S689kNbK+SQigwPzF5fN4t750CtAT1A3HkLqWVo+tiTARyfWsYmQnaJWJKXsoFK5YXgGNU2y46XSS5y/UPac/8CGeR8wwEXXdaeKEdoOhF+G3/XymrbWkQqrEQrXfoNC2cGOUbMY7yydnlaQ/3gdwmgGVFBS1cJYjqJGNgHg9ehlM4narur8LQKMkJxEvdHozVQp9xDFQfPGIrXwL/tevCRAYT4rEa1RZtxLNEzsAAnbmjGhKAKlAeR86uS2F7KdawnJa+pAKlluPQC8s1p/w02adj+CKodLsWA34KaASlhLo7Tp5oYwKS18eSkqBl6EWsZznqokw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=n1eeb31OuVcsDZa2KeMH/0oqPoCT3A0oHSOg+LvOMYg=; b=GSBEZBKFtP2KAWfQ+vYbCcGJJh3HLzcVKtFTNEe735rwU0Ajhc66CZD1nyyAwMerqwxJ5wE5gJu21u353C2VpFtPvw/c8FKss28JWLQW/5DGrxNeB+P3M4qsIIARUHhV/fo0BSZ0XvEpPAsF0mi2qqYSo6qLix6YPZHGRczn7bRoBogxY9qa5sWnT9spRcfq55/BkrFUcFpyARzr2epQVgYLlohDen/2Wm0BNDgv8k9+jrx+S04dH3ww8aH6VdSun/AFXinMCLgpP9IIzBMfzMjefM+Lm5gfkWXcu5qKYfQBN0tG4Fns/jy9t8DfTP5VEanfZBRYbagAOYUiDxgAUw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=mit.edu; dmarc=pass action=none header.from=mit.edu; dkim=pass header.d=mit.edu; arc=none Received: from DS7PR01MB7712.prod.exchangelabs.com (2603:10b6:8:7b::17) by MW4PR01MB6388.prod.exchangelabs.com (2603:10b6:303:7f::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6521.24; Mon, 26 Jun 2023 14:29:04 +0000 Received: from DS7PR01MB7712.prod.exchangelabs.com ([fe80::5d78:4464:66e8:94a9]) by DS7PR01MB7712.prod.exchangelabs.com ([fe80::5d78:4464:66e8:94a9%7]) with mapi id 15.20.6521.024; Mon, 26 Jun 2023 14:29:04 +0000 From: John F Carr To: Mark Millard CC: Current FreeBSD , freebsd-arm Subject: Re: aarch64 main-n263493-4e8d558c9d1c-dirty (so: 2023-Jun-10) Kyuafile run: "Fatal data abort" crash during vnet_register_sysinit Thread-Topic: aarch64 main-n263493-4e8d558c9d1c-dirty (so: 2023-Jun-10) Kyuafile run: "Fatal data abort" crash during vnet_register_sysinit Thread-Index: AQHZpr1rzd2h1E+wcEelf+6QGJgaxK+ad6YAgAAx/YCAAho/gIAAY7OA Date: Mon, 26 Jun 2023 14:29:04 +0000 Message-ID: <2E9684B7-9359-4A3D-A0C2-C1D2B221F2C4@mit.edu> References: <3FD359F8-CFCC-400F-B6DE-B635B747DE7F.ref@yahoo.com> <3FD359F8-CFCC-400F-B6DE-B635B747DE7F@yahoo.com> <4A380699-7C9E-4E2E-8DCD-F9ECC2112667@yahoo.com> <64F18C76-BD2A-4608-A8CC-38AC2820FC12@yahoo.com> In-Reply-To: <64F18C76-BD2A-4608-A8CC-38AC2820FC12@yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DS7PR01MB7712:EE_|MW4PR01MB6388:EE_ x-ms-office365-filtering-correlation-id: 13e81668-19bc-4931-10e3-08db7651b1a8 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: LqOp2mUMyAzBUbfPPdZwGwqm/0KnzSWNAkASaRDUxNqqnE2CFT8s2YAXouKz8Uy/vlYEC057q3VidfezbcOVHMXt0FzAmXfyTI40RHoHXR2sxtuZigGhOQTbOd/TNTHqqEGf4l/UrrdkZ4uP78mQHSdzQhAK3wazlz/Fg97ucQ0jJBQ4ij1iqfYmKPmdVlHAuaOTk7cO9hCO+TMoJAc+argi5/rj6HpB54Kc4vgKKhOgN20COXHOhf5Hi/kR0BCfN0mvjTsaKAT6jZ4VXfkR1+WbGFDqXiZv4WFfAsXniRWAZpDJqefWMrL0UdYi92Wm+5ob7lUL4XEbFubgKxtVyhLoT9ASZmcV3Xj5iPTVRmACHlyoQhV3a09U7cPZDNg8zURe2RyD3yq27FG643wLyz627IUGfSJgqbdo+risn4J1ccWLRTFMsHXjJVuiBgq35RAkS0ufSJBt7hhtGlOg/ILBx/Mx5/IUjO8AwQnwjq1E/u37hC16lnNvfltttlQfjUf1qWzJ5h3d3iCGxnjrhv6dFrAQbnDeL26eydPSaGG43fnE4Pq/qJ3WkzIVJqO2/dQMVZzcG8T1fc6u0vSV2ZwpoqYYJEXWHInUWDFuBgFBI+lILLgsDKFAxCUpw64U x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DS7PR01MB7712.prod.exchangelabs.com;PTR:;CAT:NONE;SFS:(13230028)(4636009)(136003)(396003)(346002)(376002)(366004)(39860400002)(451199021)(64756008)(4326008)(76116006)(66946007)(66556008)(66476007)(66446008)(33656002)(316002)(6916009)(786003)(478600001)(38070700005)(8936002)(36756003)(91956017)(8676002)(5660300002)(75432002)(966005)(19627235002)(86362001)(54906003)(41300700001)(6486002)(2906002)(53546011)(26005)(6512007)(6506007)(186003)(122000001)(38100700002)(71200400001)(83380400001)(2616005)(14143004);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?0pOHWxJhjrMCjPwpJU6iXJ6M7isvXzxsWtGOgfDainf810YfwWZdXJU51D7n?= =?us-ascii?Q?ne34YKu1sMvJC1D70p2h1iEpCMzYyb6xHBlvUKOxue+4c0ymg6a9Ka/sU81k?= =?us-ascii?Q?GElg1Swnvp+RtBWXpBorj9c+O2ScvGqTNHkyU79GbbidyQJKDJhRhXl2k+Wv?= =?us-ascii?Q?+I+5wQp+UK9Cqj/Mztx+qJNuYJ25LNxVMYRx6wXZFykKybL6ZPFW57WCjsHe?= =?us-ascii?Q?MTYgpaJcCUcuuNsaTmWP4zlHQlx8GqynsKVxCWVdJSZTwFn49rr9BYfotfc9?= =?us-ascii?Q?HSFfdO/LTF3e+1y5sTRlo3Dh10tOpMCSlDKjQUf7SBjO0jKI10frj4If3z6W?= =?us-ascii?Q?u3AfZuSjPVuNDN5KGFtfwomJFZy81R/4Uco3wJfDSvMjRmZmGtTRP527Owu0?= =?us-ascii?Q?AGk6OgLo7xWc3VKF6iw3pdg45t2zIun6knN8qGHOTzOZGh5uCbiTk8ajRacs?= =?us-ascii?Q?6XcbGj7WYBPjuyExNsmCNf/Evl/gryLEeT8naIdsDwi7pEsrEOBL4D7Q2LDs?= =?us-ascii?Q?RwHbsbVVM3X9xfemt4SxV2oxpkpYm0ihS7iiRvFwl4355fPeD9/b6Zl9HOei?= =?us-ascii?Q?+dcOhq7jBkK+d7UwQDifrh/FmABPTmuYLCybmyElwPRNDNe+Zzj7OdfivShN?= =?us-ascii?Q?t5/wChoaTN4+28r0hE5Hrq4GS7GPzy9GIrMI8OtXPQQ6Ek4JfXzIMHX8qdpX?= =?us-ascii?Q?UEslG9w8RNyFIF2887Wgonx/LvvgcsuffYTpdmT8j1IYdZU1gk1EJtWr5Uui?= =?us-ascii?Q?e93d0kP4vfrJ2dMDXYEZYoh0YOL2Ti9eq/HkZQZTILFhdZERE3rmxhX9NvYK?= =?us-ascii?Q?bLqzrQkoYJujsvbEhXaI67RbrFVOXgkfBJEEb1Cn1Hd/5p5SRfsrcfdGZJSa?= =?us-ascii?Q?2DmmONhBOiVDpIpUtA3lYuTvCTr332F1uPWhJ4qfvSuR+YC45ovCAes/Fing?= =?us-ascii?Q?s/pHO6j9n9pNPYV+DDcZ+pDvHtn4fS/T9XNUOIbEBcAWxl7Pym4rmTzXZw/i?= =?us-ascii?Q?E/g7m5GL65sfnLoCDm8usAame3FLZ4pXy/FdD6fA4JdFwk1rMbme07Q/BulX?= =?us-ascii?Q?mXvPTe1dJbdmk7hwl4bvZrtwij9dUAO9+YVM37q5E7CvRaVMzDPwshPvjtdD?= =?us-ascii?Q?2/s/QQnZ8zTgkozABFm1u78xTuHH1y7PhMDO6HUb8BdlTC3RZRYDnRaKbMng?= =?us-ascii?Q?bgYhgQ4xbMitxfm55xiC/56U9GaC0hihcR7Al8q+Mj17FBCFp/IGBFi8m66q?= =?us-ascii?Q?Asgpk3HTIckULJmk1T5yHiLpB5Bb02UJScUQC+5Cfp5VPtO5xiwnl+thtg/S?= =?us-ascii?Q?xmZJBiIWSrB5LeZnMzPIJ8HnY4uzmd2eXo1SGXxNMmnadZbQ++67VkyZP8/5?= =?us-ascii?Q?r/6GUe4+DUGN8scJfGghR1RyObLbijqnJDv9X//Nu+70fNGTSVfzLoUUWZ7h?= =?us-ascii?Q?clJiwMH6rsyvmFoTFDH6yB26FW2JyUvkDu27KiE6Q3/T6rpfq/iWpfjs1psd?= =?us-ascii?Q?0/Hs01nxHOdd1AWFLxBnqBhrKxrx6fAZdUokwbqKHT4OYFV/m1cSRlFkMAFO?= =?us-ascii?Q?y1WOZLMzyXqXMOB+w2o=3D?= Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DS7PR01MB7712.prod.exchangelabs.com X-MS-Exchange-CrossTenant-Network-Message-Id: 13e81668-19bc-4931-10e3-08db7651b1a8 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jun 2023 14:29:04.8075 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: WhgvTU391ieeZBIS4HzUTeNOZffGcsnrkH4NQKPTB4kg7bo2LrsKsNPxuEiYtkPd X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR01MB6388 X-OriginatorOrg: mit.edu X-Rspamd-Queue-Id: 4QqVbz4H1nz4GD9 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:3, ipnet:18.9.0.0/16, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N > On Jun 26, 2023, at 04:32, Mark Millard wrote: >=20 > On Jun 24, 2023, at 17:25, Mark Millard wrote: >=20 >> On Jun 24, 2023, at 14:26, John F Carr wrote: >>=20 >>>=20 >>>> On Jun 24, 2023, at 13:00, Mark Millard wrote: >>>>=20 >>>> The running system build is a non-debug build (but >>>> with symbols not stripped). >>>>=20 >>>> The HoneyComb's console log shows: >>>>=20 >>>> . . . >>>> GEOM_STRIPE: Device stripe.IMfBZr destroyed. >>>> GEOM_NOP: Device md0.nop created. >>>> g_vfs_done():md0.nop[READ(offset=3D5885952, length=3D8192)]error =3D 5 >>>> GEOM_NOP: Device md0.nop removed. >>>> GEOM_NOP: Device md0.nop created. >>>> g_vfs_done():md0.nop[READ(offset=3D5935104, length=3D4096)]error =3D 5 >>>> g_vfs_done():md0.nop[READ(offset=3D5935104, length=3D4096)]error =3D 5 >>>> GEOM_NOP: Device md0.nop removed. >>>> GEOM_NOP: Device md0.nop created. >>>> GEOM_NOP: Device md0.nop removed. >>>> Fatal data abort: >>>> x0: ffffa02506e64400 >>>> x1: ffff0001ea401880 (g_raid3_post_sync + 3a145f8) >>>> x2: 4b >>>> x3: a343932b0b22fb30 >>>> x4: 0 >>>> x5: 3310b0d062d0e1d >>>> x6: 1d0e2d060d0b3103 >>>> x7: 0 >>>> x8: ea325df8 >>>> x9: ffff0001eec946d0 ($d.6 + 0) >>>> x10: ffff0001ea401880 (g_raid3_post_sync + 3a145f8) >>>> x11: 0 >>>> x12: 0 >>>> x13: ffff000000cd8960 (lock_class_mtx_sleep + 0) >>>> x14: 0 >>>> x15: ffffa02506e64405 >>>> x16: ffff0001eec94860 (_DYNAMIC + 160) >>>> x17: ffff00000063a450 (ifc_attach_cloner + 0) >>>> x18: ffff0001eb290400 (g_raid3_post_sync + 48a3178) >>>> x19: ffff0001eec94600 (vnet_epair_init_vnet_init + 0) >>>> x20: ffff000000fa5b68 (vnet_sysinit_sxlock + 18) >>>> x21: ffff000000d8e000 (sdt_vfs_vop_vop_spare4_return + 0) >>>> x22: ffff000000d8e000 (sdt_vfs_vop_vop_spare4_return + 0) >>>> x23: ffffa0000042e500 >>>> x24: ffffa0000042e500 >>>> x25: ffff000000ce0788 (linker_lookup_set_desc + 0) >>>> x26: ffffa0203cdef780 >>>> x27: ffff0001eec94698 (__set_sysinit_set_sym_if_epairmodule_sys_init += 0) >>>> x28: ffff000000d8e000 (sdt_vfs_vop_vop_spare4_return + 0) >>>> x29: ffff0001eb290430 (g_raid3_post_sync + 48a31a8) >>>> sp: ffff0001eb290400 >>>> lr: ffff0001eec82a4c ($x.1 + 3c) >>>> elr: ffff0001eec82a60 ($x.1 + 50) >>>> spsr: 60000045 >>>> far: ffff0002d8fba4c8 >>>> esr: 96000046 >>>> panic: vm_fault failed: ffff0001eec82a60 error 1 >>>> cpuid =3D 14 >>>> time =3D 1687625470 >>>> KDB: stack backtrace: >>>> db_trace_self() at db_trace_self >>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x30 >>>> vpanic() at vpanic+0x13c >>>> panic() at panic+0x44 >>>> data_abort() at data_abort+0x2fc >>>> handle_el1h_sync() at handle_el1h_sync+0x14 >>>> --- exception, esr 0x96000046 >>>> $x.1() at $x.1+0x50 >>>> vnet_register_sysinit() at vnet_register_sysinit+0x114 >>>> linker_load_module() at linker_load_module+0xae4 >>>> kern_kldload() at kern_kldload+0xfc >>>> sys_kldload() at sys_kldload+0x60 >>>> do_el0_sync() at do_el0_sync+0x608 >>>> handle_el0_sync() at handle_el0_sync+0x44 >>>> --- exception, esr 0x56000000 >>>> KDB: enter: panic >>>> [ thread pid 70419 tid 101003 ] >>>> Stopped at kdb_enter+0x44: str xzr, [x19, #3200] >>>> db>=20 >>>=20 >>> The failure appears to be initializing module if_epair. >>=20 >> Yep: trying: >>=20 >> # kldload if_epair.ko >>=20 >> was enough to cause the crash. (Just a HoneyComb context at >> that point.) >>=20 >> I tried media dd'd from the recent main snapshot, booting the >> same system. No crash. I moved my build boot media to some >> other systems and tested them: crashes. I tried my boot media >> built optimized for Cortex-A53 or Cortex-X1C/Cortex-A78C >> instead of Cortex-A72: no crashes. (But only one system can >> use the X1C/A78C code in that build.) >>=20 >> So variation testing only gets the crashes for my builds >> that are code-optimized for Cortex-A72's. The same source >> tree vintage built for cortex-53 or Cortex-X1C/Cortex-A78C >> optimization does not get the crashes. But I also >> demonstrated an optmized for Cortex-A72 build from 2023-Mar >> that gets the crash. >>=20 >> The last time I ran into one of these "crashes tied to >> cortex-a72 code optimization" examples it turned out to be >> some missing memory-model management code in FreeBSD's USB >> code. But being lucky enough to help identify a FreeBSD >> source code problem again seems not that likely. It could >> easily be a code generation error by clang for all I know. >>=20 >> So, unless at some point I produce fairly solid evidence >> that the code actually running is messed up by FreeBSD >> source code, this should likely be treated as "blame the >> operator" and should likely be largely ignored as things >> are. (Just My Problem, as I want the Cortex-A72 optimized >> builds.) >=20 > Turns out that the source code in question is the > assignment to V_epair_cloner below: >=20 > static void > vnet_epair_init(const void *unused __unused) > { > struct if_clone_addreq req =3D { > .match_f =3D epair_clone_match, > .create_f =3D epair_clone_create, > .destroy_f =3D epair_clone_destroy, > }; > V_epair_cloner =3D ifc_attach_cloner(epairname, &req); > } > VNET_SYSINIT(vnet_epair_init, SI_SUB_PSEUDO, SI_ORDER_ANY, > vnet_epair_init, NULL); >=20 > Example code when not optimizing for the Cortex-A72: >=20 > 11a4c: d0000089 adrp x9, 0x23000 > 11a50: f9400248 ldr x8, [x18] > 11a54: f942c508 ldr x8, [x8, #1416] > 11a58: f943d929 ldr x9, [x9, #1968] > 11a5c: a9437bfd ldp x29, x30, [sp, #48] > 11a60: f9401508 ldr x8, [x8, #40] > 11a64: f8296900 str x0, [x8, x9] >=20 > The code when optmizing for the Cortex-A72: >=20 > 11a4c: f9400248 ldr x8, [x18] > 11a50: f942c508 ldr x8, [x8, #1416] > 11a54: d503201f nop > 11a58: 1008e3c9 adr x9, #72824 > 11a5c: f9401508 ldr x8, [x8, #40] > 11a60: f8296900 str x0, [x8, x9] > 11a64: a9437bfd ldp x29, x30, [sp, #48] >=20 > It is the "str x0, [x8, x9]" that vm_fault's for > the optimized code. >=20 > So: >=20 > 11a4c: d0000089 adrp x9, 0x23000 > 11a58: f943d929 ldr x9, [x9, #1968] >=20 > was optimized via replacement by: >=20 > 11a58: 1008e3c9 adr x9, #72824 >=20 > I.e., the optimization is based on the offset from > the instruction being fixed in order to produce the > value in x9, even if the instruction is relocated. >=20 > This resulted in the specific x9 value shown in > the x8/x9 pair: >=20 > x8: ea325df8 > x9: ffff0001eec946d0 >=20 > which total's to the fault address (value > in far): >=20 > far: ffff0002d8fba4c8 >=20 >=20 Is this the same as bug 264094? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D264094