From nobody Thu Jun 27 22:54:41 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 4W9DRQ06Zmz5QZFd for ; Thu, 27 Jun 2024 22:54:58 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-55.consmr.mail.gq1.yahoo.com (sonic316-55.consmr.mail.gq1.yahoo.com [98.137.69.31]) (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 4W9DRN6N6Bz555Y for ; Thu, 27 Jun 2024 22:54:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=bCLaLmB+; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1719528893; bh=tlP2CQ2a//7vyC/uT+rZH5HrJBVp+jF7saYxCjQ5ESs=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=bCLaLmB+BxSdjaaZ3hTjk2311iALsBufuMlTxvhGeOuN5yeWYUNHnbzx4lpeWz+cq/YuOaSUR+33DTxStnLlyzd8tFGKmp1fdaftXuT7nr/xgllhjNzKFj+gsBRvphBevcZZosgshQOzfwOZ5054A4oDSEjmW1pq6XsGFAip0g2hKWJkgMbqLwXDu1qmThvzeC15H/++wfo8PI2ChD1I8E6W+pQKeyYgHZzPVSLKxzz8jkxJ19nU5hEE8P7ynL3ZnG2L3xSewZ0JfTtC7uFlyEm6jGznzkdYZt7woZLqo9H/EB8b54G7sB1XyfIT5lrDWePUM2x6Wv7LK+EtM8xbaw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1719528893; bh=paMdtEDmf42If7o4YxgXxFeKkYs32r/VOzDlLK0j0X1=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ZxDMWl6tTiurzV4f8WW5ldC1EB8y87TEZrAoIKWxXl9rjhLYyxPD1jZHLM74lHFlgwrIM/lf7K25K0+AuaVsp3Ie6k7deuXc6FIzOITQ5LF0IaMdtdv5JwgNFj9LTUl+b6mCJxAgZbxDst+SVua/nVR3ePmuBa4e8x1hQV6VZ1ci8dJmYCk3sryuDg6OukcQnY5iMq5W1yqVrlDU4s+i88gKdEOwi/TY3P/A1HEjanqs98RynqjgtJclXHTSpC7khXwUJre2/TEakgYbQ2UUEJZYlglOlK7yiPQhrJjT3rGRy8kwtKOSnX55QQmA/0NqX7/ew8LoemVTkQ3Km7m+FA== X-YMail-OSG: x_RulyEVM1lRbSx9K6nQYQ30aVwEN4nQPMOUm4Nc9Ce48sMH.dy7O3DnXKlkcVi Tgw3KgArnwqUKDUGQfWD.Q6n6vRjmez7DKQFR9zU3z4qXeYvktaGpvWHjzbfMnU6zp6NIO6Rw74Y lQakebISrrWWXbEQm9N0dxXOs2SRXpuAAvDO1ynHty1qM_sM_4d0Dmtopb5fSC95gMlMtPiILy_M 6HK23clFlEEg9ltmg5m6TBifCAbnjkZPP9EH8EmFMDCpjRuZ47y265BhpKByBoTUDk4qYZwLQuhv 59osLmS7XMQWJOuiDQBjBvFYbhOH3VIgU1uqK9vn9o1EnlV3Diptv0FRBySWUvV_SqunNlVe8Wp7 p9YfbPm2YCMAofQkrUHdbz3f8IxkbUcvBvzNzSo.JY9nTiABTNudzJ0fL2La99XKXk8QsVKle41y zvPj3x5POJYo2b9jobEQCcN8Dv68SSp3vd80YtEGcBgqnex33ERnnPoBn.JT5taDYmyL8yjzUW6e LtRzPEhjJcBlOyUkpNoSXwjRNZIM7.FvnzLpdeFgRDrBdFe3g6w.XvNxZLhLXh.72okEJiuTseSp WaNwbfhp3ahZUn4EyQ9NtbgblbWQaW4vBEaXmq6pFe1ia65ULHGyelD3HSeBZrDdoZDD1j4s2oqJ K4g2b8EoIclMCym8dGV.vVMJv5zsR.Jwq816F1QYigKADTH3QBb2m.9NsSOHd_ow7dssWpPXWktb ljWefHmwTuOF4nUG4oFMyOdqvIMRNmEwoknTwEG.rGtp68Ns8rLNV3sjbhLZazn594wpby1B47f5 _buiIRaPdXZCI80yTrF2CtgNlpegJFg9hjrLoxAEQynUgI1XiYl6FHRh4a___hKVJtsRFW1RHvzI AfokgrApSSgvkCMuY3.C29i34OB463xan6v87sZgtQ34d5FOXAGu5CeSAxmL.1fww4OWDRf30r42 Jk3lV4FEr7Ruxszkr5uyFf3eyffjUPVwlmMribkV_xORldxqf_lI9Rh75FpQ5As7yKtNrsadmZGr tOUYijwFLpylDEAsjHLXAXVyEcV3fsVyP3NbpMXX9r4LasSoOVGxUbATW_7_Tc0nJsmoqa_PcOgb DpHR94GBYpKl7p9JSPagysDDl5PLc.dp71TiUSPBfTp6omx1u7SAaCSFDKTBDNK2lpJe2.oXPF1F REdtHtNIlmcGOzMOYm.WYWQyvGJ5sjkaurytrLWbv2FVLGIJtZbWwJuZ0KB1o30bM9RZ9ysEjq5z z3n689ybk7kXyoZH_gSdJ0pkQPnQ70jyi72XAp0TxiKY0_oWjlYEU.3nQ8AHg6hUCaxd05Vh_TSv 5Y0r_iT7KQKyLRUKzQot9Kg8AJFMJRzrDZdqZQ926kICkqCWPfDUNqPV5a0L34hYPBiLcNIQv7au WDRCY3BnivSWzcqyNL2h4K5HDhV0U9aVwzyPxmITkC0dq6y.b6kLJbUD3BbZTnl2AeH8Uqz.941L 4qzPByoRRMy.jFwvTr3acyGYIkxPCrvh62yzxcpxJ_V_oXPV3_ffF9CAjECPSAUyohtwn3nnbBt4 1ANMN9XG97j8DMoUfWSwz.GE.oUMJxAcY9XjRe4ne.uVBAU7Hke3Ikmd1I6En1cpcJVumSkkrz47 xWKPVkQVV1ahuznMVjQISIJbQTkxs46csUwdmqDN0yoLhdJ0BMTyiXxsBhK1IsgAdOPHXjYNc.i. iagbJVUVm8F4147219dRe5pHOAeI0bhQrGx1xY0dv8.YJvamoFRKJygk7S3GuLRm4PCu7Qih806I .SZxCkH.hVSsSYhia5H32hXKygt61eB24_2l97o8f7W2qPcqFlCjGCedYsw5uO6al1C4vfZuNuBk InyjkLCHS5Vn_t00ctI7ipX84R3E04Rj5.LMvUUbPT2NDYsuNgYk06RO4.aSOlwb4m5fh8ksOVZq 3xbHCG1mOAPHwS2IMbVAyxQSQb_X1pqTCJq6SqoL0Qgpx318GC_EHhgAurd_lcU2r.2_GWMpaBS2 5psSn57oPPn7m7cUNe0YVyEWCm0rJS._KE1w6ZmMWK3SqsZ5lr7JhXTPTVrIqGu4C4DkVkCOchE3 f7acs6TaYgurRrCByOULUluvPzzRLqalfSVQHZGaVGMnIbwozor9VhYCVlLdrr3nRfDPA3w89Xkj mvblE86DsXIz82gaW68mhaEY.uxxbJfMuQbaHRgB5723ZQX_MoOSVWQuhorota_vV39vwMb80oma 1m4ClyV3loY1KJDp.wpT7qEwQzF2zwCIm5u7W0bX6WyjTFngaj22ZvKn_PiGBmk2xrgvDOLNlarx 89XYR.S5jpUhMcNV4J0rg X-Sonic-MF: X-Sonic-ID: 0df7fbec-da2c-4026-98df-ecbbfa53a386 Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Thu, 27 Jun 2024 22:54:53 +0000 Received: by hermes--production-gq1-5b4c49485c-4rmzt (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 8c2f5332a6eb1800185b16a5b130df48; Thu, 27 Jun 2024 22:54:52 +0000 (UTC) Content-Type: text/plain; charset=utf-8 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 16.0 \(3774.600.62\)) Subject: Re: Git clone failures on armv7, was Re: Git core dump checking out main on armv7 From: Mark Millard In-Reply-To: Date: Thu, 27 Jun 2024 15:54:41 -0700 Cc: bob prohaska , FreeBSD ARM List Content-Transfer-Encoding: quoted-printable Message-Id: References: <5D5B6739-1685-43F5-80CC-E55603181D09@yahoo.com> <8F4F4B49-5ED3-4ACA-B0D3-356D8459BE95@yahoo.com> <5DC2D33F-A8DB-4542-B8B3-A131F660A395@yahoo.com> To: Warner Losh X-Mailer: Apple Mail (2.3774.600.62) X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; DKIM_TRACE(0.00)[yahoo.com:+]; TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_THREE(0.00)[3]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.31:from]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.31:from] X-Rspamd-Queue-Id: 4W9DRN6N6Bz555Y On Jun 27, 2024, at 14:40, Mark Millard wrote: > On Jun 27, 2024, at 12:15, Warner Losh wrote: >=20 > 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: >>>=20 >>> 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? >>>=20 >> 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_g= ittests >>=20 >> 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. >>=20 >> What happens if you start limiting the memory resources inside a = armv7 jail >> on a aarch64 machine? >>=20 >> Sometimes it works, sometimes it doesn't triggers a "memory shortage" = or >> "marginal amounts of memory available" bug hunting memories for me. >=20 > As I reported in a earlier submittal to the list, I've > replicated the problem on an armv7 system running main [15] > with RAM+SWAP being: >=20 > 2048 MiBytes RAM + 3685 MiBytes SWAP =3D=3D 5733 MiBytes OVERALL >=20 > This was on a Orange Pi+ 2ed. A top variation monitoring and > reporting various maximum observed figures did not show any > large memory use compared to even 1024 MiBytes. Any limitation > would appear to have to be local to some more specific kind > of constraint rather than overall system RAM or RAM+SWAP. >=20 >> Warner FYI: So far, doing the likes of "truss -o ~/truss.txt -f -a -H -p 2136" towards the end of "Receiving objects" (where 2136 was the original git process) has always resulted in a normal completion of the clone. comparing/contrasting use of (gdb) run clone --depth=3D1 -o freebsd = ssh://anongit@192.158.248.9/src.git /tmp/DOES-NOT-EXIST Such still gets the errors: (gdb) run clone --depth=3D1 -o freebsd = ssh://anongit@192.158.248.9/src.git /tmp/DOES-NOT-EXIST Starting program: /usr/local/bin/git clone --depth=3D1 -o freebsd = ssh://anongit@192.158.248.9/src.git /tmp/DOES-NOT-EXIST Cloning into '/tmp/DOES-NOT-EXIST'... [Detaching after fork from child process 2172] [New LWP 100254 of process 2171] [Detaching after fork from child process 2173] remote: Enumerating objects: 104642, done. remote: Counting objects: 100% (104642/104642), done. remote: Compressing objects: 100% (88919/88919), done. remote: Total 104642 (delta 22161), reused 43523 (delta 11808), = pack-reused 0 (from 0) Receiving objects: 100% (104642/104642), 344.50 MiB | 1.11 MiB/s, done. [LWP 100254 of process 2171 exited] Resolving deltas: 100% (22161/22161), done. [Detaching after fork from child process 2176] fatal: missing blob object '64981a94f867c4c6f9c4aaa26c1117cc8d85de34' fatal: remote did not send all necessary objects [Inferior 1 (process 2171) exited with code 0200] >> Thanks for reading, >>=20 >> bob prohaska >>=20 >>=20 >>>> A second try without chroot resulted in failure but no panic: >>>=20 >>>> : Should own extent_mutex_pool(17) >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>>> 47.25 MiB | 1.35 MiB/s =20 >>>> error: index-pack died of signal 6 >>>>=20 >>>> A repeat session produced an oft-seen failure: >>>>=20 >>>> 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. >>>=20 >>>> : Should own extent_mutex_pool(17) >>>=20 >>> That is the same error notice as above that looked >>> to be interesting. >>>=20 >>> 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). >>>=20 >>>> 47.25 MiB | 1.35 MiB/s =20 >>>> 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=20 >>>> 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 >>>=20 >>> Note the lack of a local message: >>>=20 >>> : Should own extent_mutex_pool >>>=20 >>> But the prior jemalloc message(s) may be sufficient >>> context to not be surprised about this. >>>=20 >>>> root@www:/mnt/4tharmv7gittest #=20 >>>>=20 >>>> 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 >>>=20 >>> Note the lack of a local message: >>>=20 >>> : Should own extent_mutex_pool >>>=20 >>> But the prior jemalloc message(s) may be sufficient >>> context to not be surprised about this (again). >>>=20 >>>> root@www:/mnt/5tharmv7gittest=20 >>>>=20 >>>> Not sure what to try next, thanks for reading this far!=20 >>>>=20 >>>> bob prohaska >>>>=20 >>>>=20 >>>> Archived at=20 >>>> http://www.zefox.net/~fbsd/rpi2/git_problems/readme_armv7 >>>=20 >>>=20 =3D=3D=3D Mark Millard marklmi at yahoo.com