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