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

On Sat, Apr 8, 2023 at 5:24 AM Mateusz Guzik <mjguzik@gmail.com> wrote:
>
> On 4/8/23, 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.
> >
>
> Mate, that's one confusing email.
>

Sorry, this was misdirected anger around this series of crappery.

> I had seen the upstream review, apparently there is opposition to the
> patch, it is clearly not going to land within hours.
>

The opposition is notably from a person that does not actually work on
this platform, and IMO has no bearing on our downstream review. We'll
get past him eventually, because this is what needs to happen.

> Whatever the Real Fix(tm) might be, I'm confident my change has no
> impact on work on it, past the need to flip kfpu_allowed back to 1.
>
> At the same time things were broken to the point where aarch64 + zfs
> literally did not boot. Once more, I fail to see how restoring basic
> operation by fipping a macro to 0 throws any wrenches into the effort
> to get simd working.
>

Thanks!

> If anything the question is how come a clearly *not* implemented simd
> support got kfpu_allowed set to 1.
>

Your guess is as good as mine -- it clearly could not have been tested
at all, I have no clue why they didn't err on the side of caution and
avoid fpu usage.

Thanks,

Kyle Evans