Date: Sat, 8 Apr 2023 21:40:37 -0500 From: Kyle Evans <kevans@freebsd.org> To: Mateusz Guzik <mjguzik@gmail.com> Cc: Kyle Evans <kevans@freebsd.org>, Mark Millard <marklmi@yahoo.com>, dev-commits-src-main@freebsd.org, Current FreeBSD <freebsd-current@freebsd.org>, freebsd-arm <freebsd-arm@freebsd.org>, John F Carr <jfc@mit.edu> Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 [separate aarch64 panic for zpool import] Message-ID: <CACNAnaG3m7%2BBmJFYdBHnQLhtnwzTX1f4da2ro%2Bugz6%2BZN6y=xg@mail.gmail.com> In-Reply-To: <CAGudoHE2XgG0-zNyfBTRHPqTrXsVy5GuTu=USHLHmp1qqXgHSQ@mail.gmail.com> References: <F6C7D902-88AD-4725-A63B-CCE2960CCB3B.ref@yahoo.com> <F6C7D902-88AD-4725-A63B-CCE2960CCB3B@yahoo.com> <CAGudoHEuMj8hf2=BjN30udi2nxN7QgU8nRvmikj7tFLAJg5dWw@mail.gmail.com> <CAGudoHFt3aonOXJsgYTLwSY141p1YjGOrcO2t1vocDLXZuXyTA@mail.gmail.com> <3A019D10-E520-4C11-AE9F-4EA5D99B9B07@yahoo.com> <CAGudoHGc76uuMVR9EJhTQs-4rO%2BnrO4FTxzEWQgeTrY6aR5z=Q@mail.gmail.com> <CACNAnaGT-10vHvyNN7MxQZqQdWUekPiNpzio2QFwji0UiuczCg@mail.gmail.com> <CAGudoHE2XgG0-zNyfBTRHPqTrXsVy5GuTu=USHLHmp1qqXgHSQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Apr 8, 2023 at 5:24=E2=80=AFAM Mateusz Guzik <mjguzik@gmail.com> wr=
ote:
>
> On 4/8/23, Kyle Evans <kevans@freebsd.org> wrote:
> > On Fri, Apr 7, 2023 at 4:54=E2=80=AFPM 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_ar=
m.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/5e2e3615d91f9c0c688987=
915ff5c8de23c22bde/arm64/aarch64/kernel.txz
> >> >
> >> > (No artifact build was exactly at either of your commits.)
> >> >
> >> > =3D=3D=3D
> >> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACNAnaG3m7%2BBmJFYdBHnQLhtnwzTX1f4da2ro%2Bugz6%2BZN6y=xg>