Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 [separate aarch64 panic for zpool import]
Date: Sat, 08 Apr 2023 00:54:20 UTC
On Apr 7, 2023, at 16:29, Kyle Evans <kevans@freebsd.org> wrote: > On Fri, Apr 7, 2023 at 4:54 PM Mateusz Guzik <mjguzik@gmail.com> wrote: >> >> On 4/7/23, Mark Millard <marklmi@yahoo.com> wrote: >>> On Apr 7, 2023, at 14:26, Mateusz Guzik <mjguzik@gmail.com> wrote: >>> >>>> On 4/7/23, Mateusz Guzik <mjguzik@gmail.com> wrote: >>>>> 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) >>>>> >>>>> >>>> >>>> ops, wrong file >>>> >>>> diff --git a/sys/contrib/openzfs/include/os/freebsd/spl/sys/simd_arm.h >>>> b/sys/contrib/openzfs/include/os/freebsd/spl/sys/simd_arm.h >>>> index 178fbc3b3c6e..c462220289d6 100644 >>>> --- a/sys/contrib/openzfs/include/os/freebsd/spl/sys/simd_arm.h >>>> +++ b/sys/contrib/openzfs/include/os/freebsd/spl/sys/simd_arm.h >>>> @@ -46,7 +46,7 @@ >>>> #include <machine/elf.h> >>>> #include <machine/md_var.h> >>>> >>>> -#define kfpu_allowed() 1 >>>> +#define kfpu_allowed() 0 >>>> #define kfpu_initialize(tsk) do {} while (0) >>>> #define kfpu_begin() do {} while (0) >>>> #define kfpu_end() do {} while (0) >>> >>> It will take me a bit to setup a separate build/install >>> context for the source code vintage involved. Then more >>> time to do the build, install, and test. (I'm keeping >>> my normal environments completely before the mess.) >>> >>> FYI: >>> >>> I have used the artifact build just after your pair of zfs >>> related updates to confirm the VFP problem is still in >>> place as of that point: >>> >>> https://artifact.ci.freebsd.org/snapshot/main/5e2e3615d91f9c0c688987915ff5c8de23c22bde/arm64/aarch64/kernel.txz >>> >>> (No artifact build was exactly at either of your commits.) >>> >>> === >>> Mark Millard >>> marklmi at yahoo.com >>> >>> >> >> I have arm64 + zfs at $job and just verified the above lets it boot >> again, so I committed already. >> > > This was a known issue that we were working on fixing properly over in > https://reviews.freebsd.org/D39448... this really could have waited > just a little bit longer. This problem was already brought up in > response to the commit in question days ago. FYI: I substituted the aarch64 kernel from: https://artifact.ci.freebsd.org/snapshot/main/d6e24901349dc34a2f8040d67730eb2d510073ab/arm64/aarch64/kernel.txz into the 2023-Apr-06 aarch64 snapshot based media that I'd been testing with, rebooted, and tried the test. The result was good: # zpool import ZFS filesystem version: 5 ZFS storage pool version: features support (5000) The use of appropriate: https://artifact.ci.freebsd.org/snapshot/main/d6e24901349dc34a2f8040d67730eb2d510073ab/*/*/kernel*.txz may be a way to get to a more normal status for then making progress in a more normal manor, not just for aarch64 and armv7 since the earlier zfs-update fixup drafts are also in place at that point. Of course, one needs a way to make the substitutions of the kernel materials into whatever type of the boot media (UFS or ZFS) is in involved. === Mark Millard marklmi at yahoo.com