From nobody Thu Jul 21 15:24:57 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 4Lpbwk5XdPz4WshB for ; Thu, 21 Jul 2022 15:25:10 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Lpbwj5RStz4DPw for ; Thu, 21 Jul 2022 15:25:09 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe33.google.com with SMTP id t15so1828100vsr.12 for ; Thu, 21 Jul 2022 08:25:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xDxcZrOpWVqGI39ngQOAyJrfuN1IB5bELlJJFEi0uq4=; b=MxRC30mLiqELW6VmM4ciimKGF6uNLMpr2ZgjZ36fNA+PjwwRxj+0wD+n0LpTE6qiWC SsUmShm/p5blFbHOr+fqLPJ8X4Px5bfgKC3Hcx1C6VJShngk7xJDNZz55J7r39suqV+z dSiHefcAEBn3iPpwoT3T7ku/EA4h4B0luOUSN+usrFN2Wz7C+Vm5V9+C7CjCjZzk34w9 eMv6FxypJYQMCn7uqtuWKkdtn7NemDMTeNPgExHejpLsQpusMF2Ozl8DAknBhxDDYIxK 6lB4EifRzhbIARrvev9ZfotKxDNg7CEj0wGr9KOsU79/MkOMud63XTIeRNiKmllY10p2 jWQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xDxcZrOpWVqGI39ngQOAyJrfuN1IB5bELlJJFEi0uq4=; b=qv+GNRHNe4wg2eA3b8e4h4PcvTKQarG/Q2/yk122d4IATNGVw9hPhRqw31JnvqvTy8 V6qpWqyX597Z9i9VVOzCcXchh+FKPjTt96EHHVaqCXBngkVupr2/zsOVsYoaf+l+xpCo dMsAxMmvUq2m0dqXKIMjXCf9YwlwQffdFa8TQUuORU668YcWSilycgNjtKRC1Zk0vH/w 50LM/m3bkpWBAb0cNcwB8XwMPQ9wjTRBNp/ZgApYFCU6+07eXavVegKvRc8aByEA3+jo npIXbNboC+sbi4qs8bQSgOAksm1rZOsaMn18vXsaJfxfF7EzMfalTbfl7UT1agMBuvsK 2/nA== X-Gm-Message-State: AJIora8UyXDmb0A5WJ6QryhpvVFWwDP1N2QlCDnMSe0NUbIF/WtzQqcB 31fl9ZB8pVt2OqFbZOqw4cnG8XUgqa8sWAPxU/9Qzg== X-Google-Smtp-Source: AGRyM1vZXwxCgAIYJLUYvB2ep5MX/42kLp6gMK8MsIYGOiSQwUOEOhsV9TTwID4WKSJmxeHnC3CX5/yOr0cFA12BX8Q= X-Received: by 2002:a67:ec88:0:b0:357:83f:e0f3 with SMTP id h8-20020a67ec88000000b00357083fe0f3mr15853086vsp.76.1658417108965; Thu, 21 Jul 2022 08:25:08 -0700 (PDT) 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 References: <16906DFD-286B-4D59-9438-CA9CD9026C55@yahoo.com> <202207171708.26HH81bA062303@gndrsh.dnsmgr.net> <20220719204245.GL30607@FreeBSD.org> In-Reply-To: From: Warner Losh Date: Thu, 21 Jul 2022 09:24:57 -0600 Message-ID: Subject: Re: git: 1dfcff294e44 - main - release: increase IMAGE_SIZE for arm, arm64, riscv [odd alignment for SBC images] To: Kyle Evans Cc: Mark Millard , Glen Barber , Ed Maste , "Rodney W. Grimes" , dev-commits-src-main@freebsd.org, "Dr. Rolf Jansen" , freebsd-arm Content-Type: multipart/alternative; boundary="000000000000ab6c0105e4525284" X-Rspamd-Queue-Id: 4Lpbwj5RStz4DPw X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=MxRC30mL; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e33) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_CC(0.00)[yahoo.com,freebsd.org,gndrsh.dnsmgr.net,cyclaero.com]; R_SPF_NA(0.00)[no SPF record]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e33:from]; ARC_NA(0.00)[]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_SEVEN(0.00)[8]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-ThisMailContainsUnwantedMimeParts: N --000000000000ab6c0105e4525284 Content-Type: text/plain; charset="UTF-8" On Thu, Jul 21, 2022 at 8:55 AM Kyle Evans wrote: > On Wed, Jul 20, 2022 at 10:08 AM Mark Millard wrote: > > > > On 2022-Jul-19, at 15:45, Warner Losh wrote: > > > > > On Tue, Jul 19, 2022, 2:42 PM Glen Barber wrote: > > >>> . . . > > >> > > >> My concern with this is kern.geom.part.mbr.enforce_chs is always '1' > on > > >> the builders, which effectively means all arm builds will fail every > > >> time. I think we need to get to the actual root of the problem here, > > >> versus applying band-aids to a shark bite. > > > > > > I think this is the actual problem. While such pedantry can be useful > for ancient picky BIOSes, these days only the LBA fields of the MBR are > used. And the fake BIOS geometry is crazy weird. We can likely tweak it to > be more friendly. > > > > > > Why is it == 1 on the builder? If people want things aligned gpart has > an option for years iirc to do that. And we want that off for the builds. > > > > 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=0 and see what breaks, if anything? > > (Sort of a snapshot exp run.) > > > > https://svnweb.freebsd.org/base?view=revision&revision=332731 says: > > Note: In addition to this merge, kern.geom.part.mbr.enforce_chs has > been enabled on the build machine to mitigate against the issue in > the PR referenced. > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226536 > ("glabel/partition mixup on sdcard images") > Having read through all that, I think it's safe to disable it again. We changed the build process to avoid the original bug, so no longer need the rounding to prevent the situation from happening. There are no old branches or legacy reasons to keep it enabled unless there's another side effect of it that I'm not seeing... Warner --000000000000ab6c0105e4525284 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jul 21, 2022 at 8:55 AM Kyle = Evans <kevans@freebsd.org> = wrote:
On Wed, J= ul 20, 2022 at 10:08 AM Mark Millard <marklmi@yahoo.com> wrote:
>
> On 2022-Jul-19, at 15:45, Warner Losh <imp@bsdimp.com> wrote:
>
> > On Tue, Jul 19, 2022, 2:42 PM Glen Barber <gjb@freebsd.org> wrote:
> >>> . . .
> >>
> >> My concern with this is kern.geom.part.mbr.enforce_chs is alw= ays '1' on
> >> the builders, which effectively means all arm builds will fai= l every
> >> time.=C2=A0 I think we need to get to the actual root of the = problem here,
> >> versus applying band-aids to a shark bite.
> >
> > I think this is the actual problem. While such pedantry can be us= eful for ancient picky BIOSes, these days only the LBA fields of the MBR ar= e used. And the fake BIOS geometry is crazy weird. We can likely tweak it t= o be more friendly.
> >
> > Why is it =3D=3D 1 on the builder? If people want things aligned = gpart has an option for years iirc to do that. And we want that off for the= builds.
>
> 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.)
>

https://svnweb.freebsd.org/base= ?view=3Drevision&revision=3D332731 says:

Note: In addition to this merge, kern.geom.part.mbr.enforce_chs has
been enabled on the build machine to mitigate against the issue in
the PR referenced.

https://bugs.freebsd.org/bugzilla/show_bu= g.cgi?id=3D226536
("glabel/partition mixup on sdcard images")
=
Having read through all that, I think it's safe to disab= le it again. We changed the build process
to avoid the original b= ug, so no longer need the rounding to prevent the situation from happening.=
There are no old branches or legacy reasons to keep it enabled u= nless there's another side effect
of it that I'm not seei= ng...

Warner
--000000000000ab6c0105e4525284--