Date: Sat, 12 Aug 2023 10:21:24 -0700 From: Mark Millard <marklmi@yahoo.com> To: Current FreeBSD <freebsd-current@freebsd.org> Subject: 14.0-APLHA1 snapshot use of kyua: An odd backtrace that appeared on the aarch64 console (and logs) Message-ID: <E3CF948A-CE27-417B-9297-D1D96778D059@yahoo.com> References: <E3CF948A-CE27-417B-9297-D1D96778D059.ref@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I ran the block of zfs tests on a snapshot 14.0-APLHA1 install used to boot and operate a Windows Dev Ket 2023. I just noticed a non-panic/non-crash backtrace had been output to the console (and related logs): . . . GEOM: md0: the primary GPT table is corrupt or invalid. GEOM: md0: using the secondary instead -- recovery strongly advised. GEOM: md1: the primary GPT table is corrupt or invalid. GEOM: md1: using the secondary instead -- recovery strongly advised. GEOM: md2: the primary GPT table is corrupt or invalid. GEOM: md2: using the secondary instead -- recovery strongly advised. GEOM: md3: the primary GPT table is corrupt or invalid. GEOM: md3: using the secondary instead -- recovery strongly advised. got error -2 on name 1 on op 3 KDB: stack backtrace: db_trace_self() at db_trace_self db_trace_self_wrapper() at db_trace_self_wrapper+0x30 zfs_lookup_internal() at zfs_lookup_internal+0xb8 zfs_rename() at zfs_rename+0x128 zfs_replay_rename() at zfs_replay_rename+0xa4 zil_replay_log_record() at zil_replay_log_record+0x1b0 zil_parse() at zil_parse+0x360 zil_replay() at zil_replay+0xdc zfsvfs_setup() at zfsvfs_setup+0x1fc $x.0() at $x.0+0x6b0 vfs_domount_first() at vfs_domount_first+0x24c vfs_domount() at vfs_domount+0x2cc vfs_donmount() at vfs_donmount+0x844 sys_nmount() at sys_nmount+0x60 do_el0_sync() at do_el0_sync+0x520 handle_el0_sync() at handle_el0_sync+0x44 --- exception, esr 0x56000000 GEOM_NOP: Device md0.nop created. GEOM_NOP: Device md1.nop created. GEOM_NOP: Device md2.nop created. GEOM_NOP: Device md3.nop created. GEOM_NOP: Device md4.nop created. GEOM_NOP: Device md5.nop created. GEOM_NOP: Device md0.nop removed. GEOM_NOP: Device md1.nop removed. GEOM_NOP: Device md2.nop removed. GEOM_NOP: Device md3.nop removed. GEOM_NOP: Device md4.nop removed. GEOM_NOP: Device md5.nop removed. . . . For reference . . . I had set up md0 .. md5, each 1g swap backed, and, in /etc/kyua/kyua.conf , had used: test_suites.FreeBSD.disks =3D '/dev/md0 /dev/md1 /dev/md2 /dev/md3 = /dev/md4 /dev/md5' (I the future I'll use file backed that are larger.) Note: After dropping a copy of the extra files from the rpi-arm64 snapshots's msdosfs into the rock64 installation's msdosfs, the rock64 snapshot install on the USB media then can boot and operate every aarch64 system I have access to. (It is something I've done for a long time.) The rock64 having an unusually large area for u-boot related dd'ing could serve well for dd'ing various alternatives and testing them: overlapping the other file systems is unlikely. Such can be handy for having a uniform testing environment. =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E3CF948A-CE27-417B-9297-D1D96778D059>