From nobody Sat Aug 13 06:04:41 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 4M4VPT6YDYz4Yg3D for ; Sat, 13 Aug 2022 06:04:45 +0000 (UTC) (envelope-from nicolas@lautrecote.org) Received: from relay8-d.mail.gandi.net (relay8-d.mail.gandi.net [IPv6:2001:4b98:dc4:8::228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4M4VPS3zWcz3wTS for ; Sat, 13 Aug 2022 06:04:44 +0000 (UTC) (envelope-from nicolas@lautrecote.org) Received: (Authenticated sender: nicolas@lautrecote.org) by mail.gandi.net (Postfix) with ESMTPSA id D16EA1BF203 for ; Sat, 13 Aug 2022 06:04:41 +0000 (UTC) Message-ID: <2ec46a85-43c8-7a77-bf54-36e50657b7f3@lautrecote.org> Date: Sat, 13 Aug 2022 08:04:41 +0200 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 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: Looks like the arm 20220805 snapshots are still odd, so probably kern.geom.part.mbr.enforce_chs=0 was still in use Content-Language: fr To: freebsd-arm@freebsd.org References: <6AF28022-A8E7-46B3-B64E-99D217E9B6AC@yahoo.com> <0E0083BD-A749-4112-8FDA-62326EA95F8A@freebsd.org> <20220809181513.GG30607@FreeBSD.org> <944D4959-780A-4A45-B8F7-9F3E00741E48@yahoo.com> <20220813003034.GP30607@FreeBSD.org> From: Nicolas Caillaud In-Reply-To: <20220813003034.GP30607@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4M4VPS3zWcz3wTS X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=lautrecote.org; spf=pass (mx1.freebsd.org: domain of nicolas@lautrecote.org designates 2001:4b98:dc4:8::228 as permitted sender) smtp.mailfrom=nicolas@lautrecote.org X-Spamd-Result: default: False [-3.90 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[lautrecote.org,none]; R_SPF_ALLOW(-0.20)[+ip6:2001:4b98:dc4:8::/64]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[2001:4b98:dc4:8::228:from]; TO_DN_NONE(0.00)[]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:203476, ipnet:2001:4b98:dc4::/48, country:FR]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[] X-ThisMailContainsUnwantedMimeParts: N hi all sorry to "troll", but how can I subscribe to this list ? thank you very much Le 13/08/2022 à 02:30, Glen Barber a écrit : > On Fri, Aug 12, 2022 at 05:16:12PM -0700, Mark Millard wrote: >> On 2022-Aug-9, at 11:55, Mark Millard wrote: >> >>> On 2022-Aug-9, at 11:15, Glen Barber wrote: >>> >>>> On Tue, Aug 09, 2022 at 02:06:14PM -0400, Ed Maste wrote: >>>>> On Sun, 7 Aug 2022 at 18:43, Glen Barber wrote: >>>>>> Will do. I’ll commit the suggested change to main tomorrow. >>>>>> >>>>>> Thank you for your vigilant investigation. >>>>> Shall I commit the enforce_chs check now? >>>>> --- >>>>> commit 6ee7d69e6b526f35789b23ba570025f1c3b39c1a >>>>> Author: Ed Maste >>>>> Date: Tue Jul 19 16:47:49 2022 -0400 >>>>> >>>>> release: ensure enforce_chs sysctl is 0 >>>>> >>>>> We do not want CHS-based alignment for VM or SD card release images. >>>>> >>>>> Sponsored by: The FreeBSD Foundation >>>>> >>>>> 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() { >>>>> } >>>>> >>>>> arm_create_disk() { >>>>> + if [ $(sysctl -n kern.geom.part.mbr.enforce_chs) != 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}" = "GPT" ]; then >>>>> >>>> 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. >>>> >>>> If we do want to ensure it is set to '0', yes, please go ahead. >>>> >>> 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. >>> >>> I really doubt that using kern.geom.part.mbr.enforce_chs=1 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. >>> >> 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=45add40717c24ef0b5418664fae1718b15a0422b >> >> 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 >> >> 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 >> => 63 468862065 da0 MBR (224G) >> 63 1985 - free - (993K) >> 2048 102400 da0s1 fat32lba [active] (50M) >> 104448 468757680 da0s2 freebsd (224G) >> >> => 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=1 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: >> # uhub_reattach_port: port ? reset failed, error=USB_ERR_TIMEOUT >> # uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port ? >> initial_turbo=60 >> >> 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.) >> > Mark, > > Thank you very much for the detailed information, and of course for > reporting the problem, and testing variations of the correct behavior. > > Glen >