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

2023-04-07 Thread Mark Millard 
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]

2023-04-07 Thread Kyle Evans 
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: textdumps are too slow

2023-04-07 Thread alan somers 
On Fri, Apr 7, 2023, 4:07 PM Rodney W. Grimes 
wrote:

> > On Fri, Apr 7, 2023 at 12:08?PM Warner Losh  wrote:
> > >
> > >
> > >
> > > On Fri, Apr 7, 2023 at 6:20?AM Poul-Henning Kamp 
> wrote:
> > >>
> > >> 
> > >> Alan Somers writes:
> > >> > On Fri, Apr 7, 2023 at 2:22=E2=80=AFAM Poul-Henning Kamp <
> p...@phk.freebsd.dk> wrote:
> > >>
> > >> > > I would expect them to be limited by the serial console speed
> before
> > >> > > the video system speed ?
> > >> >
> > >> > That was my first guess, too.  But my serial console is 115200 baud,
> > >> > which is faster than the low performance server grade video card.
> > >>
> > >> Ok, that must truly be sucky hardware...
> > >
> > >
> > > That's 10x slower than 1990s era VGA cards then... 115200 is 11k
> characters a second,
> > > and FreeBSD on 1990s era VGA cards was in excess of 1MB/s, faster if
> not a pure ISA
> > > card... Video hardware that's slower than *THAT* likely indicates a
> big big problem in
> > > our video stack.
> > >
> > > Warner
> >
> > While I'm logged into the video terminal in a normal login session, I
> > measure about 28M characters/second.  So maybe the slow speed is due
> > to something inefficient in ddb(4).
>
> Do you mean to a physically connected vga display and usb/ps2 connected
> keyboard, or do you mean a serially connected video terminal, or something
> else like a console created by a BMC?
>
> One other thing that could be at issue is a console redirection via
> serial port, that can make "VGA device" performance appear abismal.
>
>
> --
> Rod Grimes
> rgri...@freebsd.org


It's a BMC video console.  I'm also using a BMC serial port, but during
panic I measured the serial port as faster than the video port.


>

Re: textdumps are too slow

2023-04-07 Thread Rodney W. Grimes 
> On Fri, Apr 7, 2023 at 12:08?PM Warner Losh  wrote:
> >
> >
> >
> > On Fri, Apr 7, 2023 at 6:20?AM Poul-Henning Kamp  
> > wrote:
> >>
> >> 
> >> Alan Somers writes:
> >> > On Fri, Apr 7, 2023 at 2:22=E2=80=AFAM Poul-Henning Kamp 
> >> >  wrote:
> >>
> >> > > I would expect them to be limited by the serial console speed before
> >> > > the video system speed ?
> >> >
> >> > That was my first guess, too.  But my serial console is 115200 baud,
> >> > which is faster than the low performance server grade video card.
> >>
> >> Ok, that must truly be sucky hardware...
> >
> >
> > That's 10x slower than 1990s era VGA cards then... 115200 is 11k characters 
> > a second,
> > and FreeBSD on 1990s era VGA cards was in excess of 1MB/s, faster if not a 
> > pure ISA
> > card... Video hardware that's slower than *THAT* likely indicates a big big 
> > problem in
> > our video stack.
> >
> > Warner
> 
> While I'm logged into the video terminal in a normal login session, I
> measure about 28M characters/second.  So maybe the slow speed is due
> to something inefficient in ddb(4).

Do you mean to a physically connected vga display and usb/ps2 connected
keyboard, or do you mean a serially connected video terminal, or something
else like a console created by a BMC?

One other thing that could be at issue is a console redirection via
serial port, that can make "VGA device" performance appear abismal.


-- 
Rod Grimes rgri...@freebsd.org

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

2023-04-07 Thread Mateusz Guzik 
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]

2023-04-07 Thread Mark Millard 
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]

2023-04-07 Thread Mateusz Guzik 
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]

2023-04-07 Thread Mateusz Guzik 
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]

2023-04-07 Thread Mark Millard 
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

Re: Another VFP-in-kernel problem on armv8

2023-04-07 Thread Mark Millard 
On Apr 7, 2023, at 06:06, John F Carr  wrote:

> I upgraded from mid-February CURRENT (5dc00f00b747) to yesterday 
> (f02879f19925) and my system panics during boot with
> 
>  panic: VFP exception in the kernel
> 
> Most likely this panic is while trying to import the root ZFS pool.  The 
> crash is at the first vector instruction in zfs_sha256_block_neon (in zfs.ko):
> 
>   f9284: 4cdf7020  ld1 { v0.16b }, [x1], #16
> 
> This instruction is implemented on my CPU (Cortex A-57), confirmed by running 
> it in user mode.
> 
> I don't see any obviously related changes in ZFS since the last working 
> kernel.  What's going on recently with VFP in the kernel?


I've a simpler reproducer context based on just official
materials:

Downloaded and dd'd an 2023-Apr-06 snapshot image and
powered up a small aarch64 board with it:

. . .
FreeBSD 14.0-CURRENT #0 main-n262010-f21faa67ab6b: Thu Apr  6 11:49:31 UTC 2023
r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC 
arm64
FreeBSD clang version 15.0.7 (https://github.com/llvm/llvm-project.git 
llvmorg-15.0.7-0-g8dfdcc7b7bf6)
 . . .


So: A just-UFS boot context. Then login and try "zpool import"
without having any zfs media present, just the UFS boot media:

Login: root
Password:
Apr  6 13:00:28 generic login[1443]: ROOT LOGIN (root) ON ttyu0
FreeBSD 14.0-CURRENT #0 main-n262010-f21faa67ab6b: Thu Apr  6 11:49:31 UTC 2023 
r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC

Welcome to FreeBSD!

Release Notes, Errata: https://www.FreeBSD.org/releases/
Security Advisories:   https://www.FreeBSD.org/security/
FreeBSD Handbook:  https://www.FreeBSD.org/handbook/
FreeBSD FAQ:   https://www.FreeBSD.org/faq/
Questions List:https://www.FreeBSD.org/lists/questions/
FreeBSD Forums:https://forums.FreeBSD.org/

Documents installed with the system are in the /usr/local/share/doc/freebsd/
directory, or can be installed later with:  pkg install en-freebsd-doc
For other languages, replace "en" with a language code like de or fr.

Show the version of FreeBSD installed:  freebsd-version ; uname -a
Please include that output and any error messages when posting questions.
Introduction to manual pages:  man man
FreeBSD directory layout:  man hier

To change this login announcement, see motd(5).
root@generic:~ # 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> 

===
Mark Millard
marklmi at yahoo.com

Re: textdumps are too slow

2023-04-07 Thread Alan Somers 
On Fri, Apr 7, 2023 at 12:08 PM Warner Losh  wrote:
>
>
>
> On Fri, Apr 7, 2023 at 6:20 AM Poul-Henning Kamp  wrote:
>>
>> 
>> Alan Somers writes:
>> > On Fri, Apr 7, 2023 at 2:22=E2=80=AFAM Poul-Henning Kamp 
>> >  wrote:
>>
>> > > I would expect them to be limited by the serial console speed before
>> > > the video system speed ?
>> >
>> > That was my first guess, too.  But my serial console is 115200 baud,
>> > which is faster than the low performance server grade video card.
>>
>> Ok, that must truly be sucky hardware...
>
>
> That's 10x slower than 1990s era VGA cards then... 115200 is 11k characters a 
> second,
> and FreeBSD on 1990s era VGA cards was in excess of 1MB/s, faster if not a 
> pure ISA
> card... Video hardware that's slower than *THAT* likely indicates a big big 
> problem in
> our video stack.
>
> Warner

While I'm logged into the video terminal in a normal login session, I
measure about 28M characters/second.  So maybe the slow speed is due
to something inefficient in ddb(4).

Re: textdumps are too slow

2023-04-07 Thread Warner Losh 
On Fri, Apr 7, 2023 at 6:20 AM Poul-Henning Kamp  wrote:

> 
> Alan Somers writes:
> > On Fri, Apr 7, 2023 at 2:22=E2=80=AFAM Poul-Henning Kamp <
> p...@phk.freebsd.dk> wrote:
>
> > > I would expect them to be limited by the serial console speed before
> > > the video system speed ?
> >
> > That was my first guess, too.  But my serial console is 115200 baud,
> > which is faster than the low performance server grade video card.
>
> Ok, that must truly be sucky hardware...
>

That's 10x slower than 1990s era VGA cards then... 115200 is 11k characters
a second,
and FreeBSD on 1990s era VGA cards was in excess of 1MB/s, faster if not a
pure ISA
card... Video hardware that's slower than *THAT* likely indicates a big big
problem in
our video stack.

Warner

Re: n262026-37d97b10ff0e installworld failure

2023-04-07 Thread Mateusz Guzik 
On 4/7/23, Graham Perrin  wrote:
> Log: 
>
> Any ideas?
>
> 37d97b10ff0e was around twelve hours ago,
> 
>

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.

-- 
Mateusz Guzik

Re: n262026-37d97b10ff0e installworld failure

2023-04-07 Thread Mateusz Guzik 
yes, this is the recent zfs breakage. temporarily you can work around
by installing the patched cp by hand. it already in the tree.
alternatively get yourself https://github.com/openzfs/zfs/pull/14723

On 4/7/23, Graham Perrin  wrote:
> Log: 
>
> Any ideas?
>
> 37d97b10ff0e was around twelve hours ago,
> 
>
>


-- 
Mateusz Guzik

n262026-37d97b10ff0e installworld failure

2023-04-07 Thread Graham Perrin 

Log: 

Any ideas?

37d97b10ff0e was around twelve hours ago, 





OpenPGP_signature
Description: OpenPGP digital signature

documentation nit / TERMINFO in ncurses man pages

2023-04-07 Thread Dan Mack 



I recently logged into one of my FreeBSD systems from an alacritty 
terminal.  FreeBSD didn't have a termcap entry for alacritty so I 
generated one with tic and all was well.   However, I noticed the 
following issues with the TERM* related tools (I guess this is all from 
contrib/ncurses in /usr/src).


Specifically, the issue is for example - the tic(1M) man page says in the 
FILES section:


 /usr/share/misc/terminfo/?/*
Compiled terminal description database.

However, when you run tic(1M), the compiled terminal files are actually 
placed in /usr/share/terminfo/?/* .   I thought I could create a simple 
one line fix by re-defining the definition for *d in the manpage, however, 
it looks like there there might be a need to create two separate directory 
variables instead.


On FreeBSD-Current HEAD (2d3614fb132b1cb8efd1e0accdd0c98ce6893efa) I am 
seeing two directories in use:


  /usr/share/terminfo/?- compiled entries created by tic(1M)
and
  /usr/share/misc  - contains the files termcap and termcap.db

Looks like this directory reference is set to *d here in the tic manpage:

18259542b2f8f contrib/ncurses/man/tic.1m 2000-10-11 07:31:01 +  37) 
.ds d @TERMINFO@


Since this is also set in alot of other places, we probably need someone 
to make some sort of decision :-)


Dan

Re: IFF_KNOWSEPOCH -> IFF_NEEDSEPOCH

2023-04-07 Thread Drew Gallatin 
This sounds like a good plan to me

On Thu, Apr 6, 2023, at 2:34 PM, Gleb Smirnoff wrote:
>   Hi,
> 
> recently we had several drivers marked with IFF_KNOWSEPOCH
> which reminded me that this flag was supposed to be temporary.
> 
> Here is the change that introduced it e87c4940156. It was
> caused by several drivers sending packets from non-interrupt
> context and thus triggering NET_EPOCH_ASSERT(). It was about
> 10 - 20 drivers having this problem initially and reduced down
> to a few after 4426b2e64bd. We had a pretty heated dicussion
> back then and I apologize for that.
> 
> May I suggest before entering FreeBSD 14.0-RELEASE cycle we
> will get back to what was there before e87c4940156?
> 
> To avoid the driver fallout that we used to have back in
> early 2020, here is the plan. In ether_input() where we
> now conditionally on the IFF_KNOWSEPOCH flag enter/exit the
> epoch with INVARIANTS we will also conditionally enter/exit
> in case we are supposed to be in the epoch wrt the flag, but
> we are not. We will also print a warning once, like "interface
> foo0 called if_input without epoch". This handling will be
> converted to normal assertion after a couple months.
> 
> If everybody is fine with this suggestion I will post
> a review. Otherwise please express your concerns.
> 
> -- 
> Gleb Smirnoff
>

Re: textdumps are too slow

2023-04-07 Thread Poul-Henning Kamp 

Alan Somers writes:
> On Fri, Apr 7, 2023 at 2:22=E2=80=AFAM Poul-Henning Kamp 
>  wrote:

> > I would expect them to be limited by the serial console speed before
> > the video system speed ?
>
> That was my first guess, too.  But my serial console is 115200 baud,
> which is faster than the low performance server grade video card.

Ok, that must truly be sucky hardware...

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

Re: textdumps are too slow

2023-04-07 Thread Alan Somers 
On Fri, Apr 7, 2023 at 2:22 AM Poul-Henning Kamp  wrote:
>
> 
> Alan Somers writes:
>
> > However, these servers also have about 10,000 threads
> > apiece, so textdumps are also slow.  They take tens of minutes.
> > I have dual console setup: both serial and video.  It seems to me that
> > the speed of the textdump might be limited by the video system.
>
> I would expect them to be limited by the serial console speed before
> the video system speed ?

That was my first guess, too.  But my serial console is 115200 baud,
which is faster than the low performance server grade video card.

Re: textdumps are too slow

2023-04-07 Thread Poul-Henning Kamp 

Alan Somers writes:

> However, these servers also have about 10,000 threads
> apiece, so textdumps are also slow.  They take tens of minutes.
> I have dual console setup: both serial and video.  It seems to me that
> the speed of the textdump might be limited by the video system.

I would expect them to be limited by the serial console speed before
the video system speed ?

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

Re: Is it valid to combine CTLFLAG_TUN with CTLFLAG_VNET ?

2023-04-07 Thread Zhenlei Huang 



> On Apr 6, 2023, at 3:56 AM, Hans Petter Selasky  wrote:
> 
> On 4/5/23 21:44, Hans Petter Selasky wrote:
>> On 4/5/23 20:23, Gleb Smirnoff wrote:
>>> What if we remove the CTLFLAG_VNET check from the code you posted above?
>>> I don't see anything going wrong, rather going right 
>>> 
>>> CTLFLAG_VNET will not mask away CTLFLAG_TUN.
>> Hi Gleb,
>> It's possible to bypass that check, but some work needs to be done first. 
>> Then all jails created, will also start from those sysctl tunable values.
>> The problem is, where does the VNET base pointer come from?
>> Especially those static sysctl's. You would need to make some design there I 
>> guess and look at the SYSINIT() order. When are SYSINIT's filled with 
>> tunable data's. And when is the default VNET created.
>> Because the data pointer passed to the register sysctl function is simply an 
>> offset pointer into a malloc'ed structure.
>> --HPS
> 
> Hi Zhenlei,
> 
> Feel free to work on this, and add me as a reviewer and complete phase two of:
> 
>> commit 3da1cf1e88f8448bb10c5f778ab56ff65c7a6938
>> Author: Hans Petter Selasky 
>> Date:   Fri Jun 27 16:33:43 2014 +
>>Extend the meaning of the CTLFLAG_TUN flag to automatically check if
>>there is an environment variable which shall initialize the SYSCTL
>>during early boot. This works for all SYSCTL types both statically and
>>dynamically created ones, except for the SYSCTL NODE type and SYSCTLs
>>which belong to VNETs. A new flag, CTLFLAG_NOFETCH, has been added to
> 

I'd like to do some refactoring firstly, so that I can focus on CTLFLAG_VNET ;)

> --HPS

Best regards,
Zhenlei

Re: IFF_KNOWSEPOCH -> IFF_NEEDSEPOCH

2023-04-07 Thread Zhenlei Huang 


> On Apr 7, 2023, at 2:34 AM, Gleb Smirnoff  wrote:
> 
>  Hi,
> 
> recently we had several drivers marked with IFF_KNOWSEPOCH
> which reminded me that this flag was supposed to be temporary.
> 
> Here is the change that introduced it e87c4940156. It was
> caused by several drivers sending packets from non-interrupt
> context and thus triggering NET_EPOCH_ASSERT(). It was about
> 10 - 20 drivers having this problem initially and reduced down
> to a few after 4426b2e64bd. We had a pretty heated dicussion
> back then and I apologize for that.
> 
> May I suggest before entering FreeBSD 14.0-RELEASE cycle we
> will get back to what was there before e87c4940156?

It sounds good if only a few drivers need IFF_NEEDSEPOCH.

> 
> To avoid the driver fallout that we used to have back in
> early 2020, here is the plan. In ether_input() where we
> now conditionally on the IFF_KNOWSEPOCH flag enter/exit the
> epoch with INVARIANTS we will also conditionally enter/exit
> in case we are supposed to be in the epoch wrt the flag, but
> we are not. We will also print a warning once, like "interface
> foo0 called if_input without epoch". This handling will be
> converted to normal assertion after a couple months.

Should also apply to infiniband_input().

BTW, is `in_epoch()` too heavy to replace flag IFF_NEEDSEPOCH
or IFF_KNOWSEPOCH ?

> 
> If everybody is fine with this suggestion I will post
> a review. Otherwise please express your concerns.

Good to make it moving forward ;)

Best regards,
Zhenlei

> 
> -- 
> Gleb Smirnoff