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 wrote:
>
> On 4/8/23, Kyle Evans wrote:
> > On Fri, Apr 7, 2023 at 4:54 PM Mateusz Guzik wrote:
> >>
> >> On 4/7/23, Mark Millard wrote:
> >> > On Apr 7, 2023, at 14:26, Mateusz Guzik wrote:
> >> >
> >> >> On 4/7/23, Mateusz Guzik 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 @@
> >> >>> #defineID_AA64PFR0_EL1 sys_reg(3, 0, 0, 1, 0)
> >> >>> #defineID_AA64ISAR0_EL1sys_reg(3, 0, 0, 6, 0)
> >> >>>
> >> >>> -#definekfpu_allowed() 1
> >> >>> +#definekfpu_allowed() 0
> >> >>> #definekfpu_begin()kernel_neon_begin()
> >> >>> #definekfpu_end() kernel_neon_end()
> >> >>> #definekfpu_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
> >> >> #include
> >> >>
> >> >> -#definekfpu_allowed() 1
> >> >> +#definekfpu_allowed() 0
> >> >> #definekfpu_initialize(tsk)do {} while (0)
> >> >> #definekfpu_begin()do {} while (0)
> >> >> #definekfpu_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
Re: /usr/src/sys/netlink/route/iface.c:738:1: warning: unused function
> On 8 Apr 2023, at 20:21, Gary Jennejohn wrote: > > This isn't a fatal error, but it would be easy to fix: > > /usr/src/sys/netlink/route/iface.c:738:1: warning: unused function > 'inet6_get_plen' [-Wunused-function] > inet6_get_plen(const struct in6_addr *addr) > ^ > 1 warning generated. > > This function is called in get_sa_plen(const struct sockaddr *sa) and the > call is done inside #ifdef INET6...#endif, whereas the implementation is > NOT inside #ifdef INET6...#endif, as it should be. Thanks for the report, should be fixed by 39c0036d881b. > > I do not have INET6 in my kernel config file. > > -- > Gary Jennejohn >
/usr/src/sys/netlink/route/iface.c:738:1: warning: unused function
This isn't a fatal error, but it would be easy to fix: /usr/src/sys/netlink/route/iface.c:738:1: warning: unused function 'inet6_get_plen' [-Wunused-function] inet6_get_plen(const struct in6_addr *addr) ^ 1 warning generated. This function is called in get_sa_plen(const struct sockaddr *sa) and the call is done inside #ifdef INET6...#endif, whereas the implementation is NOT inside #ifdef INET6...#endif, as it should be. I do not have INET6 in my kernel config file. -- Gary Jennejohn
Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 [separate aarch64 panic for zpool import]
On 4/8/23, Kyle Evans wrote:
> On Fri, Apr 7, 2023 at 4:54 PM Mateusz Guzik wrote:
>>
>> On 4/7/23, Mark Millard wrote:
>> > On Apr 7, 2023, at 14:26, Mateusz Guzik wrote:
>> >
>> >> On 4/7/23, Mateusz Guzik 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 @@
>> >>> #defineID_AA64PFR0_EL1 sys_reg(3, 0, 0, 1, 0)
>> >>> #defineID_AA64ISAR0_EL1sys_reg(3, 0, 0, 6, 0)
>> >>>
>> >>> -#definekfpu_allowed() 1
>> >>> +#definekfpu_allowed() 0
>> >>> #definekfpu_begin()kernel_neon_begin()
>> >>> #definekfpu_end() kernel_neon_end()
>> >>> #definekfpu_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
>> >> #include
>> >>
>> >> -#definekfpu_allowed() 1
>> >> +#definekfpu_allowed() 0
>> >> #definekfpu_initialize(tsk)do {} while (0)
>> >> #definekfpu_begin()do {} while (0)
>> >> #definekfpu_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.
I had seen the upstream review, apparently there is opposition to the
patch, it is clearly not going to land within hours.
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.
If anything the question is how come a clearly *not* implemented simd
support got kfpu_allowed set to 1.
--
Mateusz Guzik
Re: n262026-37d97b10ff0e installworld failure
On 07/04/2023 16:51, Mateusz Guzik wrote: On 4/7/23, Graham Perrin wrote: … I pushed the fix. git pull, make sure you are at 20be1b4fc4b72f10d5f9411e5bbde0f46a98be5b or later. build and install the new kernel, only then proceed with installworld and you should be fine. Fix confirmed, thanks for the rapidity. % uname -aKU FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #38 main-n262032-5e2e3615d91f: Fri Apr 7 18:54:28 BST 2023 grahamperrin@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC- NODEBUG amd64 1400085 1400085 % OpenPGP_signature Description: OpenPGP digital signature
