Re: fsck segfaults on rpi3 running 13-stable (and on 14-CURRENT analyzing the same file system that resulted from the 13-STABLE crash)

On Feb 18, 2023, at 13:06, bob prohaska <fbsd@www.zefox.net> wrote:

> On Fri, Feb 17, 2023 at 04:23:59PM -0800, Mark Millard wrote:
> [huge snip] 
>> Looks like that is one of the messages for problems
>> fsck_ffs does not attempt to deal with (probably for
>> good reasons in each case/context). 
> 
> Since there wasn't much to lose I tried deleting
> the bad inodes using fsdb clri and re-running fsck.
> 
> After maybe a dozen cycles fsck reported the filesystem
> clean and, to a superficial inspection, intact. 
> 
> The disk rebooted, ran git reset --hard and is now running
> buildworld. Fingers and toes are now fully crossed 8-)
> 
> Is it possible to continue updating the -current Pi3 using
> git while preserving the hand-applied changes to /sbin/fsck?

Making some presumptions about your source path
( /usr/src/ ) . . . (Beware that I do not use
git pull but do fetch and merge --ff-only
separately. So I'm guessing some below.)

# git -C /usr/src/ status
(Any surprises? Deal with such. YOu might want
to restore sources that you know you will just
want the newer official content of.)

# git -C /usr/src/ stash push
# git -C /usr/src/ pull
# git -C /usr/src/ stash apply

AT THIS POINT IT MIGHT INDICATE CONFLICTS IF THE
fsck_fft SOURCE HAS BEEN UPDATED. There is more
to it if/when that happens. You might choose to
restore the official source, for example. I'm not
listing explicit steps for any alternatives.

Sometime later when things are known okay but
likely before the next stash push:
# git -C /usr/src/ stash drop

I'll note that you could first "cd /usr/src/" instead
of using "-C /usr/src/" on the command lines.

> Simply running git pull results in complaints about unstaged
> changes. IIRC, subversion didn't care. 
> 
> [another huge snip}
> 
> 
>> 
>> Beyond that, things with floating-point use in
>> multi-threading contexts looks to be significantly
>> broken in main [so: 14] for now. (This was involved
>> in your FreeBSD crash based on the the backtrace
>> showed.)
>> 
>> If you try to set up another armv7 context, I suggest,
>> for now, staying before:
>> 
>> commit 6926e2699ae55080f860488895a2a9aa6e6d9b4d
>> Author: Kornel Dul??ba <kd@FreeBSD.org>
>> AuthorDate: 2023-02-04 12:59:30 +0000
>> Commit: Kornel Dul??ba <kd@FreeBSD.org>
>> CommitDate: 2023-02-04 19:21:43 +0000
>> 
>> arm: Add support for using VFP in kernel
>> 
>> This would be until a list of issues have been
>> addressed. I've reported how to produce 3
>> distinct failures, 2 of which hit KASSERT
>> panics, and the other one is for ending up with
>> floating-point values from the wrong thread
>> (but same process). More may be identified
>> and fixed before things generally work again
>> for main for armv7 FreeBSD.
> 
> The relative merits of aarch64 vs armv7 are a bit
> muddy from my point of view. The only real objection
> to aarch64 on the Pi3 is running out of memory
> during buildworld.

Using armv7 on an RPi3B runs out of RAM+SWAP
sooner because it only allows a much smaller
swapspace due to the armv7 code's addressing
limitations, as I understand. (It also ends
up mistuned at a much smaller swap space
size.)

So to allow (near) maximum RAM+SWAP for a
reasonably tuned context: use aarch64 on
RPi3B's.

> On a "production" machine that
> happens infrequently and needn't be fast, so -j2
> solves the problem. I was interested in trying to
> use armv7 on the Pi3, but unless it works "out of
> the box" it's probably more trouble than benefit. 

All sufficiently recent main native-armv7 kernels
are broken because of the VFP handling changes,
at least for hardware with VFP.

Your original report was for the buildworld failure
on a RPi2. Was that v1.1 so armv7-only (no aarch64
present)?

The original backtrace indicates a problem that
is tied to the armv7 kernel new VFP handling that
is not working well yet. That would also apply to
a RPi3B using an armv7 kernel. FYI: I did my
how-to-reproduce investigations on a OrPi+2e armv7,
not on a RPi* .

===
Mark Millard
marklmi at yahoo.com