From nobody Wed Jul 31 14:46:21 2024 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 4WYw022G7yz5S1cN; Wed, 31 Jul 2024 14:46:26 +0000 (UTC) (envelope-from void@f-m.fm) Received: from fhigh6-smtp.messagingengine.com (fhigh6-smtp.messagingengine.com [103.168.172.157]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 4WYw010tX8z4lsc; Wed, 31 Jul 2024 14:46:25 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm3 header.b="pxg/Ller"; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=TBLTdAwN; dmarc=pass (policy=none) header.from=f-m.fm; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 103.168.172.157 as permitted sender) smtp.mailfrom=void@f-m.fm Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailfhigh.nyi.internal (Postfix) with ESMTP id 812DF1146CCB; Wed, 31 Jul 2024 10:46:23 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Wed, 31 Jul 2024 10:46:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc:cc :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1722437183; x=1722523583; bh=rc65PALNJf iF3hqmeDGcy5eFSgtK8nqAMw7ajS2ar5M=; b=pxg/LlerFDi5Vyzq/ZtVaMINs5 fydeZ6tM+fHaJa/TM6GQNF2urOMTvI/6GnCYwSjp3xksFZ1wsGbEe2njnAdwQSSh noX8qfkCL/Gg2SH2/QXc1WCTLFyWX2AGwZcT8NtfOJ5364a3Hfvk4yrMR03rArqi Ce7MXxtPHDEipRR8V/FiJfVAJ30FqJlQ4W2a4TAEtUtNZmtVW9QT4EbtS1W4mnlR 2+n1yfyY4QSwhHMfhCNbRbAjPr67rCJeZFJlZL7E1ahihk3xYtPuz3+WeqG4X73F TP7BNoTQ5lVhw79C5LFgkqbDNH9t1o2B7LU4lhkrTl+Odkw8f8lXfF44zGmQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; t=1722437183; x=1722523583; bh=rc65PALNJfiF3hqmeDGcy5eFSgtK 8nqAMw7ajS2ar5M=; b=TBLTdAwNDm+wYMIyCoFsAK2kSKaS3qr8zm1Padq2lKfC dDpbNpGawoIdJWFgspkzT0YLp5CNVBiH03KSzmJpZCYAKfyVd94wOx+MYzjMvDeB 3PtNA7CkTikWSpMDTXcTfIxirxbkZokbBulmiY9nyuxiKuBYnQC2dymuOehdBogS /kzshzViOqV9WBV7xVJgTR1+aSgWlbH5LPrX8g5sVini1yKnseVkix+pwmM6nM5z 9cU1TNQLNdLyl0FG9ouBT+LcZKlvVuJApmo1BP8dF6csqHLllA5kGWiuws0MMAu3 3Hrt+3qNgYVeNPxco3JCW35QdtJoqqc2ej1OKumzUw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrjeeigdekudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvfevuffkfhggtggujgesthdtre dttddtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgr thhtvghrnhepuddvueeguddufeetheehffdvgeetleekkedvveffudekueegueetffetfe eklefhnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhep vhhoihgusehfqdhmrdhfmhdpnhgspghrtghpthhtoheptd X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 31 Jul 2024 10:46:22 -0400 (EDT) Date: Wed, 31 Jul 2024 15:46:21 +0100 From: void To: freebsd-ports@freebsd.org Cc: freebsd-arm@freebsd.org Subject: Re: [main has a fix for] armv7-on-aarch64 stuck at urdlck: I got a replication of the "ampere2" bulk build hangup problem on a Windows DevKit 2023 Message-ID: Mail-Followup-To: freebsd-ports@freebsd.org, freebsd-arm@freebsd.org References: <561E4947-6D56-4431-AE08-C843FF232066@yahoo.com> <68C09CB4-92AF-4369-A1E0-A6EADF092449@yahoo.com> 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 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <68C09CB4-92AF-4369-A1E0-A6EADF092449@yahoo.com> X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.79 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.985]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; MID_RHS_NOT_FQDN(0.50)[]; RWL_MAILSPIKE_VERYGOOD(-0.20)[103.168.172.157:from]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm3,messagingengine.com:s=fm3]; R_SPF_ALLOW(-0.20)[+ip4:103.168.172.128/27]; RCVD_IN_DNSWL_LOW(-0.10)[103.168.172.157:from]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[f-m.fm]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_THREE(0.00)[3]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org,freebsd-ports@freebsd.org]; ASN(0.00)[asn:209242, ipnet:103.168.172.0/24, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; MISSING_XM_UA(0.00)[]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim] X-Rspamd-Queue-Id: 4WYw010tX8z4lsc On Fri, Jul 26, 2024 at 05:14:31PM -0700, Mark Millard wrote: > >I assume that this wording is about having amd64 with qemu attempting >bulk -a for building amv7 packages, not about having aarch64 (without >qemu) bulk -a with armv7 jails do so (which are now being done). Have >I got that right? > >If spreading the package-building load around more to amd64 contexts >was a goal, and if amd64 with qemu worked well for aarch64, one could >imagine having some of the aarch64 package builds on amd64 but all >the armv7 ones on the ampere*'s. This may be more likely to work >better overall than amd64 with qemu ever handling a 32-bit context >well (armv7 here). Sort of adjacent to this discussion, but here's an idea: Don't have tier2 platforms building on the same machinery as tier1. That way, issues like armv7 builds (for ports) running forever will never delay aarch64. Sure to be other issues that can be sidestepped with such an approach. Just a suggestion. --