Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 [separate aarch64 panic for zpool import]

can you try with this:

diff --git a/sys/contrib/openzfs/include/os/linux/kernel/linux/simd_aarch64.h
b/sys/contrib/openzfs/include/os/linux/kernel/linux/simd_aarch64.h
index 16276b08c759..e1bca9ef140a 100644
--- a/sys/contrib/openzfs/include/os/linux/kernel/linux/simd_aarch64.h
+++ b/sys/contrib/openzfs/include/os/linux/kernel/linux/simd_aarch64.h
@@ -71,7 +71,7 @@
 #define        ID_AA64PFR0_EL1         sys_reg(3, 0, 0, 1, 0)
 #define        ID_AA64ISAR0_EL1        sys_reg(3, 0, 0, 6, 0)

-#define        kfpu_allowed()          1
+#define        kfpu_allowed()          0
 #define        kfpu_begin()            kernel_neon_begin()
 #define        kfpu_end()              kernel_neon_end()
 #define        kfpu_init()             (0)


On 4/7/23, Mark Millard <marklmi@yahoo.com> wrote:
> Turns out that as of this commit aarch64 (Cortex-A72 and Cortex-A57
> examples reported) gets the following even when no zfs media is
> present (UFS boot):
>
> # zpool import
>  x0: ffff0000f0fa9168 (ucom_cons_softc + efbf1bb8)
>  x1: ffff0000ff900000 ($d.1 + afa318)
>  x2: ffff0000ff900400 ($d.1 + afa718)
>  x3: ffff0000fec1b0a4 (sha_incremental + 0)
>  x4:                0
>  x5:           100000
>  x6:         8e16db93
>  x7:                0
>  x8: ffff0000feb06168 (tf_sha256_neon + 0)
>  x9: ffff0000fea931fb ($d.1 + b)
> x10: ffff0000feb045f4 (SHA2Update + f4)
> x11:               29
> x12:                1
> x13:                0
> x14:                0
> x15:                2
> x16: ffff0000feaf7500 ($d.0 + 0)
> x17: ffff000000476cf0 (nanouptime + 0)
> x18: ffff0000f0fa9000 (ucom_cons_softc + efbf1a50)
> x19: ffff0000f0fa9168 (ucom_cons_softc + efbf1bb8)
> x20:              400
> x21: ffff0000ff900000 ($d.1 + afa318)
> x22: ffff0000f0fa9198 (ucom_cons_softc + efbf1be8)
> x23:                0
> x24:                0
> x25:                0
> x26: ffff0000fed2df70 (sha256_neon_impl + 0)
> x27:              203
> x28:               31
> x29: ffff0000f0fa9040 (ucom_cons_softc + efbf1a90)
>  sp: ffff0000f0fa9000
>  lr: ffff0000feb04668 (SHA2Update + 168)
> elr: ffff0000feaf8684 (zfs_sha256_block_neon + 14)
> spsr:         20000045
> esr: 000000001fe00000
> panic: VFP exception in the kernel
> cpuid = 3
> time = 1680786034
> KDB: stack backtrace:
> db_trace_self() at db_trace_self
> db_trace_self_wrapper() at db_trace_self_wrapper+0x30
> vpanic() at vpanic+0x13c
> panic() at panic+0x44
> do_el1h_sync() at do_el1h_sync+0x210
> handle_el1h_sync() at handle_el1h_sync+0x10
> --- exception, esr 0xffff0000f0fa9198
> (null)() at 0x400
> KDB: enter: panic
> [ thread pid 1446 tid 100101 ]
> Stopped at      kdb_enter+0x44: undefined       f905c27f
> db>
>
> The above was produced via using an artifact build's
> kernel based on that exact commit:
>
> https://artifact.ci.freebsd.org/snapshot/main/2a58b312b62f908ec92311d1bd8536dbaeb8e55b/arm64/aarch64/kernel.txz
>
> By contrast, the prior commit had an artifact build
> as well, but it's kernel does not get the panic for
> zpool import :
>
> https://artifact.ci.freebsd.org/snapshot/main/b98fbf3781df16f7797b2bbeabf205dc7d4985ae/arm64/aarch64/kernel.txz
>
> See also:
>
> https://lists.freebsd.org/archives/freebsd-current/2023-April/003417.html
>
> ===
> Mark Millard
> marklmi at yahoo.com
>
>


-- 
Mateusz Guzik <mjguzik gmail.com>