From nobody Sat Aug 13 00:16:12 2022 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 4M4LgS10lrz4Z10q for ; Sat, 13 Aug 2022 00:16:20 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-20.consmr.mail.gq1.yahoo.com (sonic314-20.consmr.mail.gq1.yahoo.com [98.137.69.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 4M4LgR3sSfz3BtG for ; Sat, 13 Aug 2022 00:16:19 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1660349777; bh=bk/hVOdh8NyqsNPM1otQ35RQAFzHgsAbwT18NeaCLso=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=qcjfMyPJz3TvxooYuEaC1dvefqzdom5q7+pO508yOuwgH71+lbHvPp2wNRzkXYltfoCmXAx+oVOH7IHdNys4iYGWx1abgFCXrs+K+lQt5SEavQWBISdb0tVuZmM7d0nhnE0uX3EQxFBrOTk18lk+NkhPv/4uQHkHoIOYwF4DXQyN9PmGnSQpM7/1kbTyDyLiQFbemcJtNtgJSObcdudciGqxksBWCE5LGxVHupMgEa5jTfQtOLRPmYA2fhtzqOJeOZv0n5zWLsMlOhhUoe8OqEaKfnnEHPwhEbPrlf5j7LlNGhIOH6Gn5o4cwVYyziln/XQArDbTdb0F4CBEb4tV9g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1660349777; bh=BBxE74IQi2Tg/8+UsgOcyo+F6AS008LxOrGntQpXobd=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=D9eZ6AVJiXxbCj31M0xMQBXdX3fgkqp6pJ2t17P/f7b+igMJiDnFHBjPtsNzEgVZ0z75XOXJuf6R+4U7Medlqzv8xdhA5+Yofh/gPjeXcyJ+OlsDHdprMwcGBsr0xH1iwda4jgZSTbz3q7OumTIb9MQJVNzHPbvD+5KHtNTUvDY2dZ8cgffocJ/5p+j59W6gzcURS/ddgwm0JQG7ZcS3/o+HVVhpFXFwP0uQo1eFJnzcknnvZdahX5gAZrElVpP6Drx4O2M2kv7dTb/YeZVN239lUKhqLbQ4+j+DXNfOEPjet+T6ia5SUA30IU/NG3qlje1iKExbd23CERbTelQsCA== X-YMail-OSG: WadpHvMVM1mgvV9Gh4vLS7N9PSfnA4rAaw8yB.uR.QZuXiu4a2uWfTy1pHpJ8Xu xEpJZ6voxGkEKut6IMjKUWnbzcMFgCBruEs4yGRfyehlD_7120n9JJWW3g5uheL7Sk5uryNCIUp4 T5MQ57VzeKvOLD2E0XgEz1JgHuGwWl8p.j5izmRfS7C4.tEI5VyA1OEM8uupHVxp5vekhpH425Mx NRY8afOsPUIWynJps.zsnmY.ryVeXsxRPiAF951P8YnzQwKD85vdCTp5zAgMwkIK9IyqLhNxXLcw iqzQZvkCZ2tvu9PAcfsCFSqKlvSxzQFtpqS82AnAXts0e.tlBfPiCX9a_0tbUcP5EroZKdsHsGDT 7OBrp9oXWCPvdt8Y.xAPjreiOWp6LJr1lOPf3Zj1asqgAsMp088kptXL0ePQKeWuVCFkss3wVpge 1k1nvP4DS6X3y7DdHtA2BzMm9tHD0pq1TX3eNLVCRzLqGdWVCHF4tJhgIQYxczOEDgiLSqbFz.DI hENkur.adQ4c1p9lFFhw2WEHn7cJefZG6gpB92yQaSJj8fuN1Kj0wp0WCUZuBdTBvTR2NxH.UmU_ vcmsUDj0sW_5f70NpWBRuC4A5E_7n2f2XyO0t7Ffz9_AY1YEXzFpt6BQbkI8DW1VXx78V_e2hDeT laGeP8ur.3cqtj1GErJZfI0fTn1ZSsVRMudVr9ebyjZbyJfgsnEcMFiIkHOKLzalxllsZqNzMdGH w5vWIwesW6uHEVM9.Rgc_LvIX8Cln6uoCCruWv2RRPDefdrzI4wpWBInpAT4YW6QY3t685Tirpoa sdfzNB2v1rBY77DZ9rEzFXK3GF0EEdHXnUNNnbOfH6npJNWtpJm3N6kob0dXbJ0Ah9gThO7ONmFQ PmcmeKohLUMBnapUmptQ01oFjrWHPjckhGfy2m01dcjlNHfaMcbfaTXMsJdK4ASuJB8UV2fsxrLu jnx.iWGa9s_MA_vMlLZVmUHBXSQI2No8ui4Jr7lsIXkRAc6JMsHNg_U2W1uGhmVmsuJp2k2is.Cz QCSZCANe08umDE3N7FEbKEKUQlTIfixSsEEhnfRUHJqgBYN79wBhEy0oxNR8HljnEGdEhiMvix9Z woLINREMTwOQDG3.7ItuF5EVGqGbNTHyPyDm46rzSaPPBJJybwfTTumy5CNKiZPzH0yALyrX0pBh Z1liQvLpPotAF0n_2His.YBBefqlatUQuIriJEsZuEqJZ2pyTbPRo4aKJ9poFMD74yaVki9fEAQ_ BxA_M8iRVMOJKsF1syyrhiYu7AUogCe0bPaTPwKyCFwMpZm8Qvw2Dp06PvlStTXESkRr7W.TLlGm GoDqx6S7By4tg_x8wLUDQp32el85Iic1d8NG24WFfneag5ZtQxyWFECqLc0mdzb6Pmj4qe5gvM9O NPCDCiTOIM.bMY99Y7FlJfggkTh_.HCFf4zd19xgpQep0qzJNRPP.gSc4voEVxCWTjX1BDqZHONE 1F2ScYcOTWdt1Z7uUqd._4tGP9XYZ6Q7ojAWeD1wKDPHnRxo4kkSmvKoAvunyqOBIyqSk4uhtFms hEFqGBij679f3nygTvwTeECGKFKBGHVe9nL9l3FaBsC8uX8LsBwfALIfAuCOyKAMsA2jYhfpDdkJ N278.5PffVrrvsFvKpW5ZxfASFBoAhOR2Fl55KniN0TFsrbk321HP57_xTeF4L7RIF_uIntuaFCj Nl3ESiCGL80R77yJwI47HAK5AKmL3rskvBip7GWJgzeDimYuQ4e6IbhxyzyUUwgbmPU5c867HZOj 1Wq2lyQ7vkkB8H7rQvh7z57PjZQXKZ2NIWE_BOR6n0pr3DfzQAj5Drz63yl1xc_RxtlbHkc4NwGx VNgwFV.KJUpYbmPaL8rYKsEqh6cd12RQZJKThdPKeJKvmBWS7qu..q.VA244jKnO_PowC2mV.Vm8 bc7HqnQ1kpxdtU15_b9nHkhIJQiGdjsoDwgdR7ise2Dq5.izzepdngzTm7UX8E0T5EHESW10rHZv 2.CysrgUtzWhx1voOK1nAWjxBbiDYKirmnT5gl5YDJ6YjHpVFP8I1IMi_z3EbmCY6Uz1EdgrEWko LiSyR_eGR8uwEKLLmwyhf_ThcC_JQLDHrlIQmyzyikT8S35vKF7TM77_JFIsBCwzLT3Bb2967624 KYegxvFLbg4htUqfNqwOv5xoEDtQczdy7JUJiKtbFeh_zYusLlWiblLlOpYs2_j5SrMboK2yS88T cs46ykJntglEvTbG9HlyvDeKuNb0UGLZRReR.MQyAjgZAv9WCETdKkqS4K5aNQ_I.JNa_LX9gsvD xyjaopS.MpUjYNIUD3..SxbG1r4ywsYob_WjzGBpbogFMsjmCSsljBlTOkonRynbt1pL3Fdc3BfN gueDFcRu.cpxJxuL9KDU- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Sat, 13 Aug 2022 00:16:17 +0000 Received: by hermes--production-gq1-686964ccb6-8l9xn (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID bd257bcf7abc987ecbad0d2016e5016f; Sat, 13 Aug 2022 00:16:13 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Looks like the arm 20220805 snapshots are still odd, so probably kern.geom.part.mbr.enforce_chs=0 was still in use From: Mark Millard In-Reply-To: Date: Fri, 12 Aug 2022 17:16:12 -0700 Cc: Warner Losh , "Rodney W. Grimes" , FreeBSD Hackers , freebsd-arm , "Dr. Rolf Jansen" Content-Transfer-Encoding: quoted-printable Message-Id: <944D4959-780A-4A45-B8F7-9F3E00741E48@yahoo.com> References: <6AF28022-A8E7-46B3-B64E-99D217E9B6AC@yahoo.com> <0E0083BD-A749-4112-8FDA-62326EA95F8A@freebsd.org> <20220809181513.GG30607@FreeBSD.org> To: Glen Barber , Ed Maste X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4M4LgR3sSfz3BtG X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=qcjfMyPJ; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.33 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.990]; NEURAL_HAM_MEDIUM(-0.84)[-0.837]; 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]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.83:from]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_SEVEN(0.00)[7]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org] X-ThisMailContainsUnwantedMimeParts: N On 2022-Aug-9, at 11:55, Mark Millard wrote: > On 2022-Aug-9, at 11:15, Glen Barber wrote: >=20 >> On Tue, Aug 09, 2022 at 02:06:14PM -0400, Ed Maste wrote: >>> On Sun, 7 Aug 2022 at 18:43, Glen Barber wrote: >>>>=20 >>>> Will do. I=E2=80=99ll commit the suggested change to main = tomorrow. >>>>=20 >>>> Thank you for your vigilant investigation. >>>=20 >>> Shall I commit the enforce_chs check now? >>> --- >>> commit 6ee7d69e6b526f35789b23ba570025f1c3b39c1a >>> Author: Ed Maste >>> Date: Tue Jul 19 16:47:49 2022 -0400 >>>=20 >>> release: ensure enforce_chs sysctl is 0 >>>=20 >>> We do not want CHS-based alignment for VM or SD card release = images. >>>=20 >>> Sponsored by: The FreeBSD Foundation >>>=20 >>> diff --git a/release/tools/arm.subr b/release/tools/arm.subr >>> index 6e4ae731a0b9..01c5303cd4e1 100644 >>> --- a/release/tools/arm.subr >>> +++ b/release/tools/arm.subr >>> @@ -62,6 +62,10 @@ umount_loop() { >>> } >>>=20 >>> arm_create_disk() { >>> + if [ $(sysctl -n kern.geom.part.mbr.enforce_chs) !=3D 0 ]; = then >>> + return 1 >>> + fi >>> + >>> # Create the target raw file and temporary work directory. >>> chroot ${CHROOTDIR} gpart create -s ${PART_SCHEME} ${mddev} >>> if [ "${PART_SCHEME}" =3D "GPT" ]; then >>>=20 >>=20 >> Good question. Do we still want to ensure it is set to '0'? I'm a = bit >> confused from the back-and-forth on the original thread. >>=20 >> If we do want to ensure it is set to '0', yes, please go ahead. >>=20 >=20 > Hopefully this week's experiment with explicitly avoiding BSD > and freebsd-ufs having the same offset inside BSD (avoiding > both offsets being zero) will allow the UFS labeling to work > right: freebsd-ufs being tied to a unique offset inside BSD. >=20 > I really doubt that using kern.geom.part.mbr.enforce_chs=3D1 to > cause the offsets to be different is reasonable, despite that > it happens to make them distinct: the freebsd-ufs offset is > better controlled explicitly elsewhere. >=20 The experiment with this week's snapshot is working just fine. It is based on the update: QUOTE The branch main has been updated by gjb: URL: = https://cgit.FreeBSD.org/src/commit/?id=3D45add40717c24ef0b5418664fae1718b= 15a0422b commit 45add40717c24ef0b5418664fae1718b15a0422b Author: Glen Barber AuthorDate: 2022-08-08 14:59:29 +0000 Commit: Glen Barber CommitDate: 2022-08-08 14:59:29 +0000 release: fix alignment for arm SoCs =20 MFC after: 3 days Submitted by: Mark Millard Sponsored by: Rubicon Communications, LLC ("Netgate") --- release/tools/arm.subr | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/release/tools/arm.subr b/release/tools/arm.subr index 3dea17339958..25d4640cc26b 100644 --- a/release/tools/arm.subr +++ b/release/tools/arm.subr @@ -77,7 +77,7 @@ arm_create_disk() { chroot ${CHROOTDIR} newfs_msdos -L msdosboot -F = ${FAT_TYPE} /dev/${mddev}s1 chroot ${CHROOTDIR} gpart add -t freebsd ${mddev} chroot ${CHROOTDIR} gpart create -s bsd ${mddev}s2 - chroot ${CHROOTDIR} gpart add -t freebsd-ufs -a 64k = ${mddev}s2 + chroot ${CHROOTDIR} gpart add -t freebsd-ufs -a 64k -b = 64k ${mddev}s2 chroot ${CHROOTDIR} newfs -U -L rootfs /dev/${mddev}s2a fi END QUOTE This is unlike when the "-b 64k" was not present. This includes rebooting after the initial boot, unlike before. This is for dd'ing to USB3 NVMe SSD media and testing, for both of: FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220812-6a70a0c8bfa-257314.img FreeBSD-13.1-STABLE-arm64-aarch64-RPI-20220812-eb2a9b78586-252107.img (The -b use implicitly also changed the size of the freebsd-ufs slice, making it smaller.) For the media growfs is involved in the initial boot. glabel list now shows ufs/rootfs bound to da0s2a and does not show a ufs/rootfsa at all. There is no binding to da0s2 (BSD) shown. # glabel list Geom name: da0s1 Providers: 1. Name: msdosfs/MSDOSBOOT Mediasize: 52428800 (50M) Sectorsize: 512 Stripesize: 0 Stripeoffset: 1048576 Mode: r1w1e1 secoffset: 0 offset: 0 seclength: 102400 length: 52428800 index: 0 Consumers: 1. Name: da0s1 Mediasize: 52428800 (50M) Sectorsize: 512 Stripesize: 0 Stripeoffset: 1048576 Mode: r1w1e2 Geom name: da0s2a Providers: 1. Name: ufs/rootfs Mediasize: 240003866624 (224G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 53542912 Mode: r1w1e1 secoffset: 0 offset: 0 seclength: 468757552 length: 240003866624 index: 0 Consumers: 1. Name: da0s2a Mediasize: 240003866624 (224G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 53542912 Mode: r1w1e2 # gpart show -p =3D> 63 468862065 da0 MBR (224G) 63 1985 - free - (993K) 2048 102400 da0s1 fat32lba [active] (50M) 104448 468757680 da0s2 freebsd (224G) =3D> 0 468757680 da0s2 BSD (224G) 0 128 - free - (64K) 128 468757552 da0s2a freebsd-ufs (224G) A difference in behavior is that "gpart show" does not report the ufs/rootfs labeling. For all I know, this could be expected. glabel does show ufs/rootfs . I do not know what would happen if only the size had been made smaller but the starting offset had been left at 0. But the evidence from the "without -b" and "with -b" testing is that having starting offset 0 in BSD and the same size as BSD can be a problem for the freebsd-ufs slice as processed by the initial boot, at least when ufs labeling is in use (here ufs/rootfs). So far, this week's snapshots look good to me for the issue having been avoided but ending up better aligned overall than when kern.geom.part.mbr.enforce_chs=3D1 was in use. If a larger alignment is needed at some point for freebsd-ufs, adjusting the pair of gpart add arguments "-a 64k -b 64k" should deal with it. Notes: The USB3 NNVMe SSD based testing was with a 8GiByte RPi4B and so does have the addition of: # # Local addition that avoids USB3 SSD boot failures that look like:=20 # uhub_reattach_port: port ? reset failed, error=3DUSB_ERR_TIMEOUT=20 # uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port = ?=20 initial_turbo=3D60=20 in the config.txt file that the RPi* firmware uses. (It is for a separate issue --and FreeBSD does not have such in place by default at this time.) =3D=3D=3D Mark Millard marklmi at yahoo.com