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

Mark Millard <[email protected]>
Newsgroups gmane.os.freebsd.devel.arm
Message-ID <[email protected]>
On Aug 23, 2023, at 13:54, bob prohaska <[email protected]> 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://[email protected]/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     [email protected]:/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     : [email protected]
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://[email protected]/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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.