On Sat, Apr 8, 2023 at 5:24 AM Mateusz Guzik <mjgu...@gmail.com> wrote: > > On 4/8/23, Kyle Evans <kev...@freebsd.org> wrote: > > On Fri, Apr 7, 2023 at 4:54 PM Mateusz Guzik <mjgu...@gmail.com> wrote: > >> > >> On 4/7/23, Mark Millard <mark...@yahoo.com> wrote: > >> > On Apr 7, 2023, at 14:26, Mateusz Guzik <mjgu...@gmail.com> wrote: > >> > > >> >> On 4/7/23, Mateusz Guzik <mjgu...@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