From nobody Thu Jun 27 01:24:59 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 4W8gqH51TBz5NBMl for ; Thu, 27 Jun 2024 01:25:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-21.consmr.mail.gq1.yahoo.com (sonic313-21.consmr.mail.gq1.yahoo.com [98.137.65.84]) (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 4W8gqH2R2Pz4pRw for ; Thu, 27 Jun 2024 01:25:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1719451513; bh=LeySuj9YfuJFA+67YcfoS9xPziyVtEpjccqQVN5Z7ZM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=AoKsqbvsgmskrOFk+CUCtyuHHNf2hqtvB0sssaG8KZ4m8QU1ION8bZRmSQVOBs7rX+09b4dZUFtRSNv4FV7Ks2MXQ9Hp0NkKWUN/tHdUn7LwCCnD2EUStznd6TJdLFeUTTwgA/vAli3rlJZYLEX7jPYq3L23CVcLsdhkG8V6EJ0rxtHvFWKRJdsH++2GwbF4DJROf41dQpWHXXcYo4+gjRj/NeqJeJjKtr4w+5bWaawx1xwL1cM4gq75E2in+3Ebhlg9vpFTDVvrgIETIWDDTGFNvMcTI9H+idwHQcO4Jzwdpn0pqd6KFgJuwUrH4u2sFxYeIJCVpVt8BEHj4DgubA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1719451513; bh=zcMJv1o+/22Whj4SQ/Gfb6KMdDzdu3r+NOuZzxp5hJ8=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Iw1evWbGSv9XCAQmqJH7+GoIcVlU3nfe2wFCCe2jMH8wOiESs7G8uftz1uNShtvFW/PBoWkqQVZZs5woeGDoYxCx3UaDLYusHaVphlt6UfeDAfRxoDtTEX43LX//FCnwS9JEqcPo/IXnGq4LPoE6K1j0PfyhkXbbB76lwvTzXVsEbEEPdrRytDaEKdaA3m9NU3khyIezcwnQPA0ROMNflzNzAPhpLMt7OQF8CyY4wdUe4o1NBP2uti2MWsofc8vUUb6Y2B7WRic8OPZ99uL4kJ5eCxiWL0ptoPBQfDfiSaTxmkJGX4vbV4D7PlZEN5rlMG2S4V4GPaxsQl1E+cQ9fA== X-YMail-OSG: bDmjVLoVM1k2jjC6fOOD7NfITy86oO37wgfXxZk8wxNWyXO4DXg1HZzvgIUFxHW imGf4GiW7nr8UnBOIkf_9Mkl54ZEkoHxD6dkTXWTrlNW1JmYHOFKkyZNBpdg1ZOJxEiUadCHe3Pe IZT6E8b7IvjLdpXQtYFwYyMPo4XSxfwwr6aujPw8WZ.vjwc0HQvfHGQG76HKcLEr07adhh8K3X9C iT0mOhuCIzlS7n.PGyKxtC9wBUFuFb_sy_jXGyWXhU6pFLTfHqUVUSMzqbscaOTL22wYlS3lUkex OnbNDt5J6pRtHMODy7WXvbgDiD4mYha0VApWiZ5U7AKChkzHf7boHUyU50QD_pJXaSX139KD4ClM 0vBwq2pVh_MYGp078iCdpyvSm0qrVHmoVokbhQVaUzGCjt8Sy23U48GtHmdJGoumR5nnRrQKRCFn MEDchVJjxlUTZ8UhiDG0Q7HRb7obKpSMOK4llX1.K3NwRFHrlMFur5ljYtBGNuS1bOoV0LUR0yTe WL.a05wkPXSyz2TfrEwUY1PN9R4r_BlZxnMWlyM6_ilfRWpMBw28MFv5vKMUzt1CWbToDs.ojRKT O0JFGpE9S3xySvqWipLLimyjeMIUZB88XpiE7fJG_69gyavioD0qnFmbhl.c_IJzUFO2TFyw0IRA _Q4sHkKn.hk.u6KUZIth09Pfr..J18lWuQUJQFuiG1ZdxlAqt37Z4HQ0vdAhx5XqmvTIphx7E_Xc RzYEpecIQOMRWRsWYN6HxMILXt8VSz07Lpe4Ib9LBJI0CsR8KDAgOfKQZfROQ3TXvegTUk4AUzAv 9uYAgIJSv2awi9x2.ZDE_PSmrHNJAw1vy6cV8xbU1P._9srA4JwVK2OilHcfz7g4I0_tD5jwLiOE 3qumFyvkpV7h2guRJWpUfoYs9sYRKBMLcB5VHtiZ2G8aWUFWgrODmpG1ytC7w4PR3f2Ny4sLkKXO yU.vf2Vn6aVj24puLXdgWvWktTE_kp9oE5JOMH3qkW5Wr1ZaR09EcPqkdDw1mwNMNZ2ShtnBwFgJ _W0OY6Tly02ZvaqaChHsJlEwRXJUdqs98exmt.l4pdcyLDfaJq8CzY4bP_e19vTxpILY1KmERVbd jNX6D3kgNND2EOYpGdcy3oBvNMCzg.DyMaoJ33ElytUYpWNlF2t75k_hjEiPaWVSopVYuZOeeWVa 8mWnbi088k935II6gu1Da35VPQaV9eMZpP9rtn4jOc5Q8lCr9_BXRJ2Lmuk.m2jHfiRKrzTe4dk4 dh4jRxOtZ6L0iNVcslAfu0gi1SXWt4A4r4fhKMllIWrvOOFR9YUCRxc47716JQAFZ4ubWSHLqdLR 6DD3V1LXvwnLnTxOAv6zc0mTOQlM9AMxDeg_CN9s4HFpXR.HWsuxn5_ki2gbwBMruE2WLu_iJDo3 ubRvTyoj_v0Hp3BOttb2h7KphCfGcgSTAkGAqKAsvnNb2z4HuKho2BR3NA6eoRObHghx6vdZjqHw 6C2NyI.Z2FXG_O8sKOBEOliNP8z.X.dG0jGClHv6Rq9YLn8JOFfg.8qBPYUtrWES4lmSCrDcKq7s GDkqa2dvLi6wlK.__gjDrCXQ4zf780NFOQt9OJNtHhBmTdW1wZ_c3yM4i2QyA3N..8mGQACkBdyP lBC7cU.R_HwlWbGaCwW4BSfc3Q46suhxBaz2sjYUr71jCEuel2l4R4XG7Qj0D35trVEFMxYKmEuM rxr.uJH3qYcK9Ti0zJQsNEjc0q8a7O0TE4bQ36uCMYGtAtP1Huo9NtZFxS6EHFKWxhxSJgbTxFwh R4kN17yVkFaYsc8d2p7HSgGA09FhOFgXUZp.BmxsSu1pgbezKqKwgWr.53U.5K2fKUWcpLU8ly.H RM9XMYddWHQgqaSEzYpitdEzsPNyqDN64.LTwIwyUi.kAi7PaVmJ02ZsaJNy9c3XOYswSTupxxze c0KeKALQeBWKXydZJJqI9ilaiqFvijTgeXKGuvHJlxpgW_wIU_VUott7g3HiP3PbMzfTVWOwuP1S b13.0U7wi1WsM4B4B4QBzzDqimIQ7eSNyD_KfCK7v0cVLwFqFPYaUnrOFMYMa741kOzMzYEL0rAD wcoj3HDdhb8sEI3pCMYmkF78g.cvFs8dI9MxQ.Xx1QIAoEZAFkF.Q7kuiMH4VKxd.sgYnGM9L6kc m4n.UsxV1As8ewjd8OwOwVvDQwPU76dgFWknL5rF6FRwILAWogCwLG.cf5A7zqYMUDPIfDHHbVFb eL9iDLzbe0FUkHxfPoL8MasDlvj2pf4cBl9GSAOsPo1xzLx_yp_zN1ey8QVysE5.fWP4IBg4EIPx fmw-- X-Sonic-MF: X-Sonic-ID: 9c638d58-0a8c-4f04-b105-7e9032e533c1 Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Thu, 27 Jun 2024 01:25:13 +0000 Received: by hermes--production-gq1-5b4c49485c-pghqv (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 72581de27489935816c740e21b1900d2; Thu, 27 Jun 2024 01:25:10 +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 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: Wed, 26 Jun 2024 18:24:59 -0700 Cc: FreeBSD ARM List Content-Transfer-Encoding: quoted-printable Message-Id: <5DC2D33F-A8DB-4542-B8B3-A131F660A395@yahoo.com> References: <5D5B6739-1685-43F5-80CC-E55603181D09@yahoo.com> <8F4F4B49-5ED3-4ACA-B0D3-356D8459BE95@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3774.600.62) 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:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Queue-Id: 4W8gqH2R2Pz4pRw On Jun 26, 2024, at 17:42, bob prohaska wrote: > On Tue, Jun 25, 2024 at 05:51:59PM -0700, Mark Millard wrote: >> On Jun 25, 2024, at 17:28, bob prohaska wrote: >>=20 >>> On Sun, Jun 23, 2024 at 10:17:53AM -0700, Mark Millard wrote: >>>> On Jun 23, 2024, at 07:28, bob prohaska wrote: >>>>>>=20 >>>>>> It should be possible to mount the media normally used >>>>>> on one of the RPi2B v1.1's on, say, an RPi4B. One could >>>>>> then set up enough context to, say, chroot into the >>>>>> armv7 file system and try executing the clone in that >>>>>> context. >>>>>>=20 >>>>>=20 >>>>> That's physically not hard to do. Just power down the stable/14 >>>>> Pi2 and plug the Pi2's boot disk into the Pi4. >>>>=20 >>>> Up to power issues, if bus powered. >>>>=20 >>>>>> The result would be using the RPi4B aarch64 kernel and >>>>>> the armv7 world. If that has no problems, then the armv7 >>>>>> kernel likely has problems that contribute but the armv7 >>>>>> world would be less likely to. >>>>>>=20 >>>>>> Doing this can get into first using the likes of >>>>>> (notation presumes use of /mnt at the mount point used >>>>>> above): >>>>>>=20 >>>>>> # mount -tdevfs devfs /mnt/dev/ >>>>>> and possibly: >>>>>> # mount -tfdescfs none /mnt/fd/ >>>>=20 >>>> That last should have been: >>>>=20 >>>> # mount -tfdescfs none /mnt/dev/fd/ >>>>=20 >>>> Use of the likes of "mkdir -p . . ." may be required in >>>> order to have the directories for use as mount points >>>> if they are missing. >>>>=20 >>>>>>=20 >>>>>> before doing the likes of: >>>>>>=20 >>>>>> # chroot /mnt/ >>>>>> # # EXPERIMENT HERE >>>>>> # exit >>>>>>=20 >>>>> I didn't realise that armv7 binaries would run under >>>>> an aarch64 kernel. Most convenient! >>>>=20 >>>> Such can be used to have a faster way to build armv7 >>>> packages, that also allows larger armv7 processes to >>>> be involved (but still 32-bit limited with part of >>>> the address space reserved, for sure). Not only that, >>>> the process size limit is not a system >>>> size limit: An RPi4B with 8 GiBytes of RAM can have >>>> several armv7 processes at once that total over 4 >>>> GiBytes of RAM in use at the time, no swapping >>>> needing to be involved. >>>>=20 >>>>>> Also, after exiting the chroot session, one would >>>>>> do the likes of: >>>>>>=20 >>>>>> # umount /mnt/dev/ >>>>>> and possibly: >>>>>> # umount /mnt/fd/ >>>>=20 >>>> That should have been (order dependent for fd inside dev): >>>>=20 >>>> possibly: >>>> # umount /mnt/dev/fd/ >>>>=20 >>>> then: >>>>=20 >>>> # umount /mnt/dev/ >>>>=20 >>>>>>=20 >>>>>> # umount /mnt/ >>>>>>=20 >>>>> Thank you for the cleanup details! >>>>=20 >>>=20 >>> I ended up trying the experiment twice. The first try used the = mistaken >>> mount -tfdescfs none /mnt/fd/ but since it was noted "possibly" I = ignored >>> the error and the git clone command completed successfully. After = noticing >>> your correction, the experiment was repeated and the clone failed: >>>=20 >>> root@nemesis:/usr/2ndgittest # git clone --depth=3D1 -o freebsd = ssh://anongit@192.158.248.9/src.git . >>> Cloning into '.'... >>> remote: Enumerating objects: 104636, done. >>> remote: Counting objects: 100% (104636/104636), done. >>> remote: Compressing objects: 100% (88903/88903), done. >>> client_loop: send disconnect: Broken pipe88.34 MiB | 165.00 KiB/s >>=20 >> The above "client_loop: send disconnect: Broken pipe" >> seems to be the original error here. >>=20 >> It would be interesting to have evidence of how >> repeatable such is and what variety of other >> results happen. >=20 > Using chroot on the aarch64 -current Pi4 I made > repeated clones onto the mechanical hard disk > hosting the armv7 stable/14 filesystem. Couldn't > reproduce the error above in five tries. > Transcript at = http://www.zefox.net/~fbsd/rpi2/git_problems/readme_aarch64 Sounds like the armv7 kernel likely has some issues of its own --instead of armv7 world. > Then I moved the disk to an armv7 -current Pi2 > using the same chroot setup, the clone with=20 > --depth=3D1 worked so I dropped the depth limit > and repeated; that caused a kernel panic. 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? > 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 =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. > : 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 =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 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 #=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 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=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 =3D=3D=3D Mark Millard marklmi at yahoo.com