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: 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: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 [separate aarch64 panic for zpool import]
On Apr 7, 2023, at 16:29, 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.
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
Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 [separate aarch64 panic for zpool import]
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.
Thanks,
Kyle Evans
Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 [separate aarch64 panic for zpool import]
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.
--
Mateusz Guzik
Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 [separate aarch64 panic for zpool import]
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
Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 [separate aarch64 panic for zpool import]
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)
> On 4/7/23, Mark Millard wrote:
>> Turns out that as of this commit aarch64 (Cortex-A72 and Cortex-A57
>> examples reported) gets the following even when no zfs media is
>> present (UFS boot):
>>
>> # zpool import
>> x0: f0fa9168 (ucom_cons_softc + efbf1bb8)
>> x1: ff90 ($d.1 + afa318)
>> x2: ff900400 ($d.1 + afa718)
>> x3: fec1b0a4 (sha_incremental + 0)
>> x4:0
>> x5: 10
>> x6: 8e16db93
>> x7:0
>> x8: feb06168 (tf_sha256_neon + 0)
>> x9: fea931fb ($d.1 + b)
>> x10: feb045f4 (SHA2Update + f4)
>> x11: 29
>> x12:1
>> x13:0
>> x14:0
>> x15:2
>> x16: feaf7500 ($d.0 + 0)
>> x17: 00476cf0 (nanouptime + 0)
>> x18: f0fa9000 (ucom_cons_softc + efbf1a50)
>> x19: f0fa9168 (ucom_cons_softc + efbf1bb8)
>> x20: 400
>> x21: ff90 ($d.1 + afa318)
>> x22: f0fa9198 (ucom_cons_softc + efbf1be8)
>> x23:0
>> x24:0
>> x25:0
>> x26: fed2df70 (sha256_neon_impl + 0)
>> x27: 203
>> x28: 31
>> x29: f0fa9040 (ucom_cons_softc + efbf1a90)
>> sp: f0fa9000
>> lr: feb04668 (SHA2Update + 168)
>> elr: feaf8684 (zfs_sha256_block_neon + 14)
>> spsr: 2045
>> esr: 1fe0
>> panic: VFP exception in the kernel
>> cpuid = 3
>> time = 1680786034
>> KDB: stack backtrace:
>> db_trace_self() at db_trace_self
>> db_trace_self_wrapper() at db_trace_self_wrapper+0x30
>> vpanic() at vpanic+0x13c
>> panic() at panic+0x44
>> do_el1h_sync() at do_el1h_sync+0x210
>> handle_el1h_sync() at handle_el1h_sync+0x10
>> --- exception, esr 0xf0fa9198
>> (null)() at 0x400
>> KDB: enter: panic
>> [ thread pid 1446 tid 100101 ]
>> Stopped at kdb_enter+0x44: undefined f905c27f
>> db>
>>
>> The above was produced via using an artifact build's
>> kernel based on that exact commit:
>>
>> https://artifact.ci.freebsd.org/snapshot/main/2a58b312b62f908ec92311d1bd8536dbaeb8e55b/arm64/aarch64/kernel.txz
>>
>> By contrast, the prior commit had an artifact build
>> as well, but it's kernel does not get the panic for
>> zpool import :
>>
>> https://artifact.ci.freebsd.org/snapshot/main/b98fbf3781df16f7797b2bbeabf205dc7d4985ae/arm64/aarch64/kernel.txz
>>
>> See also:
>>
>> https://lists.freebsd.org/archives/freebsd-current/2023-April/003417.html
>>
>> ===
>> Mark Millard
>> marklmi at yahoo.com
>>
>>
>
>
> --
> Mateusz Guzik
>
--
Mateusz Guzik
Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 [separate aarch64 panic for zpool import]
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) On 4/7/23, Mark Millard wrote: > Turns out that as of this commit aarch64 (Cortex-A72 and Cortex-A57 > examples reported) gets the following even when no zfs media is > present (UFS boot): > > # zpool import > x0: f0fa9168 (ucom_cons_softc + efbf1bb8) > x1: ff90 ($d.1 + afa318) > x2: ff900400 ($d.1 + afa718) > x3: fec1b0a4 (sha_incremental + 0) > x4:0 > x5: 10 > x6: 8e16db93 > x7:0 > x8: feb06168 (tf_sha256_neon + 0) > x9: fea931fb ($d.1 + b) > x10: feb045f4 (SHA2Update + f4) > x11: 29 > x12:1 > x13:0 > x14:0 > x15:2 > x16: feaf7500 ($d.0 + 0) > x17: 00476cf0 (nanouptime + 0) > x18: f0fa9000 (ucom_cons_softc + efbf1a50) > x19: f0fa9168 (ucom_cons_softc + efbf1bb8) > x20: 400 > x21: ff90 ($d.1 + afa318) > x22: f0fa9198 (ucom_cons_softc + efbf1be8) > x23:0 > x24:0 > x25:0 > x26: fed2df70 (sha256_neon_impl + 0) > x27: 203 > x28: 31 > x29: f0fa9040 (ucom_cons_softc + efbf1a90) > sp: f0fa9000 > lr: feb04668 (SHA2Update + 168) > elr: feaf8684 (zfs_sha256_block_neon + 14) > spsr: 2045 > esr: 1fe0 > panic: VFP exception in the kernel > cpuid = 3 > time = 1680786034 > KDB: stack backtrace: > db_trace_self() at db_trace_self > db_trace_self_wrapper() at db_trace_self_wrapper+0x30 > vpanic() at vpanic+0x13c > panic() at panic+0x44 > do_el1h_sync() at do_el1h_sync+0x210 > handle_el1h_sync() at handle_el1h_sync+0x10 > --- exception, esr 0xf0fa9198 > (null)() at 0x400 > KDB: enter: panic > [ thread pid 1446 tid 100101 ] > Stopped at kdb_enter+0x44: undefined f905c27f > db> > > The above was produced via using an artifact build's > kernel based on that exact commit: > > https://artifact.ci.freebsd.org/snapshot/main/2a58b312b62f908ec92311d1bd8536dbaeb8e55b/arm64/aarch64/kernel.txz > > By contrast, the prior commit had an artifact build > as well, but it's kernel does not get the panic for > zpool import : > > https://artifact.ci.freebsd.org/snapshot/main/b98fbf3781df16f7797b2bbeabf205dc7d4985ae/arm64/aarch64/kernel.txz > > See also: > > https://lists.freebsd.org/archives/freebsd-current/2023-April/003417.html > > === > Mark Millard > marklmi at yahoo.com > > -- Mateusz Guzik
RE: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 [separate aarch64 panic for zpool import]
Turns out that as of this commit aarch64 (Cortex-A72 and Cortex-A57 examples reported) gets the following even when no zfs media is present (UFS boot): # zpool import x0: f0fa9168 (ucom_cons_softc + efbf1bb8) x1: ff90 ($d.1 + afa318) x2: ff900400 ($d.1 + afa718) x3: fec1b0a4 (sha_incremental + 0) x4:0 x5: 10 x6: 8e16db93 x7:0 x8: feb06168 (tf_sha256_neon + 0) x9: fea931fb ($d.1 + b) x10: feb045f4 (SHA2Update + f4) x11: 29 x12:1 x13:0 x14:0 x15:2 x16: feaf7500 ($d.0 + 0) x17: 00476cf0 (nanouptime + 0) x18: f0fa9000 (ucom_cons_softc + efbf1a50) x19: f0fa9168 (ucom_cons_softc + efbf1bb8) x20: 400 x21: ff90 ($d.1 + afa318) x22: f0fa9198 (ucom_cons_softc + efbf1be8) x23:0 x24:0 x25:0 x26: fed2df70 (sha256_neon_impl + 0) x27: 203 x28: 31 x29: f0fa9040 (ucom_cons_softc + efbf1a90) sp: f0fa9000 lr: feb04668 (SHA2Update + 168) elr: feaf8684 (zfs_sha256_block_neon + 14) spsr: 2045 esr: 1fe0 panic: VFP exception in the kernel cpuid = 3 time = 1680786034 KDB: stack backtrace: db_trace_self() at db_trace_self db_trace_self_wrapper() at db_trace_self_wrapper+0x30 vpanic() at vpanic+0x13c panic() at panic+0x44 do_el1h_sync() at do_el1h_sync+0x210 handle_el1h_sync() at handle_el1h_sync+0x10 --- exception, esr 0xf0fa9198 (null)() at 0x400 KDB: enter: panic [ thread pid 1446 tid 100101 ] Stopped at kdb_enter+0x44: undefined f905c27f db> The above was produced via using an artifact build's kernel based on that exact commit: https://artifact.ci.freebsd.org/snapshot/main/2a58b312b62f908ec92311d1bd8536dbaeb8e55b/arm64/aarch64/kernel.txz By contrast, the prior commit had an artifact build as well, but it's kernel does not get the panic for zpool import : https://artifact.ci.freebsd.org/snapshot/main/b98fbf3781df16f7797b2bbeabf205dc7d4985ae/arm64/aarch64/kernel.txz See also: https://lists.freebsd.org/archives/freebsd-current/2023-April/003417.html === Mark Millard marklmi at yahoo.com
