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 = 0xffff00000081c654 lr = 0xffff00000011ccb4 sp = 0xffff0000ac7a9e60 fp = 0xffff0000ac7aa060 db_trace_self_wrapper() at vpanic+0x198 pc = 0xffff00000011ccb4 lr = 0xffff0000004be678 sp = 0xffff0000ac7aa070 fp = 0xffff0000ac7aa0d0 vpanic() at panic+0x44 pc = 0xffff0000004be678 lr = 0xffff0000004be4dc sp = 0xffff0000ac7aa0e0 fp = 0xffff0000ac7aa190 panic() at ufs_lookup_ino+0xc9c pc = 0xffff0000004be4dc lr = 0xffff000000775044 sp = 0xffff0000ac7aa1a0 fp = 0xffff0000ac7aa270 ufs_lookup_ino() at vfs_cache_lookup+0xd0 pc = 0xffff000000775044 lr = 0xffff00000059a768 sp = 0xffff0000ac7aa280 fp = 0xffff0000ac7aa2f0 vfs_cache_lookup() at cache_fplookup_noentry+0x158 pc = 0xffff00000059a768 lr = 0xffff00000059f270 sp = 0xffff0000ac7aa300 fp = 0xffff0000ac7aa340 cache_fplookup_noentry() at cache_fplookup+0x440 pc = 0xffff00000059f270 lr = 0xffff00000059c0f4 sp = 0xffff0000ac7aa350 fp = 0xffff0000ac7aa410 cache_fplookup() at namei+0xd0 pc = 0xffff00000059c0f4 lr = 0xffff0000005a79fc sp = 0xffff0000ac7aa420 fp = 0xffff0000ac7aa4f0 namei() at kern_statat+0xa4 pc = 0xffff0000005a79fc lr = 0xffff0000005c82d8 sp = 0xffff0000ac7aa500 fp = 0xffff0000ac7aa660 kern_statat() at sys_fstatat+0x2c pc = 0xffff0000005c82d8 lr = 0xffff0000005c888c sp = 0xffff0000ac7aa670 fp = 0xffff0000ac7aa780 sys_fstatat() at do_el0_sync+0x460 pc = 0xffff0000005c888c lr = 0xffff00000083e048 sp = 0xffff0000ac7aa790 fp = 0xffff0000ac7aa820 do_el0_sync() at handle_el0_sync+0x90 pc = 0xffff00000083e048 lr = 0xffff00000081f224 sp = 0xffff0000ac7aa830 fp = 0xffff0000ac7aa980 handle_el0_sync() at 0x403da3e8 pc = 0xffff00000081f224 lr = 0x00000000403da3e8 sp = 0xffff0000ac7aa990 fp = 0x0000ffffffffe630 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)Received on Tue Jan 05 2021 - 19:16:02 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:26 UTC