Re: aarch64 based on main 58661b3ba9eb : panic for "ufs_dirbad: /: bad dir ino 66371814 at offset 106496: mangled entry"

2021-01-05 Thread Mark Millard
On 2021-Jan-5, at 13:28, Mark Murray  wrote:

>> On 5 Jan 2021, at 20:15, Mark Millard  wrote:
>> 
>> The machine is a MACCHIATOBin Double Shot.
> 
> Thanks for the warning :-)
> 
> I'm using an MBin/DS as my firewall/gateway, and in its Copious Free Timeā„¢, 
> an ARM64 build-box.
> 
> How recent is your UEFI SD boot image? Are you maintaining a history and 
> download site?
> 

[Note: This reply has no information related to the problem
report. I'm just answering other questions.]

I was given a UEFI materials to use a fair time ago and they
have worked sufficiently for my use. Absent a FreeBSD port
that I can use to build UEFI updates in a normal, ports-style
way, I've left it alone in this area. The UEFI screen reports:

MARVELL UEFI 18.09.0

The boot sequence reports:

BootROM - 2.03

Starting CP-0 IOROM 1.07

Booting from SD 0 (0x29)

Found valid image at boot postion 0x000

lNOTICE:  Starting binary extension
NOTICE:  SVC: SW Revision 0x0. SVC is not supported
mv_ddr: mv_ddr-armada-18.09.2-g99d7725 (Oct 29 2018 - 23:32:10)
mv_ddr: completed successfully
NOTICE:  Cold boot
NOTICE:  Booting Trusted Firmware
NOTICE:  BL1: v1.5(release):v1.5-219-g711ecd3 (Marvell-armada-18.09.4)
NOTICE:  BL1: Built : 23:32:27, Oct 29 2018
NOTICE:  BL1: Booting BL2
NOTICE:  BL2: v1.5(release):v1.5-219-g711ecd3 (Marvell-armada-18.09.4)
NOTICE:  BL2: Built : 23:32:35, Oct 29 2018
BL2: Initiating SCP_BL2 transfer to SCP
NOTICE:  SCP_BL2 contains 5 concatenated images
NOTICE:  Skipping MSS CP3 related image
NOTICE:  Skipping MSS CP2 related image
NOTICE:  Load image to CP1 MSS AP0
NOTICE:  Loading MSS image from addr. 0x40265f4 Size 0x1ad8 to MSS at 0xf428
NOTICE:  Done
NOTICE:  Load image to CP0 MSS AP0
NOTICE:  Loading MSS image from addr. 0x40280cc Size 0x1ad8 to MSS at 0xf228
NOTICE:  Done
NOTICE:  Load image to AP0 MSS
NOTICE:  Loading MSS image from addr. 0x4029ba4 Size 0x4a40 to MSS at 0xf058
NOTICE:  Done
NOTICE:  BL1: Booting BL31
lNOTICE:  BL31: v1.5(release):v1.5-219-g711ecd3 (Marvell-armada-18.09.4)
NOTICE:  BL31: Built : 23:32:47, Oct 29 2018

Armada 8040 MachiatoBin Platform Init

(I'll stop with that.)

One issue is that between:

Booting [/boot/kernel/kernel]...   
|/-\No valid device tree blob found!
WARNING! Trying to fire up the kernel, but no device tree blob found!

and:

Setting hostuuid: **REPLACED**.
Setting hostid: **REPLACED**.
Starting file system checks:

there is no output to the serial console. If I ever have problems
in that time frame, recovery would be a problem unless I found
a better UEFI variation to put in place, one that outputs
everything to the serial console.


As for my use, no history/download site, nothing externally
visible at all. No use as a firewall or gateway either. But I do
some aarch64 and armv7 builds on it.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


aarch64 based on main 58661b3ba9eb : panic for "ufs_dirbad: /: bad dir ino 66371814 at offset 106496: mangled entry"

2021-01-05 Thread Mark Millard
Later I give notes about the context. The failure reported . . .

# panic: ufs_dirbad: /: bad dir ino 66371814 at offset 106496: mangled entry
cpuid = 0
time = 1609844528
KDB: stack backtrace:
db_trace_self() at db_trace_self_wrapper+0x30
 pc = 0x0081c654  lr = 0x0011ccb4
 sp = 0xac7a9e60  fp = 0xac7aa060

db_trace_self_wrapper() at vpanic+0x198
 pc = 0x0011ccb4  lr = 0x004be678
 sp = 0xac7aa070  fp = 0xac7aa0d0

vpanic() at panic+0x44
 pc = 0x004be678  lr = 0x004be4dc
 sp = 0xac7aa0e0  fp = 0xac7aa190

panic() at ufs_lookup_ino+0xc9c
 pc = 0x004be4dc  lr = 0x00775044
 sp = 0xac7aa1a0  fp = 0xac7aa270

ufs_lookup_ino() at vfs_cache_lookup+0xd0
 pc = 0x00775044  lr = 0x0059a768
 sp = 0xac7aa280  fp = 0xac7aa2f0

vfs_cache_lookup() at cache_fplookup_noentry+0x158
 pc = 0x0059a768  lr = 0x0059f270
 sp = 0xac7aa300  fp = 0xac7aa340

cache_fplookup_noentry() at cache_fplookup+0x440
 pc = 0x0059f270  lr = 0x0059c0f4
 sp = 0xac7aa350  fp = 0xac7aa410

cache_fplookup() at namei+0xd0
 pc = 0x0059c0f4  lr = 0x005a79fc
 sp = 0xac7aa420  fp = 0xac7aa4f0

namei() at kern_statat+0xa4
 pc = 0x005a79fc  lr = 0x005c82d8
 sp = 0xac7aa500  fp = 0xac7aa660

kern_statat() at sys_fstatat+0x2c
 pc = 0x005c82d8  lr = 0x005c888c
 sp = 0xac7aa670  fp = 0xac7aa780

sys_fstatat() at do_el0_sync+0x460
 pc = 0x005c888c  lr = 0x0083e048
 sp = 0xac7aa790  fp = 0xac7aa820

do_el0_sync() at handle_el0_sync+0x90
 pc = 0x0083e048  lr = 0x0081f224
 sp = 0xac7aa830  fp = 0xac7aa980

handle_el0_sync() at 0x403da3e8
 pc = 0x0081f224  lr = 0x403da3e8
 sp = 0xac7aa990  fp = 0xe630

KDB: enter: panic
[ thread pid 58718 tid 100101 ]
Stopped at  0x403dd330
db> 

Unfortunately the db> prompt is not taking any input so all I have
is the backtrace. The machine had been left idle after upgrading
from being head -r368820 based and other activity. The
"~/fbsd-based-on-what-freebsd-main.sh mm-src" and uname below just
happened to be the last things I did before leaving it idle
overnight. I've no clue how long it was idle before the panic
happened.

# ~/fbsd-based-on-what-freebsd-main.sh mm-src
58661b3ba9ebe82f889cbc336afe618ad7f7940a
CommitDate: 2021-01-04 15:12:03 -0800
085d41abe5f1 58661b3ba9eb (HEAD -> mm-src) mm-src snapshot for mm's patched 
build in git context.
# uname -apKU
FreeBSD FBSDmacch 13.0-CURRENT FreeBSD 13.0-CURRENT 
mm-src-c255600-g085d41abe5f1 GENERIC-NODBG  arm64 aarch64 1300133 1300133

I did a fair amount of activity after the upgrade but before leaving
it idle, lots of file system activity being involved.

The machine is a MACCHIATOBin Double Shot. FreeBSD was from a
cross build, using -mcpu=cortex-a72 . (I mention mcpu in part
because I've caught a missing-synchronization issue in the past
from doing this, something a cortex-a53 running the same
build did not show and for which the cortex-a72 did not show
the issue when running a plain aarch64 or cortex-a53 targeted
build. I'm not claiming to know that the wider range of behavior
for the cortex-a72 is involved here.)


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"