From nobody Fri Nov 08 18:16:35 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 4XlRwh02kcz5cbw1 for ; Fri, 08 Nov 2024 18:16:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-20.consmr.mail.gq1.yahoo.com (sonic305-20.consmr.mail.gq1.yahoo.com [98.137.64.83]) (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 4XlRwg4cQTz43cR for ; Fri, 8 Nov 2024 18:16:51 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1731089810; bh=ahaQpF9BGD/q6I6WpaKWU0skt6XjzYN1uC319aS2qY8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=kBfsQT7My5gZMDRMrNZV/1qhRGptfjJw84xaInq7lPY/KCwSA0uOvC4UPjYF+8v8jQXe3xqmmKlaeBe7gmtcQnNE0kbXZQ0iPjbUOJycL7QtP/Z5M4ymX+Y+hgfA0etPjTk4zuqJKsQ2rfYmiC3riZ/xIv7fB44qZYIqi2jJCrgl2JL3OvhJC0TqQs3nqKdsxDPksTvFOCZN8Vp9Yma/hMvps3dsRWHVR/v2Zb4ve6wOnb9xvicdRM+ORqqD7++EY/JuOxxwXvgH8REdev7WwG2ZEt2yl+DpIq9HhsURnd2PEcBCW3+t/Xwv+xOr3TwduZ/u40wiJQrA6mbdjd1WUQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1731089810; bh=MMhIOqmN70GHiVw8HG3I8FKeJojSZjF/hXUCXSsQjWy=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=tHgBfPiyA1rb0gWArn1s8UyVRCKVjIWw/ZRlhKJ1vKP7lg6pBGpeoNrex1ZbL7+kKro68QmgKIsFUFD92B5GjjPjk1LFKj0iRkkTm+UwOjQt9fjJXRwS1YmOkqSmVLeKuTOMF1ZhJPblKCYZbroYXR/0HGl7Pyv9GYq6xNViEHqYGmaKi16AR9y9Rn54FixgfXbpShAqTRmwN2pDdcY1c83aqoR9MXQrfcTsEPW6ZmLJZHNTj1Qm85ougHMBW3mEbwrlmXmjvk/b/8cE5exLpY1IrUaI0LT/ItffUwAInybjXdZcorGIwJr0dRwOmjpvdJKkwlVbtUfivkR0M0vtvA== X-YMail-OSG: QoJHbRYVM1kvxCKgSUWFUBluhR223_Ap6l7AL.iabuCbcBrunba5M4tC7AJ7erM hROrUX.4q4ZfEMSdaag4q9yY..HwlLxZRRGMxocxDOaMfe0Fj95qCBKvsrkX61ceyqWO5_wY9ySb wGO6ENDZ.GGQWRckea9C5pr9tAJLmPcDLMd9QRwVr3x8GVHHuyswhtN_1uoJG5qh33kvN1pUHRUv pG78uODX2B19Etm.ank5x2Swgs3ilqjBpUcwm5mJ90h_FNpOqvFhqUKEpr5j3d5mBCwiwobco6mG sdNwpyNWrO2BrtX4UoyIN5eiKtUHHtqbPS9bOHo_1XqKocUqkwUGzTTYEfQDA2ohE5EmCr2oBjMM OjDPp75eHPP0r8Kb2fFqX8PvzFrijonqWOUB4R3P0PAW.XQhWxyaZ4eaca1s4weWmD6ugKBLVCFZ qT9qb9radILHqU1Nwde6UXQD.SiZ2bb1dhHM2kYnbw9X095Gq69NCIYZ_PyicIoHtypGV5gkT..G KOOSKSBkTuVQ0koe_2HnVzLsdgAX4Hr.vo7nyMsrDuJdTiqIwp31hed9IBvzwp3pD5QHG7znmfND FsBBsiyw2uDPt0jr5yb6TfNFydQtUgbT7FkokQdoeEAV97cpyJkSUwNet61zX5T3HC52tOXtA_k8 MYGKuID52gN1o1UQltHLd3KbWdY.E9NhNIBc2FGXrpmPEHITPXn3ATVFHB82r7ZC385r6ZpRpa7S Xtxs4JLOJq45T1_8q4Ywz0kNqmWdrhlkh2SbnrKyAbcG1TYyAamrhLoOtBP2si4qRVjIg8sK3IwE iwoJJZ1FG7G2.jXvBS7oYmQ6vA37ky1HrRCRqHsfjPchZ7OAck__KEsFPrREf19qhTlJKH41_dXh 7jKALb8njjGer_gytKBLy05WB3jAND.18o2r6MWXkze2O_ElFtAb.UCrUqunYnCRpeA7jjreu0e7 ywf28uupedOsYEWXLJRhwF.66PkSq5NUj9Wr1R2Bq3IEnzQ6biJnL_AP6srKRuZKJRGoyif1Jq4h eh..42hzI8Zuj7kGg8rp3hrLxJ5J32XAqBvcy_EWyn52sefrpaX6mPzg.aMPbTKSeMG4SvkSvsPW eRJYYnXCHRLa0nctuadQ6p9bsOSBHAnCHkRxbYX0_rf3lM95UMNgU3uWFYJpll5TSXo8I_NCodE4 hx7p9xxre7O1QNS1_AQ7DzXhgWANYcNvdVEPZd0h90Qd9NLSKoYIhK4lRNzx.ct9b4aF7a.RgftN E7tdVIzCKVTbsJOmdljDgE4kMEjhY9t3jU_HjSoSvF5AhBJbmy7DAvug32j12wupLt_x7eYG_th8 Ge4loFBLd2TdjTLhmj.Qq7qf6dtVywk.NIEcR3cGT6IMBOQ3wmJ949kgJN8MsZ_J3XRtEVFKHHla vm4QN0UwrwUR0vT7Os_aSZHWYjTRiMDE3E4weDvyi1EbJJDu530nucZDQici1pWX_tk86p0ZbgRZ CBGuz0E1SYKGpMQLCx6_tzH.7Vekk8yZUGmiv9_oG0ZDC7O22lu83k15Am4fVef6HDdsXVfJo8h. 7JacxCEbZEQFJkEjFU3jkChvMXJo0PCPLRA8VDm71O3Xe3tHED3S5Hzt2I4i3.2LblEHQGOmj6_h pDIDP7._GJbWd8wrR_g4toQ2t5qbSHYcSjK0ex8IT_J2F._PN2yCXzVS24Fn8ZI_cAXTOPrVIo_p TA7r.rRMHBsm9vpl9vjRmyUH0VnNu0U_B4AhzK6CIl6UpG5PngHGhnlJPbSJakiQJpeh2iC_Upgp _w8pQHNq8cU3BdbvoNfB25psw1a.HYjRp8R9cwi4bOBRacQay2KFcSNlE4D_wrgWptChDT6si9Ks oAvKfewf2ERVANxlChlAuWjebNdmrgl.PgvzctnaibcKHaFiDiaCzPjLDFhYGOxVfhuXqSoF9bHy YInLvTAaTZ7q.EglTC9I6iM.XjzRLOtsvwSd1RldKVly45PzmRlIpaRdXd0uGapb6WB2ez.5XY9Z 086KjxCFwAKoOkmYjVwsAVSP1BJTyrBsdu.smoXVTIxT5Ybsi8nV_GHh2hJK3G_OI8DVgr2aJy1X t_.9vGyTpwAUOnJd8gfCtzhYLutwWc5j1FP.DngsniqtaGv3DpzZ1m1opxi75FCDGd5OHz5Gh9Oo CjOEDGZR9rAu1Gc8.khfU.bQSyJ87vGIfDEAEGyY39uXvHyoDdYNZ0ihKiGliPay1i22.Y5TOuJa PW2t6jsz9I0.aCE0WDP8i3mmy3idN63eI5PoVOhj286E9ezj28UJzofoo1tG4LKCyvmtHgKnqXPI JjNuAbAHqpTT96hXvm0g- X-Sonic-MF: X-Sonic-ID: 97381f05-9a3d-4f34-bd78-c7f9e847ea25 Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Fri, 8 Nov 2024 18:16:50 +0000 Received: by hermes--production-gq1-5dd4b47f46-bxhh2 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 2c56abce08fd9a1392a762ae31f2c3f3; Fri, 08 Nov 2024 18:16:46 +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 \(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: <4c29d5cb-0a31-4131-a3a9-846fd4ce926f@FreeBSD.org> Date: Fri, 8 Nov 2024 10:16:35 -0800 Cc: FreeBSD ARM List , Current FreeBSD , FreeBSD Toolchain , Dimitry Andric Content-Transfer-Encoding: quoted-printable Message-Id: References: <74468E62-5A74-4FB4-94F6-599E5BA3A9A1@yahoo.com> <4c29d5cb-0a31-4131-a3a9-846fd4ce926f@FreeBSD.org> To: "mmel@freebsd.org" X-Mailer: Apple Mail (2.3776.700.51) X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Queue-Id: 4XlRwg4cQTz43cR X-Spamd-Bar: ---- On Nov 8, 2024, at 04:49, Michal Meloun wrote: > On 08.11.2024 4:15, Mark Millard wrote: >> [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 >>>> . . . > Hi Mark, >=20 > Please see https://reviews.freebsd.org/D47485 Wow. Use of the likes of: #ifdef ARM_NEW_PMAP . . . #define VM_MEMATTR_UNCACHEABLE VM_MEMATTR_SO /*name is misused by DMA */ . . . #else /* Memory attribute configuration. */ #define VM_MEMATTR_DEFAULT 0 #define VM_MEMATTR_UNCACHEABLE 1 +#endif and later versions of the header realtive to VM_MEMATTR_UNCACHEABLE goes back to: QUOTE author Ian Lepore 2015-03-26 21:13:53 +0000 committer Ian Lepore 2015-03-26 21:13:53 +0000 . . . New pmap code for armv6. Disabled by default, option ARM_NEW_PMAP = enables it. This is pretty much a complete rewrite based on the existing i386 code. = The patches have been circulating for a couple years and have been = looked at by plenty of people, but I'm not putting anybody on the hook = as having reviewed this in any formal sense except myself. After this has gotten wider testing from the user community, = ARM_NEW_PMAP will become the default and various dregs of the old pmap = code will be removed. Submitted by: Svatopluk Kraus , Michal Meloun END QUOTE So 9+ years, with after late-enough in 2016-May being with unaligned access being supported. > Unfortunately, I see 2 problems with llvm 19. >=20 > The first is regression, the compiler generates inline memset() = accessing non-aligned data with sub-optimal instructions (with word = access). This regression triggers bug in the kernel (which should be = fixed in D47485). If I read the just-above right, the LLVM 19 memset issue is a sub-optimal issue rather than a its-broken issue: The VM_MEMATTR_SO use is the aspect that is broken in the area. (Given the below issue, general testing of the use of VM_MEMATTR_NOCACHE instead seems problematical.) > Second, regarding "panic: acquiring blockable sleep lock" is due to an = bug in lld. It mis-links the ".ARM.exidx" section on the output = binary, which is used by the stack unwinder in the kernel. > I don't have a fix for this for now, so you have to use the linker = from llvm18 as a workaround. If I read the just-above right, the .ARM.exidx issue means that main [so: 15] after the LLVM 19 update is simply broken for armv7, at least for kernels, even with a kernel avoiding the VM_MEMATTR_SO issue. > I'm not sure if I have enough free cycles to manage both issues on the = llvm side... But you have already taken the analysis far beyond what I was going to be able to figure out. The major reason I still have armv7 active in my environment is to notice when some of these sorts of oddities show up in my simple context and to report some evidence about them when they happen: some earlier reporting. So, my armv7 context is not really broken by being broken. It is serving its purpose. I'll just leave the boot media as-is for the world (so: pre-LLVM19) until I have a (then) modern kernel that again works. I've got older kernels that work for this context that I'll keep around for now as well. [I've dropped Doug and Kyle from the CC based on your analysis.] Thanks, Mark =3D=3D=3D Mark Millard marklmi at yahoo.com