From nobody Thu Jun 27 19:15:35 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 4W97ZX74Jkz5QFcy for ; Thu, 27 Jun 2024 19:15:48 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4W97ZX57R5z4kkP for ; Thu, 27 Jun 2024 19:15:48 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1034.google.com with SMTP id 98e67ed59e1d1-2c86e3fb6e7so3897012a91.1 for ; Thu, 27 Jun 2024 12:15:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1719515747; x=1720120547; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=J/MRVqjqkpr+5yc5sKiLyDCf+6LS3TwA6SCwwsBw4jI=; b=zdlbPr5KYDfsTP8YD8N5Bg2I/Oe0czK8+26xpHFJvnvdNlNAn2FMrcsXN3OsYZS1b/ DzfxiiwBhhjUPZfF49pDYJLWYqdwGmdk8KT3nBYwIzJ0F+3Sz083hkb/3pE5Y4FZcbTN zdtbQOrgCwjqasyydnpRKxcSTxzgtYULHdAUg/bnVXPJmrieEdQ8Kv3UbxRxZd9Ro1Wc 7l3WrCDREGaQpWeG6C1RXbca9YLozj1fTZL8L7CtM5p6NSJTXnB+t4J6LHFImaorcp20 g3ps/73Z1hVnwSWWR1NRwzsirAbfTM+KOIWxReaqCQFewpzDFtfyWbe2B+cUDes8Iq9G syDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719515747; x=1720120547; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=J/MRVqjqkpr+5yc5sKiLyDCf+6LS3TwA6SCwwsBw4jI=; b=lIEXngZW9YotegojOnlO1t8x4ylNeI8f5QjW+2lc0wKpLT+lGi493g3YzAq+RuqyiL 7u+lBPogu9YmYZ7ro4ZAjGo/TNJMnArpQcmveK+ccAgdGwiamadGRNnPrl1O/41dbmbw MfRIgE+BlfOS3l8csH3YF5dRSPfBCvjeYMq1f0/puN63G80KafpEXbzTMi+NMgNevJnX 9PN63Pb6UbZfHmC35/yuIa5+G6qLguuVF3g5BkEAnusp02VVp9uFYqEcCEWDjNTWwUB7 25nhOt9zsEO1NI7hCVnI/BE0MCuyVsmT8BXHsPnF0dWPLWs9HurRRtliS1/r+/FVK9+s A43w== X-Forwarded-Encrypted: i=1; AJvYcCUJZAFCP5KHAsJW2DtvcWZAp8ZiDAojzToBhcQcx1fHfW7TdUl69Rn/diKkAXqiUIWwlqEeF9E1c4SnYnAHaXwDHtkqvPQyuQ== X-Gm-Message-State: AOJu0Yybd4HYoWVJQJiKnuWXYovRzMKpfPg3kJK0ASxD5lJWd0Sgsl6f JDV/TCsjYcfpttSxk3JkWw3WD2iOxCQpIxJc0erPcoaVj4GlPDYF+AeIJhd3i6QaWBucdcMTAEo eJg9lPvU6MvtdQK7hvR5ikb3PWDvepZb+fEE0nN5bOyIIGua91SQ= X-Google-Smtp-Source: AGHT+IFPwoo3t4dv3GAG6qbKcaGfe/s1+yssHbP//OsDIcYFVcBgDDZsg23s3wZRgHMvxuRg/8j9YApAQTz1wMjRWm4= X-Received: by 2002:a17:90a:db82:b0:2c9:401:a6fb with SMTP id 98e67ed59e1d1-2c90401bf8emr1701778a91.25.1719515746989; Thu, 27 Jun 2024 12:15:46 -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: <5D5B6739-1685-43F5-80CC-E55603181D09@yahoo.com> <8F4F4B49-5ED3-4ACA-B0D3-356D8459BE95@yahoo.com> <5DC2D33F-A8DB-4542-B8B3-A131F660A395@yahoo.com> In-Reply-To: From: Warner Losh Date: Thu, 27 Jun 2024 13:15:35 -0600 Message-ID: Subject: Re: Git clone failures on armv7, was Re: Git core dump checking out main on armv7 To: bob prohaska Cc: Mark Millard , FreeBSD ARM List Content-Type: multipart/alternative; boundary="00000000000049184e061be3f5ca" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4W97ZX57R5z4kkP --00000000000049184e061be3f5ca Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jun 27, 2024 at 10:24=E2=80=AFAM bob prohaska = wrote: > On Wed, Jun 26, 2024 at 06:24:59PM -0700, Mark Millard wrote: > > > > Does using the chroot setup using --depth=3D1 on the > > RPi2B consistently work when tried repeatedly? Or > > was this just an example of a rare success? > > > Apparently it was a rare success. Five back-to-back retries > all failed in an orderly way, though with different messages; > invalid fetch-pack and missing blob object. > The transcript is at > > http://www.zefox.net/~fbsd/rpi2/git_problems/readme_shallow_armv7_chroot_= gittests > > Is it worthwhile to repeat with different --depth=3D values? I'm not sure > what the sensible range might be, maybe a 1, 2, 5 sequence? It would > be convenient to avoid a panic, as that slows repetition. > What happens if you start limiting the memory resources inside a armv7 jail on a aarch64 machine? Sometimes it works, sometimes it doesn't triggers a "memory shortage" or "marginal amounts of memory available" bug hunting memories for me. Warner > Thanks for reading, > > bob prohaska > > > > > A second try without chroot resulted in failure but no panic: > > > > > : Should own extent_mutex_pool(17) > > > > That looks like it would be interesting to someone > > appropriately knowledgeable. If jemalloc can see bad > > mutex ownerships, that seems like such could lead to > > all sorts of later problems: Garbage-in/garbage-out. > > > > I do not know if the message means that various > > corruptions might be in place afterwards so that > > various later problems might be consequences that > > are not surprising possibilities. > > > > > 47.25 MiB | 1.35 MiB/s > > > error: index-pack died of signal 6 > > > > > > A repeat session produced an oft-seen failure: > > > > > > root@www:/mnt # mkdir 3rdarmv7gittest > > > root@www:/mnt # cd 3rdarmv7gittest > > > root@www:/mnt/3rdarmv7gittest # git clone -o freebsd ssh:// > anongit@192.158.248.9/src.git . > > > Cloning into '.'... > > > remote: Enumerating objects: 4511481, done. > > > remote: Counting objects: 100% (383480/383480), done. > > > remote: Compressing objects: 100% (28955/28955), done. > > > > > : Should own extent_mutex_pool(17) > > > > That is the same error notice as above that looked > > to be interesting. > > > > Note that it happens before the later message > > "error: index-pack died of signal 6". So that > > last may just be a later consequence of the > > earlier error(s). > > > > > 47.25 MiB | 1.35 MiB/s > > > error: index-pack died of signal 6 > > > fatal: index-pack failed > > > root@www:/mnt/3rdarmv7gittest # ls > > > root@www:/mnt/3rdarmv7gittest # cd .. > > > root@www:/mnt # mkdir 4tharmv7gittest > > > root@www:/mnt # cd 4tharmv7gittest > > > root@www:/mnt/4tharmv7gittest # git clone -o freebsd ssh:// > anongit@192.158.248.9/src.git . > > > Cloning into '.'... > > > remote: Enumerating objects: 4511481, done. > > > remote: Counting objects: 100% (383480/383480), done. > > > remote: Compressing objects: 100% (28955/28955), done. > > > Receiving objects: 43% (1966916/4511481), 926.00 MiB | 626.00 KiB/s > > > remote: Total 4511481 (delta 377747), reused 354525 (delta 354525), > pack-reused 4128001 (from 1) > > > Receiving objects: 100% (4511481/4511481), 1.64 GiB | 705.00 KiB/s, > done. > > > fatal: pack is corrupted (SHA1 mismatch) > > > fatal: index-pack failed > > > > Note the lack of a local message: > > > > : Should own extent_mutex_pool > > > > But the prior jemalloc message(s) may be sufficient > > context to not be surprised about this. > > > > > root@www:/mnt/4tharmv7gittest # > > > > > > No panic, however, and it seems reproducible: > > > root@www:/mnt # mkdir 5tharmv7gittest > > > root@www:/mnt # cd 5tharmv7gittest > > > root@www:/mnt/5tharmv7gittest # git clone -o freebsd ssh:// > anongit@192.158.248.9/src.git . > > > Cloning into '.'... > > > remote: Enumerating objects: 4511513, done. > > > remote: Counting objects: 100% (383480/383480), done. > > > remote: Compressing objects: 100% (28955/28955), done. > > > remote: Total 4511513 (delta 377756), reused 354525 (delta 354525), > pack-reused 4128033 (from 1) > > > Receiving objects: 100% (4511513/4511513), 1.64 GiB | 1.28 MiB/s, don= e. > > > fatal: pack is corrupted (SHA1 mismatch) > > > fatal: index-pack failed > > > > Note the lack of a local message: > > > > : Should own extent_mutex_pool > > > > But the prior jemalloc message(s) may be sufficient > > context to not be surprised about this (again). > > > > > root@www:/mnt/5tharmv7gittest > > > > > > Not sure what to try next, thanks for reading this far! > > > > > > bob prohaska > > > > > > > > > Archived at > > > http://www.zefox.net/~fbsd/rpi2/git_problems/readme_armv7 > > > > > > > > =3D=3D=3D > > Mark Millard > > marklmi at yahoo.com > > > > > > --00000000000049184e061be3f5ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jun 27, 2024 at 10:24=E2=80= =AFAM bob prohaska <fbsd@www.zefox= .net> wrote:
On Wed, Jun 26, 2024 at 06:24:59PM -0700, Mark Millard wrote:
>
> Does using the chroot setup using --depth=3D1 on the
> RPi2B consistently work when tried repeatedly? Or
> was this just an example of a rare success?
>
Apparently it was a rare success. Five back-to-back retries
all failed in an orderly way, though with different messages;
invalid fetch-pack and missing blob object.
The transcript is at
http://www.zefox.ne= t/~fbsd/rpi2/git_problems/readme_shallow_armv7_chroot_gittests

Is it worthwhile to repeat with different --depth=3D values? I'm not su= re
what the sensible range might be, maybe a 1, 2, 5 sequence? It would
be convenient to avoid a panic, as that slows repetition.
<= div>
What happens if you start limiting the memory resources = inside a armv7 jail
on a aarch64 machine?

Sometimes it works, sometimes it doesn't triggers a "memory shor= tage" or
"marginal amounts of memory available" bu= g hunting memories for me.

Warner
=C2=A0=
Thanks for reading,

bob prohaska


> > A second try without chroot resulted in failure but no panic:
>
> > <jemalloc>: Should own extent_mutex_pool(17)
>
> That looks like it would be interesting to someone
> appropriately knowledgeable. If jemalloc can see bad
> mutex ownerships, that seems like such could lead to
> all sorts of later problems: Garbage-in/garbage-out.
>
> I do not know if the message means that various
> corruptions might be in place afterwards so that
> various later problems might be consequences that
> are not surprising possibilities.
>
> > 47.25 MiB | 1.35 MiB/s=C2=A0
> > error: index-pack died of signal 6
> >
> > A repeat session produced an oft-seen failure:
> >
> > root@www:/mnt # mkdir 3rdarmv7gittest
> > root@www:/mnt # cd 3rdarmv7gittest
> > root@www:/mnt/3rdarmv7gittest # git clone=C2=A0 -o freebsd ssh://= anongit@192.158.248.9/src.git .
> > Cloning into '.'...
> > remote: Enumerating objects: 4511481, done.
> > remote: Counting objects: 100% (383480/383480), done.
> > remote: Compressing objects: 100% (28955/28955), done.
>
> > <jemalloc>: Should own extent_mutex_pool(17)
>
> That is the same error notice as above that looked
> to be interesting.
>
> Note that it happens before the later message
> "error: index-pack died of signal 6". So that
> last may just be a later consequence of the
> earlier error(s).
>
> > 47.25 MiB | 1.35 MiB/s=C2=A0
> > error: index-pack died of signal 6
> > fatal: index-pack failed
> > root@www:/mnt/3rdarmv7gittest # ls
> > root@www:/mnt/3rdarmv7gittest # cd ..
> > root@www:/mnt # mkdir 4tharmv7gittest
> > root@www:/mnt # cd 4tharmv7gittest
> > root@www:/mnt/4tharmv7gittest # git clone -o freebsd ssh://anongit@192.158.248.9/src.git .
> > Cloning into '.'...
> > remote: Enumerating objects: 4511481, done.
> > remote: Counting objects: 100% (383480/383480), done.
> > remote: Compressing objects: 100% (28955/28955), done.
> > Receiving objects:=C2=A0 43% (1966916/4511481), 926.00 MiB | 626.= 00 KiB/s
> > remote: Total 4511481 (delta 377747), reused 354525 (delta 354525= ), pack-reused 4128001 (from 1)
> > Receiving objects: 100% (4511481/4511481), 1.64 GiB | 705.00 KiB/= s, done.
> > fatal: pack is corrupted (SHA1 mismatch)
> > fatal: index-pack failed
>
> Note the lack of a local message:
>
> <jemalloc>: Should own extent_mutex_pool
>
> But the prior jemalloc message(s) may be sufficient
> context to not be surprised about this.
>
> > root@www:/mnt/4tharmv7gittest #
> >
> > No panic, however, and it seems reproducible:
> > root@www:/mnt # mkdir 5tharmv7gittest
> > root@www:/mnt # cd 5tharmv7gittest
> > root@www:/mnt/5tharmv7gittest # git clone -o freebsd ssh://anongit@192.158.248.9/src.git .
> > Cloning into '.'...
> > remote: Enumerating objects: 4511513, done.
> > remote: Counting objects: 100% (383480/383480), done.
> > remote: Compressing objects: 100% (28955/28955), done.
> > remote: Total 4511513 (delta 377756), reused 354525 (delta 354525= ), pack-reused 4128033 (from 1)
> > Receiving objects: 100% (4511513/4511513), 1.64 GiB | 1.28 MiB/s,= done.
> > fatal: pack is corrupted (SHA1 mismatch)
> > fatal: index-pack failed
>
> Note the lack of a local message:
>
> <jemalloc>: Should own extent_mutex_pool
>
> But the prior jemalloc message(s) may be sufficient
> context to not be surprised about this (again).
>
> > root@www:/mnt/5tharmv7gittest
> >
> > Not sure what to try next, thanks for reading this far!
> >
> > bob prohaska
> >
> >
> > Archived at
> > http://www.zefox.net/~fbsd/rpi2/g= it_problems/readme_armv7
>
>
>
> =3D=3D=3D
> Mark Millard
> marklmi at yahoo.com
>
>

--00000000000049184e061be3f5ca--