Re: Armv7 alpha-1 git problems [FYI: 14.0-ALPHA2 armv7 git clone (for example) unreliable on multiple system types]

From: Mark Millard <marklmi_at_yahoo.com>
Date: Thu, 24 Aug 2023 07:05:53 UTC
On Aug 23, 2023, at 13:54, bob prohaska <fbsd@www.zefox.net> wrote:

> An installation of alpha-1 on armv7 successfully built world and
> kernel, installed both and reported during reboot:
> FreeBSD 14.0-ALPHA2 armv7 1400096 #1 main-n264912-b1d3e2b77155: Tue Aug 22 22:40:54 UTC 2023
>    root@generic:/usr/obj/usr/src/arm.armv7/sys/GENERIC arm
> FreeBSD clang version 16.0.6 (https://github.com/llvm/llvm-project.git llvmorg-16.0.6-0-g7cbf1a259152)
> 
> The machine is a Pi2 v1.1 with a machanical hard disk, using bootcode.bin only on microSD
> 
> It then failed to complete git clone of ports.
> 
> The first failure was 
> # git clone ssh://anongit@git.FreeBSD.org/ports.git .
> Cloning into '.'...
> remote: Enumerating objects: 5931073, done.
> remote: Counting objects: 100% (936/936), done.
> remote: Compressing objects: 100% (120/120), done.
> error: inflate: data stream error (invalid code lengths set)0 KiB/s
> fatal: pack has bad object at offset 46086135: inflate returned -3
> fatal: fetch-pack: invalid index-pack output
> 
> This looks vaguely like problems observed trying to clone /usr/src,
> but not quite the same. That was worked around using sftp from another
> machine's sources, with a successful git pull following.

If that is what I think it was: I'd suggested that you
git clone via aarch64 and then locally deal with transfer
to the armv7 system. I had tested git clone on an aarch64
system and it had no problems. (armv7 was not set up at
the time.)

> Next, I tried
> # git clone https://git.FreeBSD.org/ports.git .
> Cloning into '.'...
> remote: Enumerating objects: 5931073, done.
> remote: Counting objects: 100% (936/936), done.
> remote: Compressing objects: 100% (120/120), done.
> panic: invalid signal8% (519050/5931073), 124.84 MiB | 719.00 KiB/s
> cpuid = 3
> time = 1692775267
> KDB: stack backtrace:
> db_trace_self() at db_trace_self
>         pc = 0xc05edb64  lr = 0xc0079c70 (db_trace_self_wrapper+0x30)
>         sp = 0xc4dc1b78  fp = 0xc4dc1c90
> db_trace_self_wrapper() at db_trace_self_wrapper+0x30
>         pc = 0xc0079c70  lr = 0xc02e9d8c (vpanic+0x140)
>         sp = 0xc4dc1c98  fp = 0xc4dc1cb8
>         r4 = 0x00000100  r5 = 0x00000000
>         r6 = 0xc076f4e8  r7 = 0xc0aeeec8
> vpanic() at vpanic+0x140
>         pc = 0xc02e9d8c  lr = 0xc02e9b6c (doadump)
>         sp = 0xc4dc1cc0  fp = 0xc4dc1cc4
>         r4 = 0xc4dc1d88  r5 = 0xd70112b8
>         r6 = 0xd70112b8  r7 = 0x00000007
>         r8 = 0xd7011000  r9 = 0xd7011000
>        r10 = 0xbfc19800
> doadump() at doadump
>         pc = 0xc02e9b6c  lr = 0xc02f047c (trapsignal+0x2f8)
>         sp = 0xc4dc1ccc  fp = 0xc4dc1d58
>         r4 = 0xbfc19800  r5 = 0xc4dc1cc4
>         r6 = 0xc02e9b6c r10 = 0xc4dc1ccc
> trapsignal() at trapsignal+0x2f8
>         pc = 0xc02f047c  lr = 0xc06119a4 (abort_handler+0x1a4)
>         sp = 0xc4dc1d60  fp = 0xc4dc1df8
>         r4 = 0xc4dc1d88  r5 = 0xd70112b8
>         r6 = 0x00000001  r7 = 0x00000007
>         r8 = 0x00000010  r9 = 0xd7011000
>        r10 = 0xbfc19800
> abort_handler() at abort_handler+0x1a4
>         pc = 0xc06119a4  lr = 0xc05f042c (exception_exit)
>         sp = 0xc4dc1e00  fp = 0xbfbfd6e8
>         r4 = 0xbfbfd6a8  r5 = 0x00000041
>         r6 = 0x3ae0921a  r7 = 0x0000009d
>         r8 = 0x3aed4000  r9 = 0xbfbfe8a0
>        r10 = 0x0000001c
> exception_exit() at exception_exit
>         pc = 0xc05f042c  lr = 0x204b807c (0x204b807c)
>         sp = 0xc4dc1e90  fp = 0xbfbfd6e8
>         r0 = 0xbfc19800  r1 = 0x3ae09074
>         r2 = 0x00000114  r3 = 0x3ae09070
>         r4 = 0xbfbfd6a8  r5 = 0x00000041
>         r6 = 0x3ae0921a  r7 = 0x0000009d
>         r8 = 0x3aed4000  r9 = 0xbfbfe8a0
>        r10 = 0x0000001c r12 = 0x3ae09058
> Unable to unwind into user mode
> KDB: enter: panic
> [ thread pid 1229 tid 100079 ]
> Stopped at      kdb_enter+0x54: ldrb    r15, [r15, r15, ror r15]!
> db> 
> 
> Not sure what to try next, probably update sources and build again.
> Any suggestions welcome!

On a OrangePi+ 2ed (so: cortex-a7 variant of armv7) with
(starting from dd of snapshot, leading to . . .):

# uname -apKU
FreeBSD armv7-main-snap 14.0-ALPHA2 FreeBSD 14.0-ALPHA2 armv7 1400094 #0 main-n264841-77013f29d048: Fri Aug 18 14:51:50 UTC 2023     root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm.armv7/sys/GENERIC arm armv7 1400094 1400094

The media is a USB3 SSD. Built-in EtherNet used.

After causing it to use latest instead of quarterly:

# pkg info pkg
The package management tool is not yet installed on your system.
Do you want to fetch and install it now? [y/N]: y
Bootstrapping pkg from pkg+http://pkg.FreeBSD.org/FreeBSD:14:armv7/latest, please wait...
Verifying signature with trusted certificate pkg.freebsd.org.2013102301... done
Installing pkg-1.20.5...
Extracting pkg-1.20.5: 100%
pkg-1.20.5
Name           : pkg
Version        : 1.20.5
Installed on   : Fri Jan  1 00:02:30 2010 UTC
Origin         : ports-mgmt/pkg
Architecture   : FreeBSD:14:armv7
Prefix         : /usr/local
Categories     : ports-mgmt
Licenses       : BSD2CLAUSE
Maintainer     : pkg@FreeBSD.org
WWW            : https://github.com/freebsd/pkg
Comment        : Package manager
Options        :
        DOCS           : on
Shared Libs provided:
        libpkg.so.4
Annotations    :
        FreeBSD_version: 1400094
Flat size      : 35.0MiB
Description    :
Package management tool

WWW: https://github.com/freebsd/pkg


(Clearly I had not dealt with setting having the time set
(2010 UTC). So I dealt with that before trying the clone.
Details not shown.)

# kldxref /boot/kernel/

# pkg install git
Updating FreeBSD repository catalogue...
Fetching meta.conf: 100%    163 B   0.2kB/s    00:01    
Fetching packagesite.pkg: 100%    6 MiB   3.0MB/s    00:02    
Processing entries: 100%
FreeBSD repository update completed. 29522 packages processed.
All repositories are up to date.
Updating database digests format: 100%
The following 36 package(s) will be affected (of 0 checked):
. . .
[36/36] Installing git-2.41.0...
. . .

# mkdir /var/tmp/git-clone-test/
# cd /var/tmp/git-clone-test/

Going after the crash case:

# git clone https://git.FreeBSD.org/ports.git .
Cloning into '.'...
remote: Enumerating objects: 5931191, done.
remote: Counting objects: 100% (936/936), done.
remote: Compressing objects: 100% (120/120), done.
fatal: SHA-1 appears to be part of a collision attack: 1a276175c070910e3b53155ecc5cb416cdb95750
fatal: fetch-pack: invalid index-pack output

So: not the same in detail but looks like a problem.
I'll note that it got near 20% transferred before
that happened.


Trying the other type (ssh):

# git clone ssh://anongit@git.FreeBSD.org/ports.git .
Cloning into '.'...
. . .
remote: Enumerating objects: 5931191, done.
remote: Counting objects: 100% (936/936), done.
remote: Compressing objects: 100% (120/120), done.
Receiving objects: 100% (5931191/5931191), 1.11 GiB | 463.00 KiB/s, done.
fatal: pack is corrupted (SHA1 mismatch)
fatal: fetch-pack: invalid index-pack output

(Note the lack of complaints by the snapshot's
debug kernel.)


I conclude that the issue is likely a more general
armv7 networking problem, not something specific to
RPi2 v1.1's.


===
Mark Millard
marklmi at yahoo.com