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

On Apr 7, 2023, at 16:29, Kyle Evans <[email protected]> wrote:

> On Fri, Apr 7, 2023 at 4:54 PM Mateusz Guzik <[email protected]> wrote:
>> 
>> On 4/7/23, Mark Millard <[email protected]> wrote:
>>> On Apr 7, 2023, at 14:26, Mateusz Guzik <[email protected]> wrote:
>>> 
>>>> On 4/7/23, Mateusz Guzik <[email protected]> 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