From nobody Sat Jul 30 06:03:31 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 4Lvv2g4PYKz4XQbP for ; Sat, 30 Jul 2022 06:03:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-23.consmr.mail.gq1.yahoo.com (sonic304-23.consmr.mail.gq1.yahoo.com [98.137.68.204]) (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 4Lvv2f0Bh2z3Rrr for ; Sat, 30 Jul 2022 06:03:37 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1659161015; bh=Ppw+3e6xglEmvzEokwq2tbg/nL+xLvhLKDH/PEevUdk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=G0vfxJnMuDx9wq+p8AoBW9aC67q2jMflHW8smJVYGRBOXr+yLT2C2VlOZiKYdVET/3ULsxBKgsjxNFv2jnhYdUq30BlYfGpWNr+WBKmsdcOdjUuEAhKZYNxYw27kxYKOCJlIs2QMCHzfFu3K808szuZioJqo7um+ip3A5hbPI3fRSiMRSZYcptXgWWPW7jNgo4JY162UElsLeAGrnRjF2fCcvNq/ItBk+tiRgIkWdhTs+7Yfo26G4P9esa2mJDgKm8eL+QMVRf902m5kG0DdgQKs8ZSqmb2iBVl0BvzSWF9j3ECdgE2bgLMM/RX84VusAjJybSvBrA8RT5oM2HMs+w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1659161015; bh=jVtjGz8pkn3O/RRCFEy47EWA5qrAqCdjpHCVPYbVWge=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=txjxUc0iMQvP3yUhPem5XZuTXqaox0Oi8sNsVSFJ2mghTH6+faO2joui+q09r7obWEnspH8BgsnzErfrl8MHNRh1fU0ZJZq/nF83Qe+ibygQRPCcBb20hQROETWSsSQXOoykrOdve0cbY71QRggt5LED0u347oK2eif0prTG5m4JuwqRgIH7kh4MGGcm6wIbaMAaQFPr8VVpQhAC1Io0QY6UahMa8wdJ3Bcx/hSQYax0IA0WksTgqA2ls5qJvT1lyjKxV4cwLEua9ydTWSSc+nPXb3Ba8J6l6+TfcnJCOlI19hSFr4/Lr0osLR70/rhD4Skm37WvvfWzmRyOW1AcxQ== X-YMail-OSG: nF.JTmQVM1lhOtAjNzUORUpDsi4Z7qQwjXvdK7PTK75oV3aSw3JI9v3bmo_Npxm VfbuVs6M73DMtfxPPwz41i6OBP_7gkVPQ_nDJe2KYGF7dwaVTF9IOdegzd7Hrnl4Ef10xS8gRti6 ULQ1TVgdBf.fDoSA9gybhq2GB_p2eZ5XLm0jgIxP3DnCY98CZGJe5kGFOFlWQ43E1qGb0mSwRzyX YC6CVMD3KmMDbfj0AoWvF6_lg1t8zkbmcfxaWS03Ow5Kd2fmdcNYo4skMSZhtzx0tOK_nJDKUOLn cCqS6o3T4iA744tDozWriyhgRm4kL4w2.IHRpYjby9l5hVYEGlsiZotgVTHTo1xCgvcB06.7vT0G 9ywpEfQ0N8nb9TIj94D2kekmorOmkw9q4t8IiZgUfRUkMVI1DhYkJLTxaSoGDbik7VA.Ql.2ZMZv 6rXT3i7PH1Y.m2BMvTiK_swGNPE7Szo7VT5WY5jVP8_FlGAPHiO3yJX2DmLaVhQYmMMXxod55.Vr MaxccbA4FJympQWHoo6UE8KIspUKaurwzEleo73rfvgbnk_ubqGm5.i0hI4jXNtsL7gCcUrzOJSZ FOr4Y8095rR01at5d5FGu0a.p9VLIB6Gi6hGrs094ImDZH7gHd0ltVCODWz8xrbqfom7CbbouupL Fg2w1zaCh8Q15UaR1HRjU.NsVWUGQq8yNymDbNpbuYWPiLNI.pklEmriDEb8FzO14qMq9aEsuFkK 6YAZM3w5FvcZMYLLNpWGD1wOt9Nij3ZG_eYUtkfXtWY0X7IZSXBxt8tdjgx3BA0kpEZ4wvuf8Ion WhZE1nDP_y6NBbBizkXnIRx_U6YcRvEQAtBBf1EyJVHmig2pR_tR0vxU7pMo5I5pe2cB_TduN7av b8kFeFwfc7upztHf8b31XrbWIUcL4ftXq25xddKm0N.1UJgGKznmqo6ElQpFuwPkLsYZ5UU81KfI FG.7mCYIbSPpYwm4MXJ4A6zkLKmKp0sYxf1LL8hRliY4hZnX58oNkYn3kUFbWUBrAab4ulWeQMRy oIlb8QoL9WC2TLBjasAZSUV_XOyeHMsk9NI1M9qZbvRYb0EKAwwmBfYtHt63t7udYj1slelxsEVj p5vvjJirRw9d92nJkKlPdfouRW5Sw0Izw.V95snu.b2LP9TxXBM2FYglhhcw.5wwCRw_VzatBJh_ jp7pvmcJC9VF3_rOQZFC6VB1UyQ7LmVDSuCpOnQw1kfRumo0gYkH5t_cj8v9Op.Y.B8RAzmdKeLE M2kc35VO.tK8CENJ4mUx.pdKlvH3MTpwCyzPm0p2ZlM0__KWZRHZnh0owSozKFt1LI3ovOpVrXC4 .YdSf.PmgG7aCM9YOU68cyDXRbAPop11Cyx_9kQEnx7HfMefIkYTkmheAMugLM_jxpWAXemIPrO6 GrfVGySxuIdfx9BqYKHSRs2GDXsrl4jNOCkeuCCQ7_YV0x2o4.OL1yTMV7v_Ev_TU4JHwyZhlALJ UZsgWES_yNJEjVH97kxYqR0t03_PsJWdF1bY8SMrd_DkIand9xHFk_cxFUxt.R40pg8VTrrY7ey8 9N.G7bkHBk57rDisO.Bsuy9rmFVN2uq3llG0CTPbn1RyodxPh3PSP.vHgx_C7J9Aa4kqLY8C4RDD 8elGwHySbyLFzsmEIiQt5.ovGJUceWFxM4hwVJk0lix0Rp_awSq2nmSFmw.C3s8hlpnIRBkYeZ1H 8dKhW7XFyDr16VahLCSacpsPZ6ZmsZkCSeLVigii0OniIuiai6mgE4_1G_kauXLNDifL2Lzr7HHe oT2ycd.61y.70i4CyLNKaC3530QPGUHaCtnZzo3vcbXqDfQ1IlCxA9wTgt8Mp2oZispSAnFTq_8H kZ1TJSxg7kf3PIz1_Z7w_CGMginVBUs2H4mEVwKIMQYwbQ9i37T8ZcK1AHm6l9gvOQrQp.NrjKSn b6yB0iR02Ws9lgmrWLNNkngap8kzkc.XtNqbiyCiaM8VWOnPX89L_Q_NHfgWwpFFBL.BXMCj69Ds tdco0dTwOsu.ooHEUriMf4AgKcs5iHCPLZ4YwRX.6cSIbm_DzHbfG_0dn1FK73hN83BrdLJzh_IE jlilWype2pwDdzq9gbcBHIFvGLPZDqOEzJm0UKeI75_iJfnctNweuILNovfUTi71oeCQyQZ45ERz EQzyEsNnnuScnBcot4CJ.WlbSbQ7RMCuExLoeo6Vl6gnV2d5yBF3GO3I0vxi3VUFjmMDmGusJCLI fcJBbdBjas9iJqMNF0KEhHRi39sv.oEZFj05d2DBwANVcRpYbZJ5uoyGn2_PHxS418VpSLyjPtQN xhCBe X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Sat, 30 Jul 2022 06:03:35 +0000 Received: by hermes--production-gq1-7b45fb68df-xzq9g (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 0f93d63cbc93d069b7c3bff7e1e63adb; Sat, 30 Jul 2022 06:03:32 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: git: 1dfcff294e44 - main - release: increase IMAGE_SIZE for arm, arm64, riscv [odd alignment for SBC images] From: Mark Millard In-Reply-To: <3B32D8E3-A436-4CF6-8CCB-6798EC7F50DC@yahoo.com> Date: Fri, 29 Jul 2022 23:03:31 -0700 Cc: Warner Losh , Ed Maste , "Rodney W. Grimes" , dev-commits-src-main@freebsd.org, "Dr. Rolf Jansen" , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <83383E16-29B2-4181-B666-B0A9C4D5451A@yahoo.com> References: <16906DFD-286B-4D59-9438-CA9CD9026C55@yahoo.com> <202207171708.26HH81bA062303@gndrsh.dnsmgr.net> <20220719204245.GL30607@FreeBSD.org> <20220729204943.GT30607@FreeBSD.org> <7E1AE740-FA45-4889-BD70-8EABB0725B39@yahoo.com> <3BF6B9DD-26DF-4C82-B2CE-E460D94F6C95@yahoo.com> <3B32D8E3-A436-4CF6-8CCB-6798EC7F50DC@yahoo.com> To: Glen Barber X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4Lvv2f0Bh2z3Rrr X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=G0vfxJnM; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.204 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.36 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.991]; NEURAL_HAM_MEDIUM(-0.87)[-0.868]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; 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.68.204:from]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; 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-Jul-29, at 22:09, Mark Millard wrote: > On 2022-Jul-29, at 20:42, Mark Millard wrote: >=20 >> On 2022-Jul-29, at 20:11, Mark Millard wrote: >>=20 >>> On 2022-Jul-29, at 19:56, Mark Millard wrote: >>>=20 >>>> On 2022-Jul-29, at 13:49, Glen Barber wrote: >>>>=20 >>>>> On Wed, Jul 20, 2022 at 10:08:20AM -0700, Mark Millard wrote: >>>>>> Would it seem appropriate to use a week (this week?) to do all >>>>>> the snapshot builds with the builders all set to have >>>>>> kern.geom.part.mbr.enforce_chs=3D0 and see what breaks, if = anything? >>>>>> (Sort of a snapshot exp run.) >>>>>>=20 >>>>>> More than just the SBC images might be involved for >>>>>> kern.geom.part.mbr.enforce_ch consequences, for all I know. >>>>>>=20 >>>>>=20 >>>>> Hey, Mark. >>>>>=20 >>>>> New snapshots for 13 and 14 are up now. Is it possible for you to = check >>>>> if the issues you had run into are indeed resolved, after setting >>>>> kern.geom.part.mbr.enforce_chs=3D0 on the builders? >>>>>=20 >>>>=20 >>>> Well, it is a mix, I think (unsure). >>>> . . . >=20 > I got a little more evidence about the type of problem, > I think. (Not that I know the interpretation to give > the evidence.) >=20 > Instead of booting the 13-STABLE media I put it into a > booted system to look at it: >=20 > =3D> 63 468862065 da0 MBR (224G) > 63 1985 - free - (993K) > 2048 102400 da0s1 fat32lba [active] (50M) > 104448 468757680 da0s2 freebsd (224G) >=20 > =3D> 0 468757680 da0s2 BSD (224G) > 0 10381312 da0s2a freebsd-ufs (5.0G) > 10381312 458376368 - free - (219G) >=20 > (I've ignored ufs/rootfs ufs/rootfsa, ufsid/* above.) >=20 > Compare/contrast: >=20 > # growfs /dev/da0s2a > growfs: unable to read superblock: Input/output error >=20 > # growfs /dev/ufs/rootfs > growfs: requested size 224GB is equal to the current filesystem size = 224GB >=20 > # mount -noatime /dev/da0s2 /mnt > # umount /mnt > # mount -noatime /dev/da0s2a /mnt > g_vfs_done():da0s2a[READ(offset=3D5920980992, length=3D8192)]error =3D = 5 > mount: /dev/da0s2a: Input/output error >=20 > # gpart resize -i 1 /dev/da0s2 >=20 > # gpart show > . . . > =3D> 63 468862065 da0 MBR (224G) > 63 1985 - free - (993K) > 2048 102400 1 fat32lba [active] (50M) > 104448 468757680 2 freebsd (224G) >=20 > =3D> 0 468757680 da0s2 BSD (224G) > 0 468757680 1 freebsd-ufs (224G) >=20 > # gpart show -p > . . . > =3D> 63 468862065 da0 MBR (224G) > 63 1985 - free - (993K) > 2048 102400 da0s1 fat32lba [active] (50M) > 104448 468757680 da0s2 freebsd (224G) >=20 > =3D> 0 468757680 da0s2 BSD (224G) > 0 468757680 da0s2a freebsd-ufs (224G) >=20 > # mount -noatime /dev/da0s2a /mnt > # umount /mnt >=20 > After that I can again use it to boot the 8GiByte RPi4B. >=20 > But, having booted itself, it shows . . . >=20 > root@generic:~ # gpart show > =3D> 63 468862065 da0 MBR (224G) > 63 1985 - free - (993K) > 2048 102400 1 fat32lba [active] (50M) > 104448 468757680 2 freebsd (224G) >=20 > root@generic:~ # gpart show -p > =3D> 63 468862065 da0 MBR (224G) > 63 1985 - free - (993K) > 2048 102400 da0s1 fat32lba [active] (50M) > 104448 468757680 da0s2 freebsd (224G) >=20 > So, again, no da0s2 BSD or da0s2a freebsd-ufs . > (Unlike gpart show on the normal-boot main [so: 14] > system.) >=20 > After shutting down and plugging into the normal-boot > system . . . >=20 > glabel list on the normal-boot system with the USB3 > SSD plugged in shows: >=20 > Geom name: da0s1 > Providers: > 1. Name: msdosfs/MSDOSBOOT > Mediasize: 52428800 (50M) > Sectorsize: 512 > Stripesize: 0 > Stripeoffset: 1048576 > Mode: r0w0e0 > secoffset: 0 > offset: 0 > seclength: 102400 > length: 52428800 > index: 0 > Consumers: > 1. Name: da0s1 > Mediasize: 52428800 (50M) > Sectorsize: 512 > Stripesize: 0 > Stripeoffset: 1048576 > Mode: r0w0e0 >=20 > Geom name: da0s2 > Providers: > 1. Name: ufsid/62e358b6cff37c76 > Mediasize: 240003932160 (224G) > Sectorsize: 512 > Stripesize: 0 > Stripeoffset: 53477376 > Mode: r0w0e0 > secoffset: 0 > offset: 0 > seclength: 468757680 > length: 240003932160 > index: 0 > Consumers: > 1. Name: da0s2 > Mediasize: 240003932160 (224G) > Sectorsize: 512 > Stripesize: 0 > Stripeoffset: 53477376 > Mode: r0w0e0 >=20 > Geom name: da0s2 > Providers: > 1. Name: ufs/rootfs > Mediasize: 240003932160 (224G) > Sectorsize: 512 > Stripesize: 0 > Stripeoffset: 53477376 > Mode: r0w0e0 > secoffset: 0 > offset: 0 > seclength: 468757680 > length: 240003932160 > index: 0 > Consumers: > 1. Name: da0s2 > Mediasize: 240003932160 (224G) > Sectorsize: 512 > Stripesize: 0 > Stripeoffset: 53477376 > Mode: r0w0e0 >=20 > while the gpart show -p on that system lists: >=20 > =3D> 63 468862065 da0 MBR (224G) > 63 1985 - free - (993K) > 2048 102400 da0s1 fat32lba [active] (50M) > 104448 468757680 da0s2 freebsd (224G) >=20 > =3D> 0 468757680 da0s2 BSD (224G) > 0 468757680 da0s2a freebsd-ufs (224G) >=20 > =3D> 0 468757680 ufsid/62e358b6cff37c76 BSD (224G) > 0 468757680 ufsid/62e358b6cff37c76a freebsd-ufs (224G) >=20 > =3D> 0 468757680 ufs/rootfs BSD (224G) > 0 468757680 ufs/rootfsa freebsd-ufs (224G) >=20 > Having managed to expand da0s2a seems better, but > it is still odd, including the mismatch in what > the self-booting 13-STABLE shows via gpart show > vs. what the normal-boot shows. The normal-boot > is of (line manually split for readability): >=20 > # uname -apKU > FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #59 > main-n256584-5bc926af9fd1-dirty: Wed Jul 6 18:10:52 PDT 2022 > = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 > arm64 aarch64 1400063 1400063. . . . So I tried plugging in the 14-CURRENT media into the RPi4B while it was booted from the 13-STABLE media. root@generic:~ # gpart show . . . =3D> 63 468862065 da1 MBR (224G) 63 1985 - free - (993K) 2048 102400 1 fat32lba [active] (50M) 104448 468757680 2 freebsd (224G) =3D> 0 468757680 da1s2 BSD (224G) 0 10381312 1 freebsd-ufs (5.0G) 10381312 458376368 - free - (219G) =3D> 63 468862065 diskid/DISK-00000000000A MBR (224G) 63 1985 - free - (993K) 2048 102400 1 fat32lba [active] = (50M) 104448 468757680 2 freebsd (224G) =3D> 0 468757680 ufsid/62e3bdbe47334896 BSD (224G) 0 10381312 1 freebsd-ufs (5.0G) 10381312 458376368 - free - (219G) =3D> 0 468757680 diskid/DISK-00000000000As2 BSD (224G) 0 10381312 1 freebsd-ufs (5.0G) 10381312 458376368 - free - (219G) So: BSD and freebsd-ufs visible. root@generic:~ # gpart resize -i1 /dev/da1s2 da1s2a resized root@generic:~ # gpart show . . . =3D> 63 468862065 da1 MBR (224G) 63 1985 - free - (993K) 2048 102400 1 fat32lba [active] (50M) 104448 468757680 2 freebsd (224G) =3D> 0 468757680 da1s2 BSD (224G) 0 468757680 1 freebsd-ufs (224G) =3D> 63 468862065 diskid/DISK-00000000000A MBR (224G) 63 1985 - free - (993K) 2048 102400 1 fat32lba [active] = (50M) 104448 468757680 2 freebsd (224G) =3D> 0 468757680 diskid/DISK-00000000000As2 BSD (224G) 0 468757680 1 freebsd-ufs (224G) Note that ufsid/* disappeared. So only the boot media seems to stop with: =3D> 63 468862065 da0 MBR (224G) 63 1985 - free - (993K) 2048 102400 1 fat32lba [active] (50M) 104448 468757680 2 freebsd (224G) (no BSD or freebsd-ufs or such). Unfortunately, the 14-CURRENT media seems to consistently get: . . . WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/ufs/rootfs [rw]... ugen0.2: at usbus0 uhub1 on uhub0 uhub1: on = usbus0 uhub1: 4 ports with 4 removable, self powered Root mount waiting for: usbus0 Root mount waiting for: usbus0 uhub_reattach_port: port 3 reset failed, error=3DUSB_ERR_TIMEOUT uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port 3 mountroot: waiting for device /dev/ufs/rootfs... Mounting from ufs:/dev/ufs/rootfs failed with error 19. Loader variables: vfs.root.mountfrom=3Dufs:/dev/ufs/rootfs vfs.root.mountfrom.options=3Drw Manual root filesystem specification: : [options] Mount using filesystem and with the specified (optional) option list. eg. ufs:/dev/da0s1a zfs:zroot/ROOT/default cd9660:/dev/cd0 ro (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /) ? List valid disk boot devices . Yield 1 second (for background tasks) Abort manual input mountroot>=20 This is independent of if I use initial_turbo=3D60 or force_turbo=3D1 in the RPi4B's config.txt . (These avoid variability in the actual timeout time frames in the early activity.) However, my normal use of main [so: 14] is not via WITNESS/invariants or such but the snapshot build is. So I might not have noticed and this might not be new for WITNESS/invariants main-kernels. As stands, 13.1-STABLE is my better test context. =3D=3D=3D Mark Millard marklmi at yahoo.com