From nobody Sat Jul 30 05:09:43 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 4Lvsrb3KHDz4XGX9 for ; Sat, 30 Jul 2022 05:09:51 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-20.consmr.mail.gq1.yahoo.com (sonic301-20.consmr.mail.gq1.yahoo.com [98.137.64.146]) (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 4LvsrZ2vKzz3C9C for ; Sat, 30 Jul 2022 05:09:50 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1659157788; bh=xjWXWNYN2XlzJ985i3jyx9H1feRQx6nmOwO8grqf3Zo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=GmmuFGoJEFEoZCYN3XUi0NasM6Ug67yogZBZLT/APpQd1Iq8cJjERRlxxXDhYn2zg73VtF6WwT7PfW97nFYXPtz0juXtXRceEgDbv7MVvgyos4yZk9+2OUXvlLcq+XbLesnLzL3T93bTg6we4Zr2kT8X0BHQduo6hNzjrBHj+xUYA74WjRtMyQVC37763gUBqJJw6BxRBXrgiAdnliGwKMVYgE2DEObaDAnGvl86MvYB/TzbGzz9a1IeULbspcDRrqAOS/3IgU4Yz7YUd7fr9pKp5b70BAvy4rVOzXANgNi+dxVq8iRPvJuXeYb42uHRzF7lMun004bQ7xoD4ZuHPQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1659157788; bh=ilB/LJ4tksUD7zUaVDj1+z9qezNqDi3QLSIVQvzq/fA=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=COOW9EzWMeA9Ty+b2Ea/K9jB8Hm5X/79FsWXJHTLkcBMcURBVbosKbokUZU7eAYfx3GffzohsTpUM/ZGVBB4yyFmJ7Ce9GAGjywq3pXIKCEm8Y8/LOWMYZionrf0OZ2LT/VwzGYEnwFd5PQpGEVv0SvG9arblTzS8JLL/PDrsVwDIqeHgHJzHiMLbKTpKQbNPn80Z2lwjD1BPnVGQkbhcRMaX5gO/dp9k5oMibmpEOL2YRye26mkEURU/Fpne9sDN+rMhkKJMK2QCi0s45J78syMSLjQEd/8XhrYIbzsLe1dSZuFv0AkKtmEWjECxvMcJxe+dcGWMW08Hncy0CMd5g== X-YMail-OSG: wd_KdvgVM1nOKawRDLNg1l5Q4qTMZSSH_jVN3vDYt22L.ulzN1f9XvIHhlyQ5ac OambhCIFLMWc2Lne8cnSgSCOi0MQk1FMdjjjWy104v77Za7kg8GIpC4gu45GjK7hrK_a_rp0EvO7 u6oghn67XPx0SYVI9gphB8AGYvdfJ7cM1DDZVsDaQk9EfqLmJ1UNPIbPk_Qf.OZJQlSr2x1V7NC9 UQ9zFpq_8cXzb.UlZxH.EQ0Sb3Q9oLotK3tZIC4Hjst.HfuXYly8_4XMxS8sFpbSUBmwzrjjLKsm TjIHywX8yXPSgX45LuWKBNKOHxeGg5p3_dFh8N.QiepLzx4DPXbbPUBn8PMqu827bU78iqYHMDgc ZueOaQPP8XxvDR.n6mbXFcPLi28lPKuK8XxGsNybQHrloTuzde5hcmHb2gMaCnn4h1nq2zAtwesy mdilEVa5N8dcUxfNGqc9ffbdkcrIdwR6_JI4ZcJO3GqD03hKqBBINI.8VaZycir1bbQzsPeAtIlb RfXjtIrM3vGZGyb9vuRscgUqdz9xopxrshSLn5sHMGwOBPAIEbhvOp0AXz2ksTZciUc9FpLaQKDq BOR9Nh7sVru_r.DJsjbL6DJeisyLmnTiTVYvR_O_WhifNLshUs8KQokiGIS0DUzNGtEKSpMFTDVK xF3n_XB9m4_G.JK_VVnsjzlu18hBaxe6NS1A6QKPgQzxRPHDi02sEjSFYnmWqBUbYSdMwP_ZwAc. aaSE49m8mrmpZpJU7Bzu8mTRvQFuOoxOyJVaCBahf0XVevJuMfrF0eBo.Y966iWiBduUjCl4Zm6_ 1nDKOfGKgHmyza1aPYCiVLPLY94FwSliE2M55dVtqBy63SJgXXgfg_LWmS_N45MQqVC_ODfGPghW SVYwiqnIg2qWJKTr_lPzdSML4l0s1PaivNhLuLGyJQC4xqQwQs12FZKH5lG_RcWJxtyD837vgxAL rjwR8UhA.mGb8364LfQ2OMJhFFcBjxKrcyaefVIkxy8Up9DG7eTr6fwO6Y.qd1tB7csP2iJZAah_ laPNYuBZXolUY7c3OGzgU.sLdG3ydRY.58CDU.H2fZSH0ZpTiLc.6fHRGxupUcwRl2fQj4_7gqSx MnqOt.0lifhFJu41KPmYYO89Gchwgzs43BC.JnXZJX5_tZbA2hvoZTBX8yt_fjbFQjUxzLVoLmLd 0c1QIUyvsnnbNNx9N7lO3PXhYBfhkqJCALGbPKtW9PAEVtBNJCCZmnmSY7ruVtE9Z8rwR0y1su6_ 6ZLyP_dw0LDX2pke6V5_ErJq4zGc642iGiohGAEgqerJWzILestURz5k.1_qU1FO_StW7wMhyQL2 UBFvC1Hx49ceS3ZYmAe_T06QvVUOnLitPs.Y22wAgupD4BsoEatjuyJ1ggT4v2nzXZTGhgy6MBLv pw8HxCa.U2o6pczVb6VWabziCHfL0RWFSRhyxZ3LwIT2e79JJpDfzbvullCqZxQog.76TEirpQRg OhMwdTR5aic95.mC_NVT.B69vqm2tWGy9TzD5JmpHdVyvHH_tmtlB4.qpRZ30dx5OcDDsyMURnnn 8CPGFXpP3wk4amDlq0Xwo23i2HDUNFlapIz_oSPJPpJtgqL7c9YCRFr9gWP5uSIm9yqgpBs.2OZz B7oXO_SQl3SCzKs2PT2aQa1vjSiGJfpxWN42bdK4w.YZhajoPfkiadrRLKfmrTnPidzBA2bcqp9t p9PfRIfIwITK2eedwdAGF3MBrTadvAUPeXjiOfGwAKBK4T6rrHgkWA26deZgFRiQ4_pP10SCI_q_ Y76HO15EQmt4Ny8nKxAjmH8XD5.Ir9rl3c4vNOWyabw3.BPlmsJiGUSiDD0Pvs0vvDRONEBagWYi 2ORlPw7ElcxDfs7L_Ml5X2pgSkgp1asSTyjM2M.vjPUuGnu717JOxoxJM4o6IC_eOYiyFIkjiTSk 5G7JKBTG0DUwbWwZOdVmCsqm65ReDZeAgVXOypNh0jPRrEAirtsXLphuz3pNrwABcHM3EoI9vGRD n79ybvQkvTV2kUjiBUwzyDXESMmdSk_hE44Ht1eL0gyi6W0oXJQT9DFJyTUgychaxeMvG2NO84cy rjwI.hYb23H4zjKLtUfIUDzLONebsIRE2rk3_oZztf0eHoE5i1gAL9Nt..VZ9.y245.5rO83dZCe 8j7VkJm4qLl9qAt5avmWNHSEupY5U1h0_YcAoXaAgsF0rvdp5PWtLaQyWwW_9kaoMO2iJyE4xXRY 88LYamZF4LdDI8i13SkDGxx0zz4mcrgFbkNh1qz58lQ8LnJ0gIFXq25US_sooZOum_.rWkCnFJAh sRPlv3tQdJg-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Sat, 30 Jul 2022 05:09:48 +0000 Received: by hermes--production-bf1-99ddd9c9c-lzhlr (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 050e04ba26f32070bbf455fc45a051db; Sat, 30 Jul 2022 05:09: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 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: <3BF6B9DD-26DF-4C82-B2CE-E460D94F6C95@yahoo.com> Date: Fri, 29 Jul 2022 22:09:43 -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: <3B32D8E3-A436-4CF6-8CCB-6798EC7F50DC@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> To: Glen Barber X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4LvsrZ2vKzz3C9C X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=GmmuFGoJ; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.27 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.992]; NEURAL_HAM_MEDIUM(-0.78)[-0.782]; 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)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.146:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_SEVEN(0.00)[7]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.146:from] X-ThisMailContainsUnwantedMimeParts: N On 2022-Jul-29, at 20:42, Mark Millard wrote: > 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). >>> . . . I got a little more evidence about the type of problem, I think. (Not that I know the interpretation to give the evidence.) Instead of booting the 13-STABLE media I put it into a booted system to look at it: =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 10381312 da0s2a freebsd-ufs (5.0G) 10381312 458376368 - free - (219G) (I've ignored ufs/rootfs ufs/rootfsa, ufsid/* above.) Compare/contrast: # growfs /dev/da0s2a growfs: unable to read superblock: Input/output error # growfs /dev/ufs/rootfs growfs: requested size 224GB is equal to the current filesystem size = 224GB # 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 # gpart resize -i 1 /dev/da0s2 # gpart show . . . =3D> 63 468862065 da0 MBR (224G) 63 1985 - free - (993K) 2048 102400 1 fat32lba [active] (50M) 104448 468757680 2 freebsd (224G) =3D> 0 468757680 da0s2 BSD (224G) 0 468757680 1 freebsd-ufs (224G) # 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 468757680 da0s2a freebsd-ufs (224G) # mount -noatime /dev/da0s2a /mnt # umount /mnt After that I can again use it to boot the 8GiByte RPi4B. But, having booted itself, it shows . . . 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) 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) So, again, no da0s2 BSD or da0s2a freebsd-ufs . (Unlike gpart show on the normal-boot main [so: 14] system.) After shutting down and plugging into the normal-boot system . . . glabel list on the normal-boot system with the USB3 SSD plugged in shows: 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 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 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 while the gpart show -p on that system lists: =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 468757680 da0s2a freebsd-ufs (224G) =3D> 0 468757680 ufsid/62e358b6cff37c76 BSD (224G) 0 468757680 ufsid/62e358b6cff37c76a freebsd-ufs (224G) =3D> 0 468757680 ufs/rootfs BSD (224G) 0 468757680 ufs/rootfsa freebsd-ufs (224G) 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): # 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. FYI: for 8 GiBye RPi4B's I add at the end of the config.txt : # # 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 I also comment out the hdmi_safe=3D1 line. (Assigning 0 instead also works.) But it is rare that I have video plugged in so I'd not normally notice the problems that hdmi_safe=3D1 can lead to. =3D=3D=3D Mark Millard marklmi at yahoo.com