Date: Tue, 18 Apr 2023 23:55:17 -0700 From: Mark Millard <marklmi@yahoo.com> To: Current FreeBSD <freebsd-current@freebsd.org>, freebsd-arm <freebsd-arm@freebsd.org> Cc: "mjg@freebsd.org" <mjg@FreeBSD.org>, "pjd@freebsd.org" <pjd@FreeBSD.org>, Kyle Evans <kevans@FreeBSD.org> Subject: Re: The import of openzfs vs. armv7: boot crashs Message-ID: <ED7E6443-A5AF-4A4F-938B-1A144497A20F@yahoo.com> In-Reply-To: <6CB8D120-1600-40E6-8A1E-87E709DCEC8F@yahoo.com> References: <6CB8D120-1600-40E6-8A1E-87E709DCEC8F@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Apr 18, 2023, at 15:44, Mark Millard <marklmi@yahoo.com> wrote: > = https://github.com/openzfs/zfs/commit/d0cbd9feaf5b82130f2e679256c71e0c7413= aae9 >=20 > does not seem to cover armv7, just aarch64. (FreeBSD disabled > floating point for both armv7 and aarch64 but that is a > different change than above.) >=20 > I used: >=20 > = FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20230406-f21faa67ab6b-262010.img.= xz >=20 > booted an RPi2B v1.1 and tried (note the KSTACK_PAGES notice and the > "undefined floating point instruction" notice): >=20 > # zpool import > ZFS NOTICE: KSTACK_PAGES is 2 which could result in stack overflow = panic! > Please consider adding 'options KSTACK_PAGES=3D4' to your kernel = config > panic: undefined floating point instruction in supervisor mode > cpuid =3D 2 > time =3D 1680784610 > KDB: stack backtrace: > db_trace_self() at db_trace_self > pc =3D 0xc05eb154 lr =3D 0xc007a688 = (db_trace_self_wrapper+0x30) > sp =3D 0xdd25c480 fp =3D 0xdd25c598 > db_trace_self_wrapper() at db_trace_self_wrapper+0x30 > pc =3D 0xc007a688 lr =3D 0xc02eb1b4 (vpanic+0x140) > sp =3D 0xdd25c5a0 fp =3D 0xdd25c5c0 > r4 =3D 0x00000100 r5 =3D 0x00000000 > r6 =3D 0xc0736bfc r7 =3D 0xc0b1aea8 > vpanic() at vpanic+0x140 > pc =3D 0xc02eb1b4 lr =3D 0xc02eaf94 (doadump) > sp =3D 0xdd25c5c8 fp =3D 0xdd25c5cc > r4 =3D 0xc0b92210 r5 =3D 0x00000000 > r6 =3D 0xc0610ca0 r7 =3D 0xf4210a0d > r8 =3D 0xddf32e4c r9 =3D 0x00000013 > r10 =3D 0xdd25c6c0 > doadump() at doadump > pc =3D 0xc02eaf94 lr =3D 0xc0610eb0 (vfp_new_thread) > sp =3D 0xdd25c5d4 fp =3D 0xdd25c638 > r4 =3D 0xdd25c6c0 r5 =3D 0xdd25c5cc > r6 =3D 0xc02eaf94 r10 =3D 0xdd25c5d4 > vfp_new_thread() at vfp_new_thread > pc =3D 0xc0610eb0 lr =3D 0xc060ff84 = (undefinedinstruction+0x178) > sp =3D 0xdd25c640 fp =3D 0xdd25c6b8 > undefinedinstruction() at undefinedinstruction+0x178 > pc =3D 0xc060ff84 lr =3D 0xc05edaa8 (exception_exit) > sp =3D 0xdd25c6c0 fp =3D 0xdd25c750 > r4 =3D 0x20000013 r5 =3D 0xde45e000 > r6 =3D 0xdd25c890 r7 =3D 0xdd25c8b0 > r8 =3D 0x00000000 r9 =3D 0x00000000 > r10 =3D 0xdd25c8c0 > exception_exit() at exception_exit > pc =3D 0xc05edaa8 lr =3D 0xddf31f20 (K256) > sp =3D 0xdd25c750 fp =3D 0xdd25c750 > r0 =3D 0xdd25c890 r1 =3D 0xde45e000 > r2 =3D 0xde45e400 r3 =3D 0xddf309fc > r4 =3D 0x00000400 r5 =3D 0xde45e000 > r6 =3D 0xdd25c890 r7 =3D 0xdd25c8b0 > r8 =3D 0x00000000 r9 =3D 0x00000000 > r10 =3D 0xdd25c8c0 r12 =3D 0xdd25c7a0 > zfs_sha256_block_neon() at zfs_sha256_block_neon+0x1c > pc =3D 0xddf32e4c lr =3D 0xc0946e8c (pcpup) > sp =3D 0xdd25c758 fp =3D 0xc0b0aeec > r4 =3D 0xc0919610 r5 =3D 0xc0919630 > r6 =3D 0xc0919618 r7 =3D 0x642ebce2 > r8 =3D 0xc0b1b0ec r9 =3D 0xc0915e88 > r10 =3D 0xc0b1b0dc > Fatal kernel mode data abort: 'Translation Fault (L1)' on read > trapframe: 0xdd25c330 > FSR=3D00000005, FAR=3D95e29398, spsr=3D200000d3 > r0 =3Ddd25c424, r1 =3D81000000, r2 =3D95e29395, r3 =3D55555555 > r4 =3Dc08ae93c, r5 =3D00004aa0, r6 =3D00004aa0, r7 =3Dc08d3e3c > r8 =3D00000001, r9 =3Dc079567a, r10=3D0000000b, r11=3Ddd25c3e0 > r12=3D00000000, ssp=3Ddd25c3c4, slr=3D00000001, pc =3Dc0610308 >=20 > panic: Fatal abort > . . . (repeats over and over) . . . I probably need to explain the subject line's reference to boot crashes, given the specific crash that I show is not that. I reported a simpler context than booting ZFS media: boot a UFS snapshot then force ZFS to start with no ZFS pools even being present. It is the same simplified type of test that I previously had reported for aarch64 as a simpler/easier test to set up than an actual root on ZFS crash that I had originally gotten for aarch64. The test I present should imply that a boot of, say, a root on ZFS context would crash. =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?ED7E6443-A5AF-4A4F-938B-1A144497A20F>