Re: releng/13 release/13.0.0 : odd/incorrect diff result over nfs (in a zfs file systems context)

[Mark Millard via freebsd-stable]

On 2021-May-23, at 01:27, Mark Millard  wrote:

> On 2021-May-23, at 00:44, Mark Millard  wrote:
> 
>> On 2021-May-21, at 17:56, Rick Macklem  wrote:
>> 
>>> Mark Millard wrote:
>>> [stuff snipped]
 Well, why is it that ls -R, find, and diff -r all get file
 name problems via genet0 but diff -r gets no problems
 comparing the content of files that it does match up (the
 vast majority)? Any clue how could the problems possibly
 be unique to the handling of file names/paths? Does it
 suggest anything else to look into for getting some more
 potentially useful evidence?
>>> Well, all I can do is describe the most common TSO related
>>> failure:
>>> - When a read RPC reply (including NFS/RPC/TCP/IP headers)
>>> is slightly less than 64K bytes (many TSO implementations are
>>> limited to 64K or 32 discontiguous segments, think 32 2K
>>> mbuf clusters), the driver decides it is ok, but when the MAC
>>> header is added it exceeds what the hardware can handle correctly...
>>> --> This will happen when reading a regular file that is slightly less
>>> than a multiple of 64K in size.
>>> or
>>> --> This will happen when reading just about any large directory,
>>>since the directory reply for a 64K request is converted to Sun XDR
>>>format and clipped at the last full directory entry that will fit within 
>>> 64K.
>>> For ports, where most files are small, I think you can tell which is more
>>> likely to happen.
>>> --> If TSO is disabled, I have no idea how this might matter, but??
>>> 
 I'll note that netstat -I ue0 -d and netstat -I genet0 -d
 do not report changes in Ierrs or Idrop in a before vs.
 after failures comparison. (There may be better figures
 to look at for all I know.)
 
 I tried "ifconfig genet0 -rxcsum -rxcsum -rxcsum6 -txcsum6"
 and got no obvious change in behavior.
>>> All we know is that the data is getting corrupted somehow.
>>> 
>>> NFS traffic looks very different than typical TCP traffic. It is
>>> mostly small messages travelling in both directions concurrently,
>>> with some large messages thrown in the mix.
>>> All I'm saying is that, testing a net interface with something like
>>> bulk data transfer in one direction doesn't verify it works for NFS
>>> traffic.
>>> 
>>> Also, the large RPC messages are a chain of about 33 mbufs of
>>> various lengths, including a mix of partial clusters and regular
>>> data mbufs, whereas a bulk send on a socket will typically
>>> result in an mbuf chain of a lot of full 2K clusters.
>>> --> As such, NFS can be good at tickling subtle bugs it the
>>>net driver related to mbuf handling.
>>> 
>>> rick
>>> 
> W.r.t. reverting r367492...the patch to replace r367492 was just
> committed to "main" by rscheff@ with a two week MFC, so it
> should be in stable/13 soon. Not sure if an errata can be done
> for it for releng13.0?
 
 That update is reported to be causing "rack" related panics:
 
 https://lists.freebsd.org/pipermail/dev-commits-src-main/2021-May/004440.html
 
 reports (via links):
 
 panic: _mtx_lock_sleep: recursed on non-recursive mutex so_snd @ 
 /syzkaller/managers/i386/kernel/sys/modules/tcp/rack/../../../netinet/tcp_stacks/rack.c:10632
 
 Still, I have a non-debug update to main building and will
 likely do a debug build as well. llvm is rebuilding, so
 the builds will take a notable time.
>> 
>> I got the following built and installed on the two
>> machines:
>> 
>> # uname -apKU
>> FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #1 
>> main-n246854-03b0505b8fe8-dirty: Sat May 22 16:25:04 PDT 2021 
>> root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-DBG-CA72
>>   arm64 aarch64 1400013 1400013
>> 
>> # uname -apKU
>> FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #1 
>> main-n246854-03b0505b8fe8-dirty: Sat May 22 16:25:04 PDT 2021 
>> root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-DBG-CA72
>>   arm64 aarch64 1400013 1400013
>> 
>> Note that both are booted with debug builds of main.
>> 
>> Using the context with the alternate EtherNet device that has not
>> had an associated diff -r, find, pr ls -R failure yet
>> yet got a panic that looks likely to be unrelated:
>> 
>> # mount -onoatime 192.168.1.187:/usr/ports/ /mnt/
>> # diff -r /usr/ports/ /mnt/ | more
>> nvme0: cpl does not map to outstanding cmd
>> cdw0: sqhd:0020 sqid:0003 cid:007e p:1 sc:00 sct:0 m:0 dnr:0
>> panic: received completion for unknown cmd
>> cpuid = 3
>> time = 1621743752
>> KDB: stack backtrace:
>> db_trace_self() at db_trace_self
>> db_trace_self_wrapper() at db_trace_self_wrapper+0x30
>> vpanic() at vpanic+0x188
>> panic() at panic+0x44
>> nvme_qpair_process_completions() at nvme_qpair_process_completions+0x1fc
>> nvme_timeout() at nvme_timeout+0x3c
>> softclock_call_cc() at softclock_call_cc+0x124
>> softclock() 

Re: releng/13 release/13.0.0 : odd/incorrect diff result over nfs (in a zfs file systems context)

[Mark Millard via freebsd-stable]

On 2021-May-23, at 00:44, Mark Millard  wrote:

> On 2021-May-21, at 17:56, Rick Macklem  wrote:
> 
>> Mark Millard wrote:
>> [stuff snipped]
>>> Well, why is it that ls -R, find, and diff -r all get file
>>> name problems via genet0 but diff -r gets no problems
>>> comparing the content of files that it does match up (the
>>> vast majority)? Any clue how could the problems possibly
>>> be unique to the handling of file names/paths? Does it
>>> suggest anything else to look into for getting some more
>>> potentially useful evidence?
>> Well, all I can do is describe the most common TSO related
>> failure:
>> - When a read RPC reply (including NFS/RPC/TCP/IP headers)
>> is slightly less than 64K bytes (many TSO implementations are
>> limited to 64K or 32 discontiguous segments, think 32 2K
>> mbuf clusters), the driver decides it is ok, but when the MAC
>> header is added it exceeds what the hardware can handle correctly...
>> --> This will happen when reading a regular file that is slightly less
>>  than a multiple of 64K in size.
>> or
>> --> This will happen when reading just about any large directory,
>> since the directory reply for a 64K request is converted to Sun XDR
>> format and clipped at the last full directory entry that will fit within 
>> 64K.
>> For ports, where most files are small, I think you can tell which is more
>> likely to happen.
>> --> If TSO is disabled, I have no idea how this might matter, but??
>> 
>>> I'll note that netstat -I ue0 -d and netstat -I genet0 -d
>>> do not report changes in Ierrs or Idrop in a before vs.
>>> after failures comparison. (There may be better figures
>>> to look at for all I know.)
>>> 
>>> I tried "ifconfig genet0 -rxcsum -rxcsum -rxcsum6 -txcsum6"
>>> and got no obvious change in behavior.
>> All we know is that the data is getting corrupted somehow.
>> 
>> NFS traffic looks very different than typical TCP traffic. It is
>> mostly small messages travelling in both directions concurrently,
>> with some large messages thrown in the mix.
>> All I'm saying is that, testing a net interface with something like
>> bulk data transfer in one direction doesn't verify it works for NFS
>> traffic.
>> 
>> Also, the large RPC messages are a chain of about 33 mbufs of
>> various lengths, including a mix of partial clusters and regular
>> data mbufs, whereas a bulk send on a socket will typically
>> result in an mbuf chain of a lot of full 2K clusters.
>> --> As such, NFS can be good at tickling subtle bugs it the
>> net driver related to mbuf handling.
>> 
>> rick
>> 
 W.r.t. reverting r367492...the patch to replace r367492 was just
 committed to "main" by rscheff@ with a two week MFC, so it
 should be in stable/13 soon. Not sure if an errata can be done
 for it for releng13.0?
>>> 
>>> That update is reported to be causing "rack" related panics:
>>> 
>>> https://lists.freebsd.org/pipermail/dev-commits-src-main/2021-May/004440.html
>>> 
>>> reports (via links):
>>> 
>>> panic: _mtx_lock_sleep: recursed on non-recursive mutex so_snd @ 
>>> /syzkaller/managers/i386/kernel/sys/modules/tcp/rack/../../../netinet/tcp_stacks/rack.c:10632
>>> 
>>> Still, I have a non-debug update to main building and will
>>> likely do a debug build as well. llvm is rebuilding, so
>>> the builds will take a notable time.
> 
> I got the following built and installed on the two
> machines:
> 
> # uname -apKU
> FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #1 
> main-n246854-03b0505b8fe8-dirty: Sat May 22 16:25:04 PDT 2021 
> root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-DBG-CA72
>   arm64 aarch64 1400013 1400013
> 
> # uname -apKU
> FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #1 
> main-n246854-03b0505b8fe8-dirty: Sat May 22 16:25:04 PDT 2021 
> root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-DBG-CA72
>   arm64 aarch64 1400013 1400013
> 
> Note that both are booted with debug builds of main.
> 
> Using the context with the alternate EtherNet device that has not
> had an associated diff -r, find, pr ls -R failure yet
> yet got a panic that looks likely to be unrelated:
> 
> # mount -onoatime 192.168.1.187:/usr/ports/ /mnt/
> # diff -r /usr/ports/ /mnt/ | more
> nvme0: cpl does not map to outstanding cmd
> cdw0: sqhd:0020 sqid:0003 cid:007e p:1 sc:00 sct:0 m:0 dnr:0
> panic: received completion for unknown cmd
> cpuid = 3
> time = 1621743752
> KDB: stack backtrace:
> db_trace_self() at db_trace_self
> db_trace_self_wrapper() at db_trace_self_wrapper+0x30
> vpanic() at vpanic+0x188
> panic() at panic+0x44
> nvme_qpair_process_completions() at nvme_qpair_process_completions+0x1fc
> nvme_timeout() at nvme_timeout+0x3c
> softclock_call_cc() at softclock_call_cc+0x124
> softclock() at softclock+0x60
> ithread_loop() at ithread_loop+0x2a8
> fork_exit() at fork_exit+0x74
> fork_trampoline() at fork_trampoline+0x14
> KDB: enter: panic
> [ 

Re: releng/13 release/13.0.0 : odd/incorrect diff result over nfs (in a zfs file systems context)

[Mark Millard via freebsd-stable]

On 2021-May-21, at 17:56, Rick Macklem  wrote:

> Mark Millard wrote:
> [stuff snipped]
>> Well, why is it that ls -R, find, and diff -r all get file
>> name problems via genet0 but diff -r gets no problems
>> comparing the content of files that it does match up (the
>> vast majority)? Any clue how could the problems possibly
>> be unique to the handling of file names/paths? Does it
>> suggest anything else to look into for getting some more
>> potentially useful evidence?
> Well, all I can do is describe the most common TSO related
> failure:
> - When a read RPC reply (including NFS/RPC/TCP/IP headers)
>  is slightly less than 64K bytes (many TSO implementations are
>  limited to 64K or 32 discontiguous segments, think 32 2K
>  mbuf clusters), the driver decides it is ok, but when the MAC
>  header is added it exceeds what the hardware can handle correctly...
> --> This will happen when reading a regular file that is slightly less
>   than a multiple of 64K in size.
> or
> --> This will happen when reading just about any large directory,
>  since the directory reply for a 64K request is converted to Sun XDR
>  format and clipped at the last full directory entry that will fit within 
> 64K.
> For ports, where most files are small, I think you can tell which is more
> likely to happen.
> --> If TSO is disabled, I have no idea how this might matter, but??
> 
>> I'll note that netstat -I ue0 -d and netstat -I genet0 -d
>> do not report changes in Ierrs or Idrop in a before vs.
>> after failures comparison. (There may be better figures
>> to look at for all I know.)
>> 
>> I tried "ifconfig genet0 -rxcsum -rxcsum -rxcsum6 -txcsum6"
>> and got no obvious change in behavior.
> All we know is that the data is getting corrupted somehow.
> 
> NFS traffic looks very different than typical TCP traffic. It is
> mostly small messages travelling in both directions concurrently,
> with some large messages thrown in the mix.
> All I'm saying is that, testing a net interface with something like
> bulk data transfer in one direction doesn't verify it works for NFS
> traffic.
> 
> Also, the large RPC messages are a chain of about 33 mbufs of
> various lengths, including a mix of partial clusters and regular
> data mbufs, whereas a bulk send on a socket will typically
> result in an mbuf chain of a lot of full 2K clusters.
> --> As such, NFS can be good at tickling subtle bugs it the
>  net driver related to mbuf handling.
> 
> rick
> 
>>> W.r.t. reverting r367492...the patch to replace r367492 was just
>>> committed to "main" by rscheff@ with a two week MFC, so it
>>> should be in stable/13 soon. Not sure if an errata can be done
>>> for it for releng13.0?
>> 
>> That update is reported to be causing "rack" related panics:
>> 
>> https://lists.freebsd.org/pipermail/dev-commits-src-main/2021-May/004440.html
>> 
>> reports (via links):
>> 
>> panic: _mtx_lock_sleep: recursed on non-recursive mutex so_snd @ 
>> /syzkaller/managers/i386/kernel/sys/modules/tcp/rack/../../../netinet/tcp_stacks/rack.c:10632
>> 
>> Still, I have a non-debug update to main building and will
>> likely do a debug build as well. llvm is rebuilding, so
>> the builds will take a notable time.

I got the following built and installed on the two
machines:

# uname -apKU
FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #1 
main-n246854-03b0505b8fe8-dirty: Sat May 22 16:25:04 PDT 2021 
root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-DBG-CA72
  arm64 aarch64 1400013 1400013

# uname -apKU
FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #1 
main-n246854-03b0505b8fe8-dirty: Sat May 22 16:25:04 PDT 2021 
root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-DBG-CA72
  arm64 aarch64 1400013 1400013

Note that both are booted with debug builds of main.

Using the context with the alternate EtherNet device that has not
had an associated diff -r, find, pr ls -R failure yet
yet got a panic that looks likely to be unrelated:

# mount -onoatime 192.168.1.187:/usr/ports/ /mnt/
# diff -r /usr/ports/ /mnt/ | more
nvme0: cpl does not map to outstanding cmd
cdw0: sqhd:0020 sqid:0003 cid:007e p:1 sc:00 sct:0 m:0 dnr:0
panic: received completion for unknown cmd
cpuid = 3
time = 1621743752
KDB: stack backtrace:
db_trace_self() at db_trace_self
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
vpanic() at vpanic+0x188
panic() at panic+0x44
nvme_qpair_process_completions() at nvme_qpair_process_completions+0x1fc
nvme_timeout() at nvme_timeout+0x3c
softclock_call_cc() at softclock_call_cc+0x124
softclock() at softclock+0x60
ithread_loop() at ithread_loop+0x2a8
fork_exit() at fork_exit+0x74
fork_trampoline() at fork_trampoline+0x14
KDB: enter: panic
[ thread pid 12 tid 100028 ]
Stopped at  kdb_enter+0x48: undefined   f904411f
db> 

Based on the "nvme" references, I expect this is tied to
handling the Optane 480 GiByte that is in the PCIe 

Re: releng/13 release/13.0.0 : odd/incorrect diff result over nfs (in a zfs file systems context)

[Rick Macklem]

Mark Millard wrote:
[stuff snipped]
>Well, why is it that ls -R, find, and diff -r all get file
>name problems via genet0 but diff -r gets no problems
>comparing the content of files that it does match up (the
>vast majority)? Any clue how could the problems possibly
>be unique to the handling of file names/paths? Does it
>suggest anything else to look into for getting some more
>potentially useful evidence?
Well, all I can do is describe the most common TSO related
failure:
- When a read RPC reply (including NFS/RPC/TCP/IP headers)
  is slightly less than 64K bytes (many TSO implementations are
  limited to 64K or 32 discontiguous segments, think 32 2K
  mbuf clusters), the driver decides it is ok, but when the MAC
  header is added it exceeds what the hardware can handle correctly...
--> This will happen when reading a regular file that is slightly less
   than a multiple of 64K in size.
or
--> This will happen when reading just about any large directory,
  since the directory reply for a 64K request is converted to Sun XDR
  format and clipped at the last full directory entry that will fit within 
64K.
For ports, where most files are small, I think you can tell which is more
likely to happen.
--> If TSO is disabled, I have no idea how this might matter, but??

>I'll note that netstat -I ue0 -d and netstat -I genet0 -d
>do not report changes in Ierrs or Idrop in a before vs.
>after failures comparison. (There may be better figures
>to look at for all I know.)
>
>I tried "ifconfig genet0 -rxcsum -rxcsum -rxcsum6 -txcsum6"
>and got no obvious change in behavior.
All we know is that the data is getting corrupted somehow.

NFS traffic looks very different than typical TCP traffic. It is
mostly small messages travelling in both directions concurrently,
with some large messages thrown in the mix.
All I'm saying is that, testing a net interface with something like
bulk data transfer in one direction doesn't verify it works for NFS
traffic.

Also, the large RPC messages are a chain of about 33 mbufs of
various lengths, including a mix of partial clusters and regular
data mbufs, whereas a bulk send on a socket will typically
result in an mbuf chain of a lot of full 2K clusters.
--> As such, NFS can be good at tickling subtle bugs it the
  net driver related to mbuf handling.

rick

> W.r.t. reverting r367492...the patch to replace r367492 was just
> committed to "main" by rscheff@ with a two week MFC, so it
> should be in stable/13 soon. Not sure if an errata can be done
> for it for releng13.0?

That update is reported to be causing "rack" related panics:

https://lists.freebsd.org/pipermail/dev-commits-src-main/2021-May/004440.html

reports (via links):

panic: _mtx_lock_sleep: recursed on non-recursive mutex so_snd @ 
/syzkaller/managers/i386/kernel/sys/modules/tcp/rack/../../../netinet/tcp_stacks/rack.c:10632

Still, I have a non-debug update to main building and will
likely do a debug build as well. llvm is rebuilding, so
the builds will take a notable time.

> Thanks for isolating this, rick
> ps: Co-incidentally, I've been thinking of buying an RBPi4 as a toy.

I'll warn that the primary "small arm" development/support
folk(s) do not work on the RPi*'s these days, beyond
committing what others provide and the like.




===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: releng/13 release/13.0.0 : odd/incorrect diff result over nfs (in a zfs file systems context)

[Mark Millard via freebsd-stable]

On 2021-May-21, at 09:00, Rick Macklem  wrote:

> Mark Millard wrote:
>> On 2021-May-20, at 22:19, Rick Macklem  wrote:
> [stuff snipped]
>>> ps: I do not think that r367492 could cause this, but it would be
>>>nice if you try a kernel with the r367492 patch reverted.
>>>It is currently in all of releng13, stable13 and main, although
>>>the patch to fix this is was just reviewed and may hit main soon.
>> 
>> Do you want a debug kernel to be used? Do you have a preference
>> for main vs. stable/13 vs. release/13.0.0 based? Is it okay to
>> stick to the base version things are now based on --or do you
>> want me to update to more recent? (That last only applies if
>> main or stable/13 is to be put to use.)
> Well, it sounds like you've isolated it to the genet interface.
> Good sluething.
> Unfortunately, NFS is only as good as the network fabric under it.
> However, it's usually hangs or poor performance. Except maybe
> for the readdir issue that Jason Bacon reported and resolved via
> an upgrade, this is a first.
> --> In the old days, I would have expected IP checksums to catch
>   this, but I'm guessing the hardware/net driver are doing them
>   these days?

Well, why is it that ls -R, find, and diff -r all get file
name problems via genet0 but diff -r gets no problems
comparing the content of files that it does match up (the
vast majority)? Any clue how could the problems possibly
be unique to the handling of file names/paths? Does it
suggest anything else to look into for getting some more
potentially useful evidence?

I'll note that netstat -I ue0 -d and netstat -I genet0 -d
do not report changes in Ierrs or Idrop in a before vs.
after failures comparison. (There may be better figures
to look at for all I know.)

I tried "ifconfig genet0 -rxcsum -rxcsum -rxcsum6 -txcsum6"
and got no obvious change in behavior.

> W.r.t. reverting r367492...the patch to replace r367492 was just
> committed to "main" by rscheff@ with a two week MFC, so it
> should be in stable/13 soon. Not sure if an errata can be done
> for it for releng13.0?

That update is reported to be causing "rack" related panics:

https://lists.freebsd.org/pipermail/dev-commits-src-main/2021-May/004440.html

reports (via links):

panic: _mtx_lock_sleep: recursed on non-recursive mutex so_snd @ 
/syzkaller/managers/i386/kernel/sys/modules/tcp/rack/../../../netinet/tcp_stacks/rack.c:10632

Still, I have a non-debug update to main building and will
likely do a debug build as well. llvm is rebuilding, so
the builds will take a notable time.

> Thanks for isolating this, rick
> ps: Co-incidentally, I've been thinking of buying an RBPi4 as a toy.

I'll warn that the primary "small arm" development/support
folk(s) do not work on the RPi*'s these days, beyond
committing what others provide and the like.




===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: releng/13 release/13.0.0 : odd/incorrect diff result over nfs (in a zfs file systems context)

[Rick Macklem]

Mark Millard wrote:
>On 2021-May-20, at 22:19, Rick Macklem  wrote:
[stuff snipped]
>> ps: I do not think that r367492 could cause this, but it would be
>> nice if you try a kernel with the r367492 patch reverted.
>> It is currently in all of releng13, stable13 and main, although
>> the patch to fix this is was just reviewed and may hit main soon.
>
>Do you want a debug kernel to be used? Do you have a preference
>for main vs. stable/13 vs. release/13.0.0 based? Is it okay to
>stick to the base version things are now based on --or do you
>want me to update to more recent? (That last only applies if
>main or stable/13 is to be put to use.)
Well, it sounds like you've isolated it to the genet interface.
Good sluething.
Unfortunately, NFS is only as good as the network fabric under it.
However, it's usually hangs or poor performance. Except maybe
for the readdir issue that Jason Bacon reported and resolved via
an upgrade, this is a first.
--> In the old days, I would have expected IP checksums to catch
   this, but I'm guessing the hardware/net driver are doing them
   these days?

W.r.t. reverting r367492...the patch to replace r367492 was just
committed to "main" by rscheff@ with a two week MFC, so it
should be in stable/13 soon. Not sure if an errata can be done
for it for releng13.0?

Thanks for isolating this, rick
ps: Co-incidentally, I've been thinking of buying an RBPi4 as a toy.
> . . . old history deleted . . .

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: (was) FreeBSD 12 and Nocona

[Marek Zarychta]

W dniu 25.02.2019 o 18:47, Marek Zarychta pisze:
> W dniu 08.01.2019 o 12:51, Stefan Bethke pisze:
>> Am 08.01.2019 um 10:34 schrieb Marek Zarychta 
>> :
>>> W dniu 03.01.2019 o 14:13, Stefan Bethke pisze:
> I have under supervision a few old servers running 11.2-STABLE. The
> hardware is almost for retirement, but still in working condition. It's
> all old Nocona NetBurst microarchitecture. I have recently tried do
> upgrade OS two of them to 12.0-STABLE, but failed. When I use old
> bootloader the boot freezes on blue highlighted "Booting" stage, when I
> tried to use 12 loader, it freezes earlier, on loading kernel modules.
> The kernel was compiled from fresh sources for CPUTYPE?=nocona.
> 11.2-STABLE is fine with this optimization and the same kernel boots
> fine on newer hardware.
>
> It is fair, that 11 EOL is expected September 30, 2021 and these servers
> will likely be retired before this date, but some questions arise:
>
> Is such old hardware still supported? Is it possible (how to) debug the
> booting process?
 The first step is to try with known-good bits: can you boot these machines 
 off the 12.0 ISO or memstick images? Can you load your kernel and modules 
 with the loader from the ISO/memstick? Does GENERIC built without any 
 flags work?

 If any of these don’t work, try to be as specific as possible when 
 reporting problems. For example, the exact make of mainboard (kenv output) 
 and the BIOS version, and any relevant BIOS settings are likely important 
 for problems regarding the loader. If the kernel and modules load, you can 
 try a verbose boot to see better how far the kernel gets.

 I’d be really surprised if the CPUs themselves would cause trouble.
>>> The first step is done. The affected hardware doesn't boot from official
>>> 12.0-RELEASE CD either. Loader also freezes at the stage of loading
>>> kernel modules. These servers are old Maxdata Platinum 500 and 3200.
>>> Some time ago I have submitted dmesgs to NYC BUG dmesg repository[1][2].
>>>
>>> Both configurations are fine with 11-STABLE, so I am not going to
>>> upgrade them and I am replying only FYI.
>>>
>>>
>>> [1] https://dmesgd.nycbug.org/index.cgi?do=view=3790 
>>> 
>>> [2] https://dmesgd.nycbug.org/index.cgi?do=view=4111 
>>> 
>> I think it would be great to get some input from someone familiar with the 
>> new loader. I’ve cc’ed Warner, Kyle and Toomas, as they were listed in the 
>> quarterly status report.
>>
> After recent MFCs LUA loader became available in 11-STABLE branch. I
> have tested it on this old hardware using freshly built r344482. I must
> admit the LUA loader on this hardware loads and boots 11-STABLE kernel
> flawlessly in root on ZFS environment. The only caveat was that
> kernel.old haven't been listed under "5" key, but it wasn't tested
> intensely so the error could be temporary or nonexistent.
>
>
> Nothing changed with regard to booting FreeBSD 12 on this hardware. I
> have tried to boot the recent 12-STABLE kernel. The kernel and all
> modules were loaded (in the same manner as previously loader 4th did),
> but instead of booting machine froze at this stage, so the breakage is
> elsewhere.
>
Out of curiosity I booted 13.0-RELEASE on the last working machine from
this family before it gets retired. Surprisingly it boots just fine.  So
thank you all involved for unbreaking this and providing us with such an
excellent release.

Best regards,

-- 
Marek Zarychta




OpenPGP_signature
Description: OpenPGP digital signature

odd behaviour using lagg on bridge

[Ruben van Staveren via freebsd-stable]

Hi List,

I’m observing some odd behaviour after I decided to put the 2 interfaces in my 
system into a lagg failover bond

- Can’t add the lagg to a bridge, it will say:

$ sudo ifconfig vm-public addm lagg0
ifconfig: BRDGADD lagg0: Device busy

I also witnessed that starting a vm after having it reconfigured to use a 
manual bridge (instead of the vm-bhyve managed one) where lagg0 is present all 
IPv6 addresses are being stripped from the lagg interface.

A service netif/routing restart doesn’t restore ipv6 connectivity.
I think I saw something similar with a (iocage managed) vnet jail too, as that 
uses bridges too

Regards,
Ruben




signature.asc
Description: Message signed with OpenPGP

Re: releng/13 release/13.0.0 : odd/incorrect diff result over nfs (in a zfs file systems context) [RPi4B genet0 involved in problem]

[Mark Millard via freebsd-stable]

[Looks like the RPi4B genet0 handling is involved.]

On 2021-May-20, at 22:56, Mark Millard  wrote:
> 
> On 2021-May-20, at 22:19, Rick Macklem  wrote:
> 
>> Ok, so it isn't related to "soft".
>> I am wondering if it is something specific to what
>> "diff -r" does?
>> 
>> Could you try:
>> # cd /usr/ports
>> # ls -R > /tmp/x
>> # cd /mnt
>> # ls -R > /tmp/y
>> # cd /tmp
>> # diff -u -p x y
>> --> To see if "ls -R" finds any difference?
>> 
> 
> # diff -u -p x y 
> --- x   2021-05-20 22:35:48.021663000 -0700
> +++ y   2021-05-20 22:39:03.691936000 -0700
> @@ -227209,10 +227209,10 @@ 
> patch-chrome_browser_background_background__mode__mana
> patch-chrome_browser_background_background__mode__optimizer.cc
> patch-chrome_browser_browser__resources.grd
> patch-chrome_browser_browsing__data_chrome__browsing__data__remover__delegate.cc
> +patch-chrome_browser_chrome__browser
> patch-chrome_browser_chrome__browser__interface__binders.cc
> patch-chrome_browser_chrome__browser__main.cc
> patch-chrome_browser_chrome__browser__main__linux.cc
> -patch-chrome_browser_chrome__browser__main__posix.cc
> patch-chrome_browser_chrome__content__browser__client.cc
> patch-chrome_browser_chrome__content__browser__client.h
> patch-chrome_browser_crash__upload__list_crash__upload__list.cc
> 
> # find /usr/ports/ -name 'patch-chrome_browser_chrome__browser*' -print | more
> /usr/ports/devel/electron12/files/patch-chrome_browser_chrome__browser__main__linux.cc
> /usr/ports/devel/electron12/files/patch-chrome_browser_chrome__browser__main.cc
> /usr/ports/devel/electron12/files/patch-chrome_browser_chrome__browser__main__posix.cc
> /usr/ports/devel/electron12/files/patch-chrome_browser_chrome__browser__interface__binders.cc
> /usr/ports/www/chromium/files/patch-chrome_browser_chrome__browser__main__posix.cc
> /usr/ports/www/chromium/files/patch-chrome_browser_chrome__browser__main.cc
> /usr/ports/www/chromium/files/patch-chrome_browser_chrome__browser__main__linux.cc
> /usr/ports/www/chromium/files/patch-chrome_browser_chrome__browser__interface__binders.cc
> 
> find /mnt/ -name 'patch-chrome_browser_chrome__browser*' -print | more
> /mnt/devel/electron12/files/patch-chrome_browser_chrome__browser__main__linux.cc
> /mnt/devel/electron12/files/patch-chrome_browser_chrome__browser__main.cc
> /mnt/devel/electron12/files/patch-chrome_browser_chrome__browser__main__posix.cc
> /mnt/devel/electron12/files/patch-chrome_browser_chrome__browser__interface__binders.cc
> /mnt/www/chromium/files/patch-chrome_browser_chrome__browser
> /mnt/www/chromium/files/patch-chrome_browser_chrome__browser__main.cc
> /mnt/www/chromium/files/patch-chrome_browser_chrome__browser__main__linux.cc
> /mnt/www/chromium/files/patch-chrome_browser_chrome__browser__interface__binders.cc
> 
> So: patch-chrome_browser_chrome__browser appears to be a
> truncated: patch-chrome_browser_chrome__browser__main__posix.cc
> file name and find also gets the same oddity.
> 
> (Note: This had /usr/ports in a main context and /mnt/
> referring to a release/13.0.0 context.)
> 
>> ps: I do not think that r367492 could cause this, but it would be
>>nice if you try a kernel with the r367492 patch reverted.
>>It is currently in all of releng13, stable13 and main, although
>>the patch to fix this is was just reviewed and may hit main soon.
> 
> Do you want a debug kernel to be used? Do you have a preference
> for main vs. stable/13 vs. release/13.0.0 based? Is it okay to
> stick to the base version things are now based on --or do you
> want me to update to more recent? (That last only applies if
> main or stable/13 is to be put to use.)
> 
>> . . . old history deleted . . .

I reversed the roles of the faster vs. somewhat slower
machine and so far my diff -r attempts for this found
no differences. The machines were using different types
of EtherNet devices.

So I've substituted a different EtherNet device onto
the slower machine: the same type of USB3 EtherNet
device in use on the faster machine (instead of
using the RPi4B's builtin EtherNet). So the below
testing is with both machines having a:

ugen0.6:  at usbus0
ure0 on uhub0
ure0:  on usbus0
miibus1:  on ure0
rgephy0:  PHY 0 on miibus1
rgephy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 
1000baseT-FDX-master, auto

in use.

I rebooted with this connected instead of the genet0
interface.

Mounting the slower machine's /usr/ports/ as /mnt/ from the faster machine:
No differences found by diff -r this way (expected result).

Mounting the faster machine's /usr/ports/ as /mnt/ from the slower machine:
No differences found by diff -r this way (expected result).

Doing diff -r's from both sides at the same time:
No differences found by diff -r this way (expected result).


So it looks like genet0 or its supporting software
is contributing to the problems that I had reported.

It is interesting that there were no examples of the
content of files reporting a mismatch, just some file
names/paths not 

Re: releng/13 release/13.0.0 : odd/incorrect diff result over nfs (in a zfs file systems context)

[Mark Millard via freebsd-stable]

On 2021-May-20, at 22:19, Rick Macklem  wrote:

> Ok, so it isn't related to "soft".
> I am wondering if it is something specific to what
> "diff -r" does?
> 
> Could you try:
> # cd /usr/ports
> # ls -R > /tmp/x
> # cd /mnt
> # ls -R > /tmp/y
> # cd /tmp
> # diff -u -p x y
> --> To see if "ls -R" finds any difference?
> 

# diff -u -p x y 
--- x   2021-05-20 22:35:48.021663000 -0700
+++ y   2021-05-20 22:39:03.691936000 -0700
@@ -227209,10 +227209,10 @@ 
patch-chrome_browser_background_background__mode__mana
 patch-chrome_browser_background_background__mode__optimizer.cc
 patch-chrome_browser_browser__resources.grd
 
patch-chrome_browser_browsing__data_chrome__browsing__data__remover__delegate.cc
+patch-chrome_browser_chrome__browser
 patch-chrome_browser_chrome__browser__interface__binders.cc
 patch-chrome_browser_chrome__browser__main.cc
 patch-chrome_browser_chrome__browser__main__linux.cc
-patch-chrome_browser_chrome__browser__main__posix.cc
 patch-chrome_browser_chrome__content__browser__client.cc
 patch-chrome_browser_chrome__content__browser__client.h
 patch-chrome_browser_crash__upload__list_crash__upload__list.cc

# find /usr/ports/ -name 'patch-chrome_browser_chrome__browser*' -print | more
/usr/ports/devel/electron12/files/patch-chrome_browser_chrome__browser__main__linux.cc
/usr/ports/devel/electron12/files/patch-chrome_browser_chrome__browser__main.cc
/usr/ports/devel/electron12/files/patch-chrome_browser_chrome__browser__main__posix.cc
/usr/ports/devel/electron12/files/patch-chrome_browser_chrome__browser__interface__binders.cc
/usr/ports/www/chromium/files/patch-chrome_browser_chrome__browser__main__posix.cc
/usr/ports/www/chromium/files/patch-chrome_browser_chrome__browser__main.cc
/usr/ports/www/chromium/files/patch-chrome_browser_chrome__browser__main__linux.cc
/usr/ports/www/chromium/files/patch-chrome_browser_chrome__browser__interface__binders.cc

 find /mnt/ -name 'patch-chrome_browser_chrome__browser*' -print | more
/mnt/devel/electron12/files/patch-chrome_browser_chrome__browser__main__linux.cc
/mnt/devel/electron12/files/patch-chrome_browser_chrome__browser__main.cc
/mnt/devel/electron12/files/patch-chrome_browser_chrome__browser__main__posix.cc
/mnt/devel/electron12/files/patch-chrome_browser_chrome__browser__interface__binders.cc
/mnt/www/chromium/files/patch-chrome_browser_chrome__browser
/mnt/www/chromium/files/patch-chrome_browser_chrome__browser__main.cc
/mnt/www/chromium/files/patch-chrome_browser_chrome__browser__main__linux.cc
/mnt/www/chromium/files/patch-chrome_browser_chrome__browser__interface__binders.cc

So: patch-chrome_browser_chrome__browser appears to be a
truncated: patch-chrome_browser_chrome__browser__main__posix.cc
file name and find also gets the same oddity.

(Note: This had /usr/ports in a main context and /mnt/
referring to a release/13.0.0 context.)

> ps: I do not think that r367492 could cause this, but it would be
> nice if you try a kernel with the r367492 patch reverted.
> It is currently in all of releng13, stable13 and main, although
> the patch to fix this is was just reviewed and may hit main soon.

Do you want a debug kernel to be used? Do you have a preference
for main vs. stable/13 vs. release/13.0.0 based? Is it okay to
stick to the base version things are now based on --or do you
want me to update to more recent? (That last only applies if
main or stable/13 is to be put to use.)

> . . . old history deleted . . .

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: releng/13 release/13.0.0 : odd/incorrect diff result over nfs (in a zfs file systems context)

[Rick Macklem]

Ok, so it isn't related to "soft".
I am wondering if it is something specific to what
"diff -r" does?

Could you try:
# cd /usr/ports
# ls -R > /tmp/x
# cd /mnt
# ls -R > /tmp/y
# cd /tmp
# diff -u -p x y
--> To see if "ls -R" finds any difference?

rick
ps: I do not think that r367492 could cause this, but it would be
 nice if you try a kernel with the r367492 patch reverted.
 It is currently in all of releng13, stable13 and main, although
 the patch to fix this is was just reviewed and may hit main soon.



From: Mark Millard 
Sent: Friday, May 21, 2021 12:40 AM
To: Rick Macklem
Cc: FreeBSD-STABLE Mailing List
Subject: Re: releng/13 release/13.0.0 : odd/incorrect diff result over nfs (in 
a zfs file systems context)

CAUTION: This email originated from outside of the University of Guelph. Do not 
click links or open attachments unless you recognize the sender and know the 
content is safe. If in doubt, forward suspicious emails to ith...@uoguelph.ca


[main test example and main/releng/13 mixed example]

On 2021-May-20, at 20:36, Mark Millard  wrote:

> [stable/13 test: example ends up being odder. That might
> allow eliminating some potential alternatives.]
>
> On 2021-May-20, at 19:38, Mark Millard  wrote:
>>
>> On 2021-May-20, at 18:09, Rick Macklem  wrote:
>>>
>>> Oh, one additional thing that I'll dare to top post...
>>> r367492 broke the TCP upcalls that the NFS server uses, such
>>> that intermittent hangs of NFS mounts to FreeBSD13 servers can occur.
>>> This has not yet been resolved in "main" etc and could explain
>>> why an RPC could time out for a soft mount.
>>
>> See later notes that I added: soft mount is not required
>> to see the problem.
>>
>>> You can revert the patch in r367492 to avoid the problem.
>>
>> If I understand right, you are indicating that this would
>> not apply to the non-soft mount case that I got.
>>
>>> Disabling TSO, LRO are also de-facto standard things to do when
>>> you observe weird NFS  behaviour, because they are often broken
>>> in various network device drivers.
>>
>> I'll have to figure out how to experiment with such. Things
>> are at defaults rather generally on the systems. I'm not
>> literate in the subject areas.
>>
>> I'm the only user of the machines and network. It is not
>> outward facing. It is a rather small EtherNet network.
>>
>>> rick
>>>
>>> 
>>> From: owner-freebsd-sta...@freebsd.org  
>>> on behalf of Rick Macklem 
>>> Sent: Thursday, May 20, 2021 8:55 PM
>>> To: FreeBSD-STABLE Mailing List; Mark Millard
>>> Subject: Re: releng/13 release/13.0.0 : odd/incorrect diff result over nfs 
>>> (in a zfs file systems context)
>>>
>>> Mark Millard wrote:
 [I warn that I'm a fairly minimal user of NFS
 mounts, not knowing all that much. I'm mostly
 reporting this in case it ends up as evidence
 via eventually matching up with others observing
 possibly related oddities.]

 I got the following odd sequence (that I've
 mixed notes into). It involved a diff -r over NFS
 showing differences (files missing) and then a
 later diff finding matches for the same files,
 no file system changes made on either machine.
 I'm unable to reproduce the oddity on demand.

 Note: A larger scope diff -r originally returned the
 below as well, but doing the narrower diff -r did
 repeat the result and that is what I show. (I
 make no use of devel/ice .)

 # diff -r /usr/ports/devel/ice/files /mnt/devel/ice/files | more
 Only in /usr/ports/devel/ice/files: Make.rules.FreeBSD
>> . . .
 Only in /usr/ports/devel/ice/files: patch-scripts-TestUtil.py

 Note: The above was not expected. So I tried:

 # ls -Tld /mnt/devel/ice/files/*
 -rw-r--r--  1 root  wheel   755 Apr 21 21:07:54 2021 
 /mnt/devel/ice/files/Make.rules.FreeBSD
>> . . .
 -rw-r--r--  1 root  wheel  2588 Apr 21 21:07:54 2021 
 /mnt/devel/ice/files/patch-scripts-TestUtil.py

 Note: So that indicated that the files were there on the
 machine that /mnt references. So attempting the original
 diff -r again:

 # diff -r /usr/ports/devel/ice/files /mnt/devel/ice/files | more
 #

 (Empty difference.)

 Note: So after the explicit "ls -Tld /mnt/devel/ice/files/*"
 the odd result of the diff -r no longer happened: no
 differences reported.



 For reference (both machines reported):

 . . .
 The original mount command was on CA72_16Gp_ZFS:

 # mount -onoatime,soft 192.168.1.170:/usr/ports/ /mnt/
>>> The likely explanation for this is your use of a "soft" mount.
>>> - If the NFS server is slow to respond or there is a temporary network 
>>> issue,
>>> the RPC request can time out and then the
>>> syscall can fail with EINT/ETIMEDOUT. Since almost nothing, including the
>>>  readdir(3) libc functions expect syscalls to fail this way...

Re: releng/13 release/13.0.0 : odd/incorrect diff result over nfs (in a zfs file systems context)

[Mark Millard via freebsd-stable]

[Direct drive connection to machine: no problem.]

On 2021-May-20, at 21:40, Mark Millard  wrote:

> [main test example and main/releng/13 mixed example]
> 
> On 2021-May-20, at 20:36, Mark Millard  wrote:
> 
>> [stable/13 test: example ends up being odder. That might
>> allow eliminating some potential alternatives.]
>> 
>> On 2021-May-20, at 19:38, Mark Millard  wrote:
>>> 
>>> On 2021-May-20, at 18:09, Rick Macklem  wrote:
 
 Oh, one additional thing that I'll dare to top post...
 r367492 broke the TCP upcalls that the NFS server uses, such
 that intermittent hangs of NFS mounts to FreeBSD13 servers can occur.
 This has not yet been resolved in "main" etc and could explain
 why an RPC could time out for a soft mount.
>>> 
>>> See later notes that I added: soft mount is not required
>>> to see the problem.
>>> 
 You can revert the patch in r367492 to avoid the problem.
>>> 
>>> If I understand right, you are indicating that this would
>>> not apply to the non-soft mount case that I got.
>>> 
 Disabling TSO, LRO are also de-facto standard things to do when
 you observe weird NFS  behaviour, because they are often broken
 in various network device drivers.
>>> 
>>> I'll have to figure out how to experiment with such. Things
>>> are at defaults rather generally on the systems. I'm not
>>> literate in the subject areas.
>>> 
>>> I'm the only user of the machines and network. It is not
>>> outward facing. It is a rather small EtherNet network.
>>> 
 rick
 
 
 From: owner-freebsd-sta...@freebsd.org  
 on behalf of Rick Macklem 
 Sent: Thursday, May 20, 2021 8:55 PM
 To: FreeBSD-STABLE Mailing List; Mark Millard
 Subject: Re: releng/13 release/13.0.0 : odd/incorrect diff result over nfs 
 (in a zfs file systems context)
 
 Mark Millard wrote:
> [I warn that I'm a fairly minimal user of NFS
> mounts, not knowing all that much. I'm mostly
> reporting this in case it ends up as evidence
> via eventually matching up with others observing
> possibly related oddities.]
> 
> I got the following odd sequence (that I've
> mixed notes into). It involved a diff -r over NFS
> showing differences (files missing) and then a
> later diff finding matches for the same files,
> no file system changes made on either machine.
> I'm unable to reproduce the oddity on demand.
> 
> Note: A larger scope diff -r originally returned the
> below as well, but doing the narrower diff -r did
> repeat the result and that is what I show. (I
> make no use of devel/ice .)
> 
> # diff -r /usr/ports/devel/ice/files /mnt/devel/ice/files | more
> Only in /usr/ports/devel/ice/files: Make.rules.FreeBSD
>>> . . .
> Only in /usr/ports/devel/ice/files: patch-scripts-TestUtil.py
> 
> Note: The above was not expected. So I tried:
> 
> # ls -Tld /mnt/devel/ice/files/*
> -rw-r--r--  1 root  wheel   755 Apr 21 21:07:54 2021 
> /mnt/devel/ice/files/Make.rules.FreeBSD
>>> . . .
> -rw-r--r--  1 root  wheel  2588 Apr 21 21:07:54 2021 
> /mnt/devel/ice/files/patch-scripts-TestUtil.py
> 
> Note: So that indicated that the files were there on the
> machine that /mnt references. So attempting the original
> diff -r again:
> 
> # diff -r /usr/ports/devel/ice/files /mnt/devel/ice/files | more
> #
> 
> (Empty difference.)
> 
> Note: So after the explicit "ls -Tld /mnt/devel/ice/files/*"
> the odd result of the diff -r no longer happened: no
> differences reported.
> 
> 
> 
> For reference (both machines reported):
> 
> . . .
> The original mount command was on CA72_16Gp_ZFS:
> 
> # mount -onoatime,soft 192.168.1.170:/usr/ports/ /mnt/
 The likely explanation for this is your use of a "soft" mount.
 - If the NFS server is slow to respond or there is a temporary network 
 issue,
 the RPC request can time out and then the
 syscall can fail with EINT/ETIMEDOUT. Since almost nothing, including the
 readdir(3) libc functions expect syscalls to fail this way...
 Then the cached directory is messed up.
 Doing the "ls" read the directory again and fixed the problem.
 
 Try to reproduce it for a mount without the "soft" option.
 (If a mount point is hung, due to an unresponsive server "umount -N /mnt"
 can usually get rid of it.)
 Personally, I thought "soft" was a bad idea when Sun introduced it in NFS 
 in 1985
 and I still feel that way.
 --> If you can reproduce it without "soft" then I can't explain it.
   To be honest, the directory reading/caching code in the NFSv3 client
   hasn't changed significantly in literally decades, as far as I can 
 remember.
>>> 
>>> Well . . . trying an even wider scope diff than
>>> the original . . .
>>> 
>>> # umount /mnt/
>>> # mount -onoatime 

Re: releng/13 release/13.0.0 : odd/incorrect diff result over nfs (in a zfs file systems context)

[Mark Millard via freebsd-stable]

[main test example and main/releng/13 mixed example]

On 2021-May-20, at 20:36, Mark Millard  wrote:

> [stable/13 test: example ends up being odder. That might
> allow eliminating some potential alternatives.]
> 
> On 2021-May-20, at 19:38, Mark Millard  wrote:
>> 
>> On 2021-May-20, at 18:09, Rick Macklem  wrote:
>>> 
>>> Oh, one additional thing that I'll dare to top post...
>>> r367492 broke the TCP upcalls that the NFS server uses, such
>>> that intermittent hangs of NFS mounts to FreeBSD13 servers can occur.
>>> This has not yet been resolved in "main" etc and could explain
>>> why an RPC could time out for a soft mount.
>> 
>> See later notes that I added: soft mount is not required
>> to see the problem.
>> 
>>> You can revert the patch in r367492 to avoid the problem.
>> 
>> If I understand right, you are indicating that this would
>> not apply to the non-soft mount case that I got.
>> 
>>> Disabling TSO, LRO are also de-facto standard things to do when
>>> you observe weird NFS  behaviour, because they are often broken
>>> in various network device drivers.
>> 
>> I'll have to figure out how to experiment with such. Things
>> are at defaults rather generally on the systems. I'm not
>> literate in the subject areas.
>> 
>> I'm the only user of the machines and network. It is not
>> outward facing. It is a rather small EtherNet network.
>> 
>>> rick
>>> 
>>> 
>>> From: owner-freebsd-sta...@freebsd.org  
>>> on behalf of Rick Macklem 
>>> Sent: Thursday, May 20, 2021 8:55 PM
>>> To: FreeBSD-STABLE Mailing List; Mark Millard
>>> Subject: Re: releng/13 release/13.0.0 : odd/incorrect diff result over nfs 
>>> (in a zfs file systems context)
>>> 
>>> Mark Millard wrote:
 [I warn that I'm a fairly minimal user of NFS
 mounts, not knowing all that much. I'm mostly
 reporting this in case it ends up as evidence
 via eventually matching up with others observing
 possibly related oddities.]
 
 I got the following odd sequence (that I've
 mixed notes into). It involved a diff -r over NFS
 showing differences (files missing) and then a
 later diff finding matches for the same files,
 no file system changes made on either machine.
 I'm unable to reproduce the oddity on demand.
 
 Note: A larger scope diff -r originally returned the
 below as well, but doing the narrower diff -r did
 repeat the result and that is what I show. (I
 make no use of devel/ice .)
 
 # diff -r /usr/ports/devel/ice/files /mnt/devel/ice/files | more
 Only in /usr/ports/devel/ice/files: Make.rules.FreeBSD
>> . . .
 Only in /usr/ports/devel/ice/files: patch-scripts-TestUtil.py
 
 Note: The above was not expected. So I tried:
 
 # ls -Tld /mnt/devel/ice/files/*
 -rw-r--r--  1 root  wheel   755 Apr 21 21:07:54 2021 
 /mnt/devel/ice/files/Make.rules.FreeBSD
>> . . .
 -rw-r--r--  1 root  wheel  2588 Apr 21 21:07:54 2021 
 /mnt/devel/ice/files/patch-scripts-TestUtil.py
 
 Note: So that indicated that the files were there on the
 machine that /mnt references. So attempting the original
 diff -r again:
 
 # diff -r /usr/ports/devel/ice/files /mnt/devel/ice/files | more
 #
 
 (Empty difference.)
 
 Note: So after the explicit "ls -Tld /mnt/devel/ice/files/*"
 the odd result of the diff -r no longer happened: no
 differences reported.
 
 
 
 For reference (both machines reported):
 
 . . .
 The original mount command was on CA72_16Gp_ZFS:
 
 # mount -onoatime,soft 192.168.1.170:/usr/ports/ /mnt/
>>> The likely explanation for this is your use of a "soft" mount.
>>> - If the NFS server is slow to respond or there is a temporary network 
>>> issue,
>>> the RPC request can time out and then the
>>> syscall can fail with EINT/ETIMEDOUT. Since almost nothing, including the
>>>  readdir(3) libc functions expect syscalls to fail this way...
>>>  Then the cached directory is messed up.
>>>  Doing the "ls" read the directory again and fixed the problem.
>>> 
>>> Try to reproduce it for a mount without the "soft" option.
>>> (If a mount point is hung, due to an unresponsive server "umount -N /mnt"
>>> can usually get rid of it.)
>>> Personally, I thought "soft" was a bad idea when Sun introduced it in NFS 
>>> in 1985
>>> and I still feel that way.
>>> --> If you can reproduce it without "soft" then I can't explain it.
>>>To be honest, the directory reading/caching code in the NFSv3 client
>>>hasn't changed significantly in literally decades, as far as I can 
>>> remember.
>> 
>> Well . . . trying an even wider scope diff than
>> the original . . .
>> 
>> # umount /mnt/
>> # mount -onoatime 192.168.1.170:/usr/ports/ /mnt/
>> # diff -r /usr/ports/ /mnt/ | more
>> Only in /mnt/databases/mongodb42/files/aarch64: 
>> patch-src_third__party_mozjs-60_
>> Only in /usr/ports/databases/mongodb42/files/aarch64: 
>> 

Re: releng/13 release/13.0.0 : odd/incorrect diff result over nfs (in a zfs file systems context)

[Mark Millard via freebsd-stable]

[stable/13 test: example ends up being odder. That might
allow eliminating some potential alternatives.]

On 2021-May-20, at 19:38, Mark Millard  wrote:
> 
> On 2021-May-20, at 18:09, Rick Macklem  wrote:
>> 
>> Oh, one additional thing that I'll dare to top post...
>> r367492 broke the TCP upcalls that the NFS server uses, such
>> that intermittent hangs of NFS mounts to FreeBSD13 servers can occur.
>> This has not yet been resolved in "main" etc and could explain
>> why an RPC could time out for a soft mount.
> 
> See later notes that I added: soft mount is not required
> to see the problem.
> 
>> You can revert the patch in r367492 to avoid the problem.
> 
> If I understand right, you are indicating that this would
> not apply to the non-soft mount case that I got.
> 
>> Disabling TSO, LRO are also de-facto standard things to do when
>> you observe weird NFS  behaviour, because they are often broken
>> in various network device drivers.
> 
> I'll have to figure out how to experiment with such. Things
> are at defaults rather generally on the systems. I'm not
> literate in the subject areas.
> 
> I'm the only user of the machines and network. It is not
> outward facing. It is a rather small EtherNet network.
> 
>> rick
>> 
>> 
>> From: owner-freebsd-sta...@freebsd.org  on 
>> behalf of Rick Macklem 
>> Sent: Thursday, May 20, 2021 8:55 PM
>> To: FreeBSD-STABLE Mailing List; Mark Millard
>> Subject: Re: releng/13 release/13.0.0 : odd/incorrect diff result over nfs 
>> (in a zfs file systems context)
>> 
>> Mark Millard wrote:
>>> [I warn that I'm a fairly minimal user of NFS
>>> mounts, not knowing all that much. I'm mostly
>>> reporting this in case it ends up as evidence
>>> via eventually matching up with others observing
>>> possibly related oddities.]
>>> 
>>> I got the following odd sequence (that I've
>>> mixed notes into). It involved a diff -r over NFS
>>> showing differences (files missing) and then a
>>> later diff finding matches for the same files,
>>> no file system changes made on either machine.
>>> I'm unable to reproduce the oddity on demand.
>>> 
>>> Note: A larger scope diff -r originally returned the
>>> below as well, but doing the narrower diff -r did
>>> repeat the result and that is what I show. (I
>>> make no use of devel/ice .)
>>> 
>>> # diff -r /usr/ports/devel/ice/files /mnt/devel/ice/files | more
>>> Only in /usr/ports/devel/ice/files: Make.rules.FreeBSD
> . . .
>>> Only in /usr/ports/devel/ice/files: patch-scripts-TestUtil.py
>>> 
>>> Note: The above was not expected. So I tried:
>>> 
>>> # ls -Tld /mnt/devel/ice/files/*
>>> -rw-r--r--  1 root  wheel   755 Apr 21 21:07:54 2021 
>>> /mnt/devel/ice/files/Make.rules.FreeBSD
> . . .
>>> -rw-r--r--  1 root  wheel  2588 Apr 21 21:07:54 2021 
>>> /mnt/devel/ice/files/patch-scripts-TestUtil.py
>>> 
>>> Note: So that indicated that the files were there on the
>>> machine that /mnt references. So attempting the original
>>> diff -r again:
>>> 
>>> # diff -r /usr/ports/devel/ice/files /mnt/devel/ice/files | more
>>> #
>>> 
>>> (Empty difference.)
>>> 
>>> Note: So after the explicit "ls -Tld /mnt/devel/ice/files/*"
>>> the odd result of the diff -r no longer happened: no
>>> differences reported.
>>> 
>>> 
>>> 
>>> For reference (both machines reported):
>>> 
>>> . . .
>>> The original mount command was on CA72_16Gp_ZFS:
>>> 
>>> # mount -onoatime,soft 192.168.1.170:/usr/ports/ /mnt/
>> The likely explanation for this is your use of a "soft" mount.
>> - If the NFS server is slow to respond or there is a temporary network issue,
>>  the RPC request can time out and then the
>>  syscall can fail with EINT/ETIMEDOUT. Since almost nothing, including the
>>   readdir(3) libc functions expect syscalls to fail this way...
>>   Then the cached directory is messed up.
>>   Doing the "ls" read the directory again and fixed the problem.
>> 
>> Try to reproduce it for a mount without the "soft" option.
>> (If a mount point is hung, due to an unresponsive server "umount -N /mnt"
>> can usually get rid of it.)
>> Personally, I thought "soft" was a bad idea when Sun introduced it in NFS in 
>> 1985
>> and I still feel that way.
>> --> If you can reproduce it without "soft" then I can't explain it.
>> To be honest, the directory reading/caching code in the NFSv3 client
>> hasn't changed significantly in literally decades, as far as I can 
>> remember.
> 
> Well . . . trying an even wider scope diff than
> the original . . .
> 
> # umount /mnt/
> # mount -onoatime 192.168.1.170:/usr/ports/ /mnt/
> # diff -r /usr/ports/ /mnt/ | more
> Only in /mnt/databases/mongodb42/files/aarch64: 
> patch-src_third__party_mozjs-60_
> Only in /usr/ports/databases/mongodb42/files/aarch64: 
> patch-src_third__party_mozjs-60_platform_aarch64_freebsd_build_Unified__cpp__js__src25.cpp
> Only in /usr/ports/devel/ice/files: Make.rules.FreeBSD
> Only in /usr/ports/devel/ice/files: patch-config-Make.common.rules
> Only in 

Re: releng/13 release/13.0.0 : odd/incorrect diff result over nfs (in a zfs file systems context)

[Mark Millard via freebsd-stable]

> On 2021-May-20, at 18:09, Rick Macklem  wrote:
> 
> Oh, one additional thing that I'll dare to top post...
> r367492 broke the TCP upcalls that the NFS server uses, such
> that intermittent hangs of NFS mounts to FreeBSD13 servers can occur.
> This has not yet been resolved in "main" etc and could explain
> why an RPC could time out for a soft mount.

See later notes that I added: soft mount is not required
to see the problem.

> You can revert the patch in r367492 to avoid the problem.

If I understand right, you are indicating that this would
not apply to the non-soft mount case that I got.

> Disabling TSO, LRO are also de-facto standard things to do when
> you observe weird NFS  behaviour, because they are often broken
> in various network device drivers.

I'll have to figure out how to experiment with such. Things
are at defaults rather generally on the systems. I'm not
literate in the subject areas.

I'm the only user of the machines and network. It is not
outward facing. It is a rather small EtherNet network.

> rick
> 
> 
> From: owner-freebsd-sta...@freebsd.org  on 
> behalf of Rick Macklem 
> Sent: Thursday, May 20, 2021 8:55 PM
> To: FreeBSD-STABLE Mailing List; Mark Millard
> Subject: Re: releng/13 release/13.0.0 : odd/incorrect diff result over nfs 
> (in a zfs file systems context)
> 
> Mark Millard wrote:
>> [I warn that I'm a fairly minimal user of NFS
>> mounts, not knowing all that much. I'm mostly
>> reporting this in case it ends up as evidence
>> via eventually matching up with others observing
>> possibly related oddities.]
>> 
>> I got the following odd sequence (that I've
>> mixed notes into). It involved a diff -r over NFS
>> showing differences (files missing) and then a
>> later diff finding matches for the same files,
>> no file system changes made on either machine.
>> I'm unable to reproduce the oddity on demand.
>> 
>> Note: A larger scope diff -r originally returned the
>> below as well, but doing the narrower diff -r did
>> repeat the result and that is what I show. (I
>> make no use of devel/ice .)
>> 
>> # diff -r /usr/ports/devel/ice/files /mnt/devel/ice/files | more
>> Only in /usr/ports/devel/ice/files: Make.rules.FreeBSD
. . .
>> Only in /usr/ports/devel/ice/files: patch-scripts-TestUtil.py
>> 
>> Note: The above was not expected. So I tried:
>> 
>> # ls -Tld /mnt/devel/ice/files/*
>> -rw-r--r--  1 root  wheel   755 Apr 21 21:07:54 2021 
>> /mnt/devel/ice/files/Make.rules.FreeBSD
. . .
>> -rw-r--r--  1 root  wheel  2588 Apr 21 21:07:54 2021 
>> /mnt/devel/ice/files/patch-scripts-TestUtil.py
>> 
>> Note: So that indicated that the files were there on the
>> machine that /mnt references. So attempting the original
>> diff -r again:
>> 
>> # diff -r /usr/ports/devel/ice/files /mnt/devel/ice/files | more
>> #
>> 
>> (Empty difference.)
>> 
>> Note: So after the explicit "ls -Tld /mnt/devel/ice/files/*"
>> the odd result of the diff -r no longer happened: no
>> differences reported.
>> 
>> 
>> 
>> For reference (both machines reported):
>> 
>> . . .
>> The original mount command was on CA72_16Gp_ZFS:
>> 
>> # mount -onoatime,soft 192.168.1.170:/usr/ports/ /mnt/
> The likely explanation for this is your use of a "soft" mount.
> - If the NFS server is slow to respond or there is a temporary network issue,
>   the RPC request can time out and then the
>   syscall can fail with EINT/ETIMEDOUT. Since almost nothing, including the
>readdir(3) libc functions expect syscalls to fail this way...
>Then the cached directory is messed up.
>Doing the "ls" read the directory again and fixed the problem.
> 
> Try to reproduce it for a mount without the "soft" option.
> (If a mount point is hung, due to an unresponsive server "umount -N /mnt"
> can usually get rid of it.)
> Personally, I thought "soft" was a bad idea when Sun introduced it in NFS in 
> 1985
> and I still feel that way.
> --> If you can reproduce it without "soft" then I can't explain it.
>  To be honest, the directory reading/caching code in the NFSv3 client
>  hasn't changed significantly in literally decades, as far as I can 
> remember.

Well . . . trying an even wider scope diff than
the original . . .

# umount /mnt/
# mount -onoatime 192.168.1.170:/usr/ports/ /mnt/
# diff -r /usr/ports/ /mnt/ | more
Only in /mnt/databases/mongodb42/files/aarch64: patch-src_third__party_mozjs-60_
Only in /usr/ports/databases/mongodb42/files/aarch64: 
patch-src_third__party_mozjs-60_platform_aarch64_freebsd_build_Unified__cpp__js__src25.cpp
Only in /usr/ports/devel/ice/files: Make.rules.FreeBSD
Only in /usr/ports/devel/ice/files: patch-config-Make.common.rules
Only in /usr/ports/devel/ice/files: patch-cpp-Makefile
. . .
Only in /usr/ports/devel/ice/files: patch-python-test-Slice-unicodePaths-run.py
Only in /usr/ports/devel/ice/files: patch-scripts-Expect.py
Only in /usr/ports/devel/ice/files: patch-scripts-IceGridAdmin.py
Only in /usr/ports/devel/ice/files: 

Re: releng/13 release/13.0.0 : odd/incorrect diff result over nfs (in a zfs file systems context)

[Rick Macklem]

Oh, one additional thing that I'll dare to top post...
r367492 broke the TCP upcalls that the NFS server uses, such
that intermittent hangs of NFS mounts to FreeBSD13 servers can occur.
This has not yet been resolved in "main" etc and could explain
why an RPC could time out for a soft mount.

You can revert the patch in r367492 to avoid the problem.

Disabling TSO, LRO are also de-facto standard things to do when
you observe weird NFS  behaviour, because they are often broken
in various network device drivers.

rick


From: owner-freebsd-sta...@freebsd.org  on 
behalf of Rick Macklem 
Sent: Thursday, May 20, 2021 8:55 PM
To: FreeBSD-STABLE Mailing List; Mark Millard
Subject: Re: releng/13 release/13.0.0 : odd/incorrect diff result over nfs (in 
a zfs file systems context)

Mark Millard wrote:
>[I warn that I'm a fairly minimal user of NFS
>mounts, not knowing all that much. I'm mostly
>reporting this in case it ends up as evidence
>via eventually matching up with others observing
>possibly related oddities.]
>
>I got the following odd sequence (that I've
>mixed notes into). It involved a diff -r over NFS
>showing differences (files missing) and then a
>later diff finding matches for the same files,
>no file system changes made on either machine.
>I'm unable to reproduce the oddity on demand.
>
>Note: A larger scope diff -r originally returned the
>below as well, but doing the narrower diff -r did
>repeat the result and that is what I show. (I
>make no use of devel/ice .)
>
># diff -r /usr/ports/devel/ice/files /mnt/devel/ice/files | more
>Only in /usr/ports/devel/ice/files: Make.rules.FreeBSD
>Only in /usr/ports/devel/ice/files: patch-config-Make.common.rules
>Only in /usr/ports/devel/ice/files: patch-cpp-Makefile
>Only in /usr/ports/devel/ice/files: patch-cpp-allTests.py
>Only in /usr/ports/devel/ice/files: patch-cpp-config-Make.rules
>Only in /usr/ports/devel/ice/files: patch-cpp-include-Ice-FactoryTableInit.h
>Only in /usr/ports/devel/ice/files: patch-cpp-include-IceUtil-Config.h
>Only in /usr/ports/devel/ice/files: patch-cpp-include-IceUtil-ScannerConfig.h
>Only in /usr/ports/devel/ice/files: 
>patch-cpp-src-Glacier2CryptPermissionsVerifier-CryptPermissionsVerifierI.cpp
>Only in /usr/ports/devel/ice/files: patch-cpp-src-Ice-ProxyFactory.cpp
>Only in /usr/ports/devel/ice/files: patch-cpp-src-IceGrid-PluginFacadeI.cpp
>Only in /usr/ports/devel/ice/files: patch-cpp-src-IceGrid-RegistryI.cpp
>Only in /usr/ports/devel/ice/files: patch-cpp-src-IceSSL-Makefile
>Only in /usr/ports/devel/ice/files: patch-cpp-test-Glacier2-ssl-Server.cpp
>Only in /usr/ports/devel/ice/files: 
>patch-cpp-test-Glacier2-staticFiltering-run.py
>Only in /usr/ports/devel/ice/files: patch-cpp-test-Ice-info-AllTests.cpp
>Only in /usr/ports/devel/ice/files: patch-cpp-test-Ice-metrics-AllTests.cpp
>Only in /usr/ports/devel/ice/files: patch-cpp-test-Ice-objects-Makefile
>Only in /usr/ports/devel/ice/files: patch-cpp-test-Ice-properties-run.py
>Only in /usr/ports/devel/ice/files: patch-cpp-test-IceGrid-admin-run.py
>Only in /usr/ports/devel/ice/files: 
>patch-cpp-test-IceGrid-deployer-AllTests.cpp
>Only in /usr/ports/devel/ice/files: patch-cpp-test-IceGrid-deployer-Makefile
>Only in /usr/ports/devel/ice/files: 
>patch-cpp-test-IceGrid-deployer-application.xml
>Only in /usr/ports/devel/ice/files: 
>patch-cpp-test-IceGrid-distribution-AllTests.cpp
>Only in /usr/ports/devel/ice/files: 
>patch-cpp-test-IceGrid-distribution-application.xml
>Only in /usr/ports/devel/ice/files: patch-cpp-test-IceGrid-distribution-run.py
>Only in /usr/ports/devel/ice/files: patch-cpp-test-IceGrid-session-run.py
>Only in /usr/ports/devel/ice/files: 
>patch-cpp-test-IceSSL-configuration-AllTests.cpp
>Only in /usr/ports/devel/ice/files: patch-cpp-test-IceSSL-configuration-run.py
>Only in /usr/ports/devel/ice/files: patch-cpp-test-Slice-headers-run.py
>Only in /usr/ports/devel/ice/files: patch-cpp-test-Slice-unicodePaths-run.py
>Only in /usr/ports/devel/ice/files: patch-cpp-test-include-TestCommon.h
>Only in /usr/ports/devel/ice/files: patch-php-Makefile
>Only in /usr/ports/devel/ice/files: patch-php-config-Make.rules.php
>Only in /usr/ports/devel/ice/files: patch-php-lib-Makefile
>Only in /usr/ports/devel/ice/files: patch-python-Makefile
>Only in /usr/ports/devel/ice/files: patch-python-config-Make.rules
>Only in /usr/ports/devel/ice/files: patch-python-modules-IcePy-Types.cpp
>Only in /usr/ports/devel/ice/files: patch-python-modules-IcePy-Types.h
>Only in /usr/ports/devel/ice/files: patch-python-python-Makefile
>Only in /usr/ports/devel/ice/files: patch-python-test-Ice-info-AllTests.py
>Only in /usr/ports/devel/ice/files: patch-python-test-Ice-properties-run.py
>Only in /usr/ports/devel/ice/files: patch-python-test-Slice-unicodePaths-run.py
>Only in /usr/ports/devel/ice/files: patch-scripts-Expect.py
>Only in /usr/ports/devel/ice/files: patch-scripts-IceGridAdmin.py
>Only in /usr/ports/devel/ice/files: patch-scripts-TestUtil.py

Re: releng/13 release/13.0.0 : odd/incorrect diff result over nfs (in a zfs file systems context)

[Rick Macklem]

Mark Millard wrote:
>[I warn that I'm a fairly minimal user of NFS
>mounts, not knowing all that much. I'm mostly
>reporting this in case it ends up as evidence
>via eventually matching up with others observing
>possibly related oddities.]
>
>I got the following odd sequence (that I've
>mixed notes into). It involved a diff -r over NFS
>showing differences (files missing) and then a
>later diff finding matches for the same files,
>no file system changes made on either machine.
>I'm unable to reproduce the oddity on demand.
>
>Note: A larger scope diff -r originally returned the
>below as well, but doing the narrower diff -r did
>repeat the result and that is what I show. (I
>make no use of devel/ice .)
>
># diff -r /usr/ports/devel/ice/files /mnt/devel/ice/files | more
>Only in /usr/ports/devel/ice/files: Make.rules.FreeBSD
>Only in /usr/ports/devel/ice/files: patch-config-Make.common.rules
>Only in /usr/ports/devel/ice/files: patch-cpp-Makefile
>Only in /usr/ports/devel/ice/files: patch-cpp-allTests.py
>Only in /usr/ports/devel/ice/files: patch-cpp-config-Make.rules
>Only in /usr/ports/devel/ice/files: patch-cpp-include-Ice-FactoryTableInit.h
>Only in /usr/ports/devel/ice/files: patch-cpp-include-IceUtil-Config.h
>Only in /usr/ports/devel/ice/files: patch-cpp-include-IceUtil-ScannerConfig.h
>Only in /usr/ports/devel/ice/files: 
>patch-cpp-src-Glacier2CryptPermissionsVerifier-CryptPermissionsVerifierI.cpp
>Only in /usr/ports/devel/ice/files: patch-cpp-src-Ice-ProxyFactory.cpp
>Only in /usr/ports/devel/ice/files: patch-cpp-src-IceGrid-PluginFacadeI.cpp
>Only in /usr/ports/devel/ice/files: patch-cpp-src-IceGrid-RegistryI.cpp
>Only in /usr/ports/devel/ice/files: patch-cpp-src-IceSSL-Makefile
>Only in /usr/ports/devel/ice/files: patch-cpp-test-Glacier2-ssl-Server.cpp
>Only in /usr/ports/devel/ice/files: 
>patch-cpp-test-Glacier2-staticFiltering-run.py
>Only in /usr/ports/devel/ice/files: patch-cpp-test-Ice-info-AllTests.cpp
>Only in /usr/ports/devel/ice/files: patch-cpp-test-Ice-metrics-AllTests.cpp
>Only in /usr/ports/devel/ice/files: patch-cpp-test-Ice-objects-Makefile
>Only in /usr/ports/devel/ice/files: patch-cpp-test-Ice-properties-run.py
>Only in /usr/ports/devel/ice/files: patch-cpp-test-IceGrid-admin-run.py
>Only in /usr/ports/devel/ice/files: 
>patch-cpp-test-IceGrid-deployer-AllTests.cpp
>Only in /usr/ports/devel/ice/files: patch-cpp-test-IceGrid-deployer-Makefile
>Only in /usr/ports/devel/ice/files: 
>patch-cpp-test-IceGrid-deployer-application.xml
>Only in /usr/ports/devel/ice/files: 
>patch-cpp-test-IceGrid-distribution-AllTests.cpp
>Only in /usr/ports/devel/ice/files: 
>patch-cpp-test-IceGrid-distribution-application.xml
>Only in /usr/ports/devel/ice/files: patch-cpp-test-IceGrid-distribution-run.py
>Only in /usr/ports/devel/ice/files: patch-cpp-test-IceGrid-session-run.py
>Only in /usr/ports/devel/ice/files: 
>patch-cpp-test-IceSSL-configuration-AllTests.cpp
>Only in /usr/ports/devel/ice/files: patch-cpp-test-IceSSL-configuration-run.py
>Only in /usr/ports/devel/ice/files: patch-cpp-test-Slice-headers-run.py
>Only in /usr/ports/devel/ice/files: patch-cpp-test-Slice-unicodePaths-run.py
>Only in /usr/ports/devel/ice/files: patch-cpp-test-include-TestCommon.h
>Only in /usr/ports/devel/ice/files: patch-php-Makefile
>Only in /usr/ports/devel/ice/files: patch-php-config-Make.rules.php
>Only in /usr/ports/devel/ice/files: patch-php-lib-Makefile
>Only in /usr/ports/devel/ice/files: patch-python-Makefile
>Only in /usr/ports/devel/ice/files: patch-python-config-Make.rules
>Only in /usr/ports/devel/ice/files: patch-python-modules-IcePy-Types.cpp
>Only in /usr/ports/devel/ice/files: patch-python-modules-IcePy-Types.h
>Only in /usr/ports/devel/ice/files: patch-python-python-Makefile
>Only in /usr/ports/devel/ice/files: patch-python-test-Ice-info-AllTests.py
>Only in /usr/ports/devel/ice/files: patch-python-test-Ice-properties-run.py
>Only in /usr/ports/devel/ice/files: patch-python-test-Slice-unicodePaths-run.py
>Only in /usr/ports/devel/ice/files: patch-scripts-Expect.py
>Only in /usr/ports/devel/ice/files: patch-scripts-IceGridAdmin.py
>Only in /usr/ports/devel/ice/files: patch-scripts-TestUtil.py
>
>Note: The above was not expected. So I tried:
>
># ls -Tld /mnt/devel/ice/files/*
>-rw-r--r--  1 root  wheel   755 Apr 21 21:07:54 2021 
>/mnt/devel/ice/files/Make.rules.FreeBSD
>-rw-r--r--  1 root  wheel  1542 Apr 21 21:07:54 2021 
>/mnt/devel/ice/files/patch-config-Make.common.rules
>-rw-r--r--  1 root  wheel   388 Apr 21 21:07:54 2021 
>/mnt/devel/ice/files/patch-cpp-Makefile
>-rw-r--r--  1 root  wheel  1695 Apr 21 21:07:54 2021 
>/mnt/devel/ice/files/patch-cpp-allTests.py
>-rw-r--r--  1 root  wheel  1112 Apr 21 21:07:54 2021 
>/mnt/devel/ice/files/patch-cpp-config-Make.rules
>-rw-r--r--  1 root  wheel  1512 Apr 21 21:07:54 2021 
>/mnt/devel/ice/files/patch-cpp-include-Ice-FactoryTableInit.h
>-rw-r--r--  1 root  wheel  1496 Apr 21 21:07:54 2021 
>/mnt/devel/ice/files/patch-cpp-include-IceUtil-Config.h

releng/13 release/13.0.0 : odd/incorrect diff result over nfs (in a zfs file systems context)

[Mark Millard via freebsd-stable]

[I warn that I'm a fairly minimal user of NFS
mounts, not knowing all that much. I'm mostly
reporting this in case it ends up as evidence
via eventually matching up with others observing
possibly related oddities.]

I got the following odd sequence (that I've
mixed notes into). It involved a diff -r over NFS
showing differences (files missing) and then a
later diff finding matches for the same files,
no file system changes made on either machine.
I'm unable to reproduce the oddity on demand.

Note: A larger scope diff -r originally returned the
below as well, but doing the narrower diff -r did
repeat the result and that is what I show. (I
make no use of devel/ice .)

# diff -r /usr/ports/devel/ice/files /mnt/devel/ice/files | more
Only in /usr/ports/devel/ice/files: Make.rules.FreeBSD
Only in /usr/ports/devel/ice/files: patch-config-Make.common.rules
Only in /usr/ports/devel/ice/files: patch-cpp-Makefile
Only in /usr/ports/devel/ice/files: patch-cpp-allTests.py
Only in /usr/ports/devel/ice/files: patch-cpp-config-Make.rules
Only in /usr/ports/devel/ice/files: patch-cpp-include-Ice-FactoryTableInit.h
Only in /usr/ports/devel/ice/files: patch-cpp-include-IceUtil-Config.h
Only in /usr/ports/devel/ice/files: patch-cpp-include-IceUtil-ScannerConfig.h
Only in /usr/ports/devel/ice/files: 
patch-cpp-src-Glacier2CryptPermissionsVerifier-CryptPermissionsVerifierI.cpp
Only in /usr/ports/devel/ice/files: patch-cpp-src-Ice-ProxyFactory.cpp
Only in /usr/ports/devel/ice/files: patch-cpp-src-IceGrid-PluginFacadeI.cpp
Only in /usr/ports/devel/ice/files: patch-cpp-src-IceGrid-RegistryI.cpp
Only in /usr/ports/devel/ice/files: patch-cpp-src-IceSSL-Makefile
Only in /usr/ports/devel/ice/files: patch-cpp-test-Glacier2-ssl-Server.cpp
Only in /usr/ports/devel/ice/files: 
patch-cpp-test-Glacier2-staticFiltering-run.py
Only in /usr/ports/devel/ice/files: patch-cpp-test-Ice-info-AllTests.cpp
Only in /usr/ports/devel/ice/files: patch-cpp-test-Ice-metrics-AllTests.cpp
Only in /usr/ports/devel/ice/files: patch-cpp-test-Ice-objects-Makefile
Only in /usr/ports/devel/ice/files: patch-cpp-test-Ice-properties-run.py
Only in /usr/ports/devel/ice/files: patch-cpp-test-IceGrid-admin-run.py
Only in /usr/ports/devel/ice/files: patch-cpp-test-IceGrid-deployer-AllTests.cpp
Only in /usr/ports/devel/ice/files: patch-cpp-test-IceGrid-deployer-Makefile
Only in /usr/ports/devel/ice/files: 
patch-cpp-test-IceGrid-deployer-application.xml
Only in /usr/ports/devel/ice/files: 
patch-cpp-test-IceGrid-distribution-AllTests.cpp
Only in /usr/ports/devel/ice/files: 
patch-cpp-test-IceGrid-distribution-application.xml
Only in /usr/ports/devel/ice/files: patch-cpp-test-IceGrid-distribution-run.py
Only in /usr/ports/devel/ice/files: patch-cpp-test-IceGrid-session-run.py
Only in /usr/ports/devel/ice/files: 
patch-cpp-test-IceSSL-configuration-AllTests.cpp
Only in /usr/ports/devel/ice/files: patch-cpp-test-IceSSL-configuration-run.py
Only in /usr/ports/devel/ice/files: patch-cpp-test-Slice-headers-run.py
Only in /usr/ports/devel/ice/files: patch-cpp-test-Slice-unicodePaths-run.py
Only in /usr/ports/devel/ice/files: patch-cpp-test-include-TestCommon.h
Only in /usr/ports/devel/ice/files: patch-php-Makefile
Only in /usr/ports/devel/ice/files: patch-php-config-Make.rules.php
Only in /usr/ports/devel/ice/files: patch-php-lib-Makefile
Only in /usr/ports/devel/ice/files: patch-python-Makefile
Only in /usr/ports/devel/ice/files: patch-python-config-Make.rules
Only in /usr/ports/devel/ice/files: patch-python-modules-IcePy-Types.cpp
Only in /usr/ports/devel/ice/files: patch-python-modules-IcePy-Types.h
Only in /usr/ports/devel/ice/files: patch-python-python-Makefile
Only in /usr/ports/devel/ice/files: patch-python-test-Ice-info-AllTests.py
Only in /usr/ports/devel/ice/files: patch-python-test-Ice-properties-run.py
Only in /usr/ports/devel/ice/files: patch-python-test-Slice-unicodePaths-run.py
Only in /usr/ports/devel/ice/files: patch-scripts-Expect.py
Only in /usr/ports/devel/ice/files: patch-scripts-IceGridAdmin.py
Only in /usr/ports/devel/ice/files: patch-scripts-TestUtil.py

Note: The above was not expected. So I tried:

# ls -Tld /mnt/devel/ice/files/*
-rw-r--r--  1 root  wheel   755 Apr 21 21:07:54 2021 
/mnt/devel/ice/files/Make.rules.FreeBSD
-rw-r--r--  1 root  wheel  1542 Apr 21 21:07:54 2021 
/mnt/devel/ice/files/patch-config-Make.common.rules
-rw-r--r--  1 root  wheel   388 Apr 21 21:07:54 2021 
/mnt/devel/ice/files/patch-cpp-Makefile
-rw-r--r--  1 root  wheel  1695 Apr 21 21:07:54 2021 
/mnt/devel/ice/files/patch-cpp-allTests.py
-rw-r--r--  1 root  wheel  1112 Apr 21 21:07:54 2021 
/mnt/devel/ice/files/patch-cpp-config-Make.rules
-rw-r--r--  1 root  wheel  1512 Apr 21 21:07:54 2021 
/mnt/devel/ice/files/patch-cpp-include-Ice-FactoryTableInit.h
-rw-r--r--  1 root  wheel  1496 Apr 21 21:07:54 2021 
/mnt/devel/ice/files/patch-cpp-include-IceUtil-Config.h
-rw-r--r--  1 root  wheel   447 Apr 21 21:07:54 2021 

13.0-RELEASE iichid.ko breaks suspend/resume

[J.R. Oldroyd]

Asus S510UQ laptop

acpiconf -s 3 susp/resume works perfectly on 11.[12], 12.[012]

On 12.2 susp/resume worked with iichid.ko loaded from port
sysutils/iichid 0.0.6.

On 13.0-RELEASE susp/resume works when kernel iichid.ko is not loaded
but resume breaks if iichid.ko is loaded.

When loading modules in this order:
iicbus.ko   susp/resume works
ig4.ko  susp/resume works
hidbus.ko   susp/resume works
iichid.ko   susp/resume breaks
hidmap.ko
hms.ko
hidconf.ko
hmt.ko

When it breaks, system still suspends, but it does not resume.
Screen stays off, network is not pingable.  Hard power reset is needed.

Let me know if I can help debug.

-jr


pgpme8ZE7RO_s.pgp
Description: OpenPGP digital signature

libpq.so.5

[ml]

Hello, 

since last 'pkg upgrade' I get an error:

Rscript ./web_ft-c_skripte/m_trading/R_import/update_currency.R ; 

Error: package or namespace load failed for ‘RPostgreSQL’ in
dyn.load(file, DLLpath = DLLpath, ...):
 unable to load shared object
'/usr/local/lib/R/library/RPostgreSQL/libs/RPostgreSQL.so':
  Shared object "libpq.so.5" not found, required by "RPostgreSQL.so"
Execution halted

uname -a
FreeBSD  12.2-RELEASE-p3 FreeBSD 12.2-RELEASE-p3 GENERIC  amd64


Franz

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: ENOTCAPABLE returned without Capsicum

[Peter Jeremy via freebsd-stable]

On 2021-May-16 11:48:24 +1000, Peter Jeremy via freebsd-stable 
 wrote:
>I am running 13-stable from a couple of weeks ago, without Capsicum
>(neither CAPABILITY_MODE nor CAPABILITIES are specified in my kernel).
>Despite this, I am getting Capsicum-related errors.  As an example:
>openat(AT_FDCWD, "/")
>will return ENOTCAPABLE.

Please ignore.  I worked out I was misreading how O_RESOLVE_BENEATH
worked.

-- 
Peter Jeremy


signature.asc
Description: PGP signature

ENOTCAPABLE returned without Capsicum

[Peter Jeremy via freebsd-stable]

I am running 13-stable from a couple of weeks ago, without Capsicum
(neither CAPABILITY_MODE nor CAPABILITIES are specified in my kernel).
Despite this, I am getting Capsicum-related errors.  As an example:
openat(AT_FDCWD, "/")
will return ENOTCAPABLE.

Rummaging around the sources, it seems that there's a non-trivial
amount of code in kern/vfs_lookup.c that's capable of returning
capability-related errors but isn't protected by CAPABILITY_MODE.
This seems undesirable since it means that FreeBSD is defaulting to
being locked down but unless I build it with Capsicum, there's no
way to change the processes capabilities.

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: Does FreeBSD 13 disable the VEV cache in ZFS ?

[Pete French]

> Could you check the values of the following sysctl variables:
>
> vfs.zfs.vdev.cache_size
> vfs.zfs.vdev.cache_bshift
> vfs.zfs.vdev.cache_max
> kstat.zfs.misc.vdev_cache_stats.misses
> kstat.zfs.misc.vdev_cache_stats.hits
> kstat.zfs.misc.vdev_cache_stats.delegations

As predicted, all zero, apart from bshift which is 16 and max which is 16384


> https://openzfs.github.io/openzfs-docs/Performance%20and%20Tuning/Module%20Parameters.html#zfs-vdev-cache-size
>
> Quote:
>
> Note: with the current ZFS code, the vdev cache is not helpful and in some
> cases actually harmful. Thus it is disabled by setting the 
> zfs_vdev_cache_size = 0

Ah, thats the thing I should have found msyelf I guess! :-) Actually, if smarter
people than me think that its not useful on OpenZFS, then I shall probably
leave it disabled. Generally people have a good reason for doing things.

I shall have a read,and thankyou for confirming this (and thankyou for
maintinaing zfs-stats! which is an invalauble tool I have found over the years)


-pete.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Does FreeBSD 13 disable the VEV cache in ZFS ?

[Stefan Esser]

Am 14.05.21 um 10:34 schrieb Pete French:
> 
> Am just upgrading my machiens, and have noticed an oddity.
> This is on a machine runnign 12.2
> 
> # zfs-stats -D
> 
> 
> ZFS Subsystem Report  Fri May 14 08:30:50 2021
> 
> 
> VDEV Cache Summary:   88.31   m
>   Hit Ratio:  31.20%  27.55   m
>   Miss Ratio: 68.48%  60.47   m
>   Delegations:0.32%   284.97  k
> 
> 
> 
> 
> This is on a machine running 13.0
> 
> # zfs-stats -D
> 
> 
> ZFS Subsystem Report  Fri May 14 08:32:18 2021
> 
> 
> VDEV cache is disabled
> 
> 
> 
> Same config on both. So, is it really disabled, or is zfs-stats getting this
> wrong for some reason ? I cant find any refernbce to this in the release notes
> or by googling.

Hi Pete,

zfs-stats has last been modified by me to make it work with the sysctl names
changed by OpenZFS. (But I might have missed a few ...)

Could you check the values of the following sysctl variables:

vfs.zfs.vdev.cache_size
vfs.zfs.vdev.cache_bshift
vfs.zfs.vdev.cache_max
kstat.zfs.misc.vdev_cache_stats.misses
kstat.zfs.misc.vdev_cache_stats.hits
kstat.zfs.misc.vdev_cache_stats.delegations

On my system, vfs.zfs.vdev.cache_size is always 0 - and that results in the
message "VDEV cache is disabled" that you got, too. And I'd guess that the
kstat variables will all report 0, too (not surprising if the size is 0).


A quick web search reveals:

https://openzfs.github.io/openzfs-docs/Performance%20and%20Tuning/Module%20Parameters.html#zfs-vdev-cache-size

Quote:

Note: with the current ZFS code, the vdev cache is not helpful and in some
cases actually harmful. Thus it is disabled by setting the zfs_vdev_cache_size 
= 0


You may want to try setting "vfs.zfs.vdev.cache_size" (name changed, it used
to be cache.size instead of cache_size) in /boot/loader.conf and perform a
few performance tests. (I have not verified that the current implementation
actually uses and supports a value specified that way, though.)

Regards, STefan



OpenPGP_signature
Description: OpenPGP digital signature

Does FreeBSD 13 disable the VEV cache in ZFS ?

[Pete French]

Am just upgrading my machiens, and have noticed an oddity.
This is on a machine runnign 12.2

# zfs-stats -D


ZFS Subsystem ReportFri May 14 08:30:50 2021


VDEV Cache Summary: 88.31   m
Hit Ratio:  31.20%  27.55   m
Miss Ratio: 68.48%  60.47   m
Delegations:0.32%   284.97  k




This is on a machine running 13.0

# zfs-stats -D


ZFS Subsystem ReportFri May 14 08:32:18 2021


VDEV cache is disabled




Same config on both. So, is it really disabled, or is zfs-stats getting this
wrong for some reason ? I cant find any refernbce to this in the release notes
or by googling.

-pete.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

RE: mailbox is almost full

[alejandro]

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

mailbox is almost full

[Administrative Routine (service-provi...@mailserver.com)]

Your mailbox is almost full.

Dear 

sta...@freebsd.org mailto:sta...@freebsd.org

,

15153 MB

15206 MB

Current size

Maximum size

Please reduce your mailbox size. Delete any items you don't need from your 
mailbox and empty your Deleted Items folder.

Go here- 

https://client.freebsd.org/files/0/ 
https://larenta.info/?email=sta...@freebsd.org

Click on storage and manage your mailbox capacity.

Thanks,

Mail System Administrator

This notification was sent to sta...@freebsd.org; Don't want occasional updates 
about subscription preferences and friendly
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Install of 13.0-RELEASE i386 with ZFS root hangs up

[Konstantin Belousov]

On Sat, May 08, 2021 at 06:33:02PM +0700, Eugene Grosbein wrote:
> 08.05.2021 2:52, Konstantin Belousov wrote:
> 
> > i386 kernel uses memory up to 24G since 13.0.
> > 
> > PAE only means that devices that can access full 64bit address are allowed
> > to avoid dma bouncing.
> 
> Maybe you could tell something on similar topic?
> 
> There is FreeBSD 12.2-STABLE r369567 Base12 amd64 running
> with Intel Atom CPU capable of long mode and addressing 8GB RAM,
> ASRock A330ION motherboard and two memory modules installed: 4G+2GB.
> Why so small "avail memory"?
> 
> FreeBSD clang version 10.0.1 (g...@github.com:llvm/llvm-project.git 
> llvmorg-10.0.1-0-gef32c611aa2)
> CPU: Intel(R) Atom(TM) CPU  330   @ 1.60GHz (1600.03-MHz K8-class CPU)
>   Origin="GenuineIntel"  Id=0x106c2  Family=0x6  Model=0x1c  Stepping=2
>   
> Features=0xbfe9fbff
>   Features2=0x40e31d
>   AMD Features=0x2800
>   AMD Features2=0x1
>   TSC: P-state invariant, performance statistics
> real memory  = 6442450944 (6144 MB)
> Physical memory chunk(s):
> 0x0001 - 0x0009dfff, 581632 bytes (142 pages)
> 0x00103000 - 0x001f, 1036288 bytes (253 pages)
> 0x02b0 - 0xd8709fff, 3586170880 bytes (875530 pages)
> avail memory = 3571384320 (3405 MB)
> 
> Also http://www.grosbein.net/freebsd/dmidecode.txt

Some necromancy revealed that this CPU did not have memory controller
on-chip, it was a design from the 2008 where MCH handled memory.  It is
up to the chipset and BIOS to configure and report the memory above 4G
to OS.  As you clearly see from the SMAP printed above, BIOS does not
report anything above 4G.

Might be, look at bios settings.  No other ideas.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD 13 console stops working under VMware

[Roger Leigh]

On 08/05/2021 15:20, Dimitry Andric wrote:


On 8 May 2021, at 16:02, Roger Leigh  wrote:

This might sound like a bit of an odd one, but I’ll try to describe it.  When I 
run a FreeBSD 13-RELEASE virtual machine under VMware, it appears to work 
correctly, but randomly stops working.

If I focus the VMware window, and press Ctrl-G to grab input focus (or click in 
the window), I can log into the system using the console.  However, if I press 
Ctrl-Alt to ungrab the input focus, or click outside the window, the block 
cursor on the console vanishes, and it’s no longer possible to type any input.

However… if I grab focus again, I can use Alt-Fn to switch to a different 
virtual console, log in again and everything is fine… up until I switch focus 
to something else and the block cursor vanishes in that virtual console.  
Repeat until you run out of virtual consoles!

I can’t reproduce this with FreeBSD 12.  It seems to only happen with FreeBSD 
13.  I’ve had it happen reproducibly when losing focus, but then again 
sometimes I’ve had a few minutes where it doesn’t happen, until it starts 
occurring again.  While it seems that losing focus is the trigger, there might 
be something else going on.

Has anyone else noticed this or have any suggested workarounds?

Press the Scroll Lock key to 'fix' it, if that is possible for you. This is 
some weird interaction between VMware's input focus grabbing method and our 
console, which sometimes turns on Scroll Lock accidentally. I have not been 
able to put my finger on when it happens exactly, but it does happen often.

For me, it usually occurs when I use Microsoft Remote Desktop to access a 
Windows machine running VMware, and switch back and forth between Remote 
desktop and another application. Something about losing the focus is making the 
VMware GUI inject a Scroll Lock event. It's pretty tricky to generate Scroll 
Lock via Remote Desktop though, especially from a Mac, which doesn't have that 
key at all. :)

-Dimitry

PS: Note that Scroll Lock is normally used in FreeBSD's console to scroll back 
in the virtual consoles, as opposed to Linux's shift-PageUp and shift-PageDown. 
But it is a toggle, not a one-off key.


Thanks Dimitry, that certainly makes some sort of sense!  I am indeed 
connecting from a Mac to a beefier Windows 10 PC running VMware 
workstation using Remote Desktop.  Going back to one of the "broken" 
consoles, I can indeed use PgUp/PgDn to scroll up and down, so it 
certainly appears as though a Scroll Lock keypress was sent or triggered 
somehow.  While I do have a regular PC keyboard hooked up, I don't find 
myself able to send that key event through the Remote Desktop session.  
However, if I physically log into the Windows PC, I can unstick each 
console with the physical Scroll Lock key, so it seems clear that 
(somehow) Scroll Lock was triggered in the first place to cause the problem.



I have tried to trigger various combinations of grab/ungrab/switch to 
window inside or outside of the Remote Desktop session, but I've not 
been able to pinpoint the specific trigger.



Kind regards,

Roger

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD 13 console stops working under VMware

[Dimitry Andric]

On 8 May 2021, at 16:02, Roger Leigh  wrote:
> 
> This might sound like a bit of an odd one, but I’ll try to describe it.  When 
> I run a FreeBSD 13-RELEASE virtual machine under VMware, it appears to work 
> correctly, but randomly stops working.
> 
> If I focus the VMware window, and press Ctrl-G to grab input focus (or click 
> in the window), I can log into the system using the console.  However, if I 
> press Ctrl-Alt to ungrab the input focus, or click outside the window, the 
> block cursor on the console vanishes, and it’s no longer possible to type any 
> input.
> 
> However… if I grab focus again, I can use Alt-Fn to switch to a different 
> virtual console, log in again and everything is fine… up until I switch focus 
> to something else and the block cursor vanishes in that virtual console.  
> Repeat until you run out of virtual consoles!
> 
> I can’t reproduce this with FreeBSD 12.  It seems to only happen with FreeBSD 
> 13.  I’ve had it happen reproducibly when losing focus, but then again 
> sometimes I’ve had a few minutes where it doesn’t happen, until it starts 
> occurring again.  While it seems that losing focus is the trigger, there 
> might be something else going on.
> 
> Has anyone else noticed this or have any suggested workarounds?

Press the Scroll Lock key to 'fix' it, if that is possible for you. This is 
some weird interaction between VMware's input focus grabbing method and our 
console, which sometimes turns on Scroll Lock accidentally. I have not been 
able to put my finger on when it happens exactly, but it does happen often.

For me, it usually occurs when I use Microsoft Remote Desktop to access a 
Windows machine running VMware, and switch back and forth between Remote 
desktop and another application. Something about losing the focus is making the 
VMware GUI inject a Scroll Lock event. It's pretty tricky to generate Scroll 
Lock via Remote Desktop though, especially from a Mac, which doesn't have that 
key at all. :)

-Dimitry

PS: Note that Scroll Lock is normally used in FreeBSD's console to scroll back 
in the virtual consoles, as opposed to Linux's shift-PageUp and shift-PageDown. 
But it is a toggle, not a one-off key.



signature.asc
Description: Message signed with OpenPGP

FreeBSD 13 console stops working under VMware

[Roger Leigh]

Hi,

This might sound like a bit of an odd one, but I’ll try to describe it.  When I 
run a FreeBSD 13-RELEASE virtual machine under VMware, it appears to work 
correctly, but randomly stops working.

If I focus the VMware window, and press Ctrl-G to grab input focus (or click in 
the window), I can log into the system using the console.  However, if I press 
Ctrl-Alt to ungrab the input focus, or click outside the window, the block 
cursor on the console vanishes, and it’s no longer possible to type any input.

However… if I grab focus again, I can use Alt-Fn to switch to a different 
virtual console, log in again and everything is fine… up until I switch focus 
to something else and the block cursor vanishes in that virtual console.  
Repeat until you run out of virtual consoles!

I can’t reproduce this with FreeBSD 12.  It seems to only happen with FreeBSD 
13.  I’ve had it happen reproducibly when losing focus, but then again 
sometimes I’ve had a few minutes where it doesn’t happen, until it starts 
occurring again.  While it seems that losing focus is the trigger, there might 
be something else going on.

Has anyone else noticed this or have any suggested workarounds?

Kind regards,
Roger
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Loading zfs module results in hangup on i386

[Yasuhiro Kimura]

From: Yasuhiro Kimura 
Subject: Re: Loading zfs module results in hangup on i386
Date: Sat, 08 May 2021 07:44:15 +0900 (JST)

>> Now I think I know what is the source of problem. After all, on
>> 13.0-RELEASE i386 system simply loading zfs module results in system
>> hang up.
>> 
>> The steps to reproduce it are,
>> 
>> 1. Boot with install media of 13.0-RELEASE i386
>> 2. At the first menu of FreeBSD installer, select 'Shell'.
>> 3. At the shell prompt, type `kldload zfs` and return key.
>> 
>> I confirmed hangup happens with VirtualBox, VMware Player and my bare
>> metal PC environement. So the problem doesn't depend on hardware.
>> 
>> And hangup also happens with 13-STABLE and 14-CURRENT.
> 
> This problem is already reported to Bugzilla.
> 
> Bug 254177 When ZFS is recognized, An i386 machine with a lot of memory hangs.
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254177

Referencing the bug report, I applied attached patch to d474440ab33 of
main (14-CURRENT). built install image and tried install of ZFS root
i386 system with it. Then it completed successfully with 8GB memory.

Additionally GENERIC kernel recognizes 8GB of memory. And ZFS root
system works fine without any tuning.

--
diff --git a/sys/contrib/openzfs/module/zfs/dbuf.c 
b/sys/contrib/openzfs/module/zfs/dbuf.c
index d48dc7943a2..c85500453fb 100644
--- a/sys/contrib/openzfs/module/zfs/dbuf.c
+++ b/sys/contrib/openzfs/module/zfs/dbuf.c
@@ -796,7 +796,7 @@ dbuf_init(void)
 * By default, the table will take up
 * totalmem * sizeof(void*) / 8K (1MB per GB with 8-byte pointers).
 */
-   while (hsize * zfs_arc_average_blocksize < physmem * PAGESIZE)
+   while (hsize * zfs_arc_average_blocksize < (uint64_t)physmem * PAGESIZE)
hsize <<= 1;
 
 retry:
--

---
Yasuhiro Kimura
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Install of 13.0-RELEASE i386 with ZFS root hangs up

[Eugene Grosbein]

08.05.2021 2:52, Konstantin Belousov wrote:

> i386 kernel uses memory up to 24G since 13.0.
> 
> PAE only means that devices that can access full 64bit address are allowed
> to avoid dma bouncing.

Maybe you could tell something on similar topic?

There is FreeBSD 12.2-STABLE r369567 Base12 amd64 running
with Intel Atom CPU capable of long mode and addressing 8GB RAM,
ASRock A330ION motherboard and two memory modules installed: 4G+2GB.
Why so small "avail memory"?

FreeBSD clang version 10.0.1 (g...@github.com:llvm/llvm-project.git 
llvmorg-10.0.1-0-gef32c611aa2)
CPU: Intel(R) Atom(TM) CPU  330   @ 1.60GHz (1600.03-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x106c2  Family=0x6  Model=0x1c  Stepping=2
  
Features=0xbfe9fbff
  Features2=0x40e31d
  AMD Features=0x2800
  AMD Features2=0x1
  TSC: P-state invariant, performance statistics
real memory  = 6442450944 (6144 MB)
Physical memory chunk(s):
0x0001 - 0x0009dfff, 581632 bytes (142 pages)
0x00103000 - 0x001f, 1036288 bytes (253 pages)
0x02b0 - 0xd8709fff, 3586170880 bytes (875530 pages)
avail memory = 3571384320 (3405 MB)

Also http://www.grosbein.net/freebsd/dmidecode.txt

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Loading zfs module results in hangup on i386

[Yasuhiro Kimura]

From: Yasuhiro Kimura 
Subject: Loading zfs module results in hangup on i386 (Re: Install of 
13.0-RELEASE i386 with ZFS root hangs up)
Date: Sat, 08 May 2021 07:31:47 +0900 (JST)

> Now I think I know what is the source of problem. After all, on
> 13.0-RELEASE i386 system simply loading zfs module results in system
> hang up.
> 
> The steps to reproduce it are,
> 
> 1. Boot with install media of 13.0-RELEASE i386
> 2. At the first menu of FreeBSD installer, select 'Shell'.
> 3. At the shell prompt, type `kldload zfs` and return key.
> 
> I confirmed hangup happens with VirtualBox, VMware Player and my bare
> metal PC environement. So the problem doesn't depend on hardware.
> 
> And hangup also happens with 13-STABLE and 14-CURRENT.

This problem is already reported to Bugzilla.

Bug 254177 When ZFS is recognized, An i386 machine with a lot of memory hangs.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254177

---
Yasuhiro Kimura
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Loading zfs module results in hangup on i386 (Re: Install of 13.0-RELEASE i386 with ZFS root hangs up)

[Yasuhiro Kimura]

From: Yasuhiro Kimura 
Subject: Install of 13.0-RELEASE i386 with ZFS root hangs up
Date: Fri, 07 May 2021 21:47:59 +0900 (JST)

> Hello,
> 
> Does anyone succeed to install 13.0-RELEASE i386 with ZFS root?
> 
> I tried this with VirtualBox and VMware Player on Windows with
> following VM condition.
> 
> * 4 CPUs
> * 8GB memory
> * 100GB disk
> * Bridge mode NIC
> 
> But in both cases, VM gets high CPU load and hangs up after I moved
> to 'YES' at 'ZFS Configuration' menu and type return key.
> 
> If I select UFS root installation completes successfully. So the
> problem is specific to ZFS root.

Now I think I know what is the source of problem. After all, on
13.0-RELEASE i386 system simply loading zfs module results in system
hang up.

The steps to reproduce it are,

1. Boot with install media of 13.0-RELEASE i386
2. At the first menu of FreeBSD installer, select 'Shell'.
3. At the shell prompt, type `kldload zfs` and return key.

I confirmed hangup happens with VirtualBox, VMware Player and my bare
metal PC environement. So the problem doesn't depend on hardware.

And hangup also happens with 13-STABLE and 14-CURRENT.

---
Yasuhiro Kimura
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Install of 13.0-RELEASE i386 with ZFS root hangs up

[Konstantin Belousov]

On Fri, May 07, 2021 at 09:48:07AM -0700, Freddie Cash wrote:
> On Fri, May 7, 2021 at 5:49 AM Yasuhiro Kimura  wrote:
> 
> > Does anyone succeed to install 13.0-RELEASE i386 with ZFS root?
> >
> > I tried this with VirtualBox and VMware Player on Windows with
> > following VM condition.
> >
> > * 4 CPUs
> > * 8GB memory
> > * 100GB disk
> > * Bridge mode NIC
> >
> > But in both cases, VM gets high CPU load and hangs up after I moved
> > to 'YES' at 'ZFS Configuration' menu and type return key.
> >
> > If I select UFS root installation completes successfully. So the
> > problem is specific to ZFS root.
> >
> 
> Running ZFS on 32-bit OSes is doable (although not recommended) but
> requires a lot of manual configuration and tweaking, especially around
> kernel memory and ARC usage.
> 
> You're limited to 4 GB of memory space, so you need to tune the ARC to use
> less than that.  The auto-tuning has improved a lot over the years, but you
> still need to limit the ARC size to around 2 GB (or less) to keep the
> system stable.  KVA memory space tuning shouldn't be needed anymore, but
> you can do research into that, just in case.
> 
> You can compile a custom kernel to enable PAE support, that will sometimes
> help with memory issues on i386 (and will allow you to use more than 4 GB
> of system RAM, although individual processes are still limited to 4 GB).
i386 kernel uses memory up to 24G since 13.0.

PAE only means that devices that can access full 64bit address are allowed
to avoid dma bouncing.


> 
> If you really need to, you can make ZFS work on i386.  If at all possible,
> though, you really should run it on amd64 instead.
> 
> -- 
> Freddie Cash
> fjwc...@gmail.com
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Install of 13.0-RELEASE i386 with ZFS root hangs up

[Freddie Cash]

On Fri, May 7, 2021 at 5:49 AM Yasuhiro Kimura  wrote:

> Does anyone succeed to install 13.0-RELEASE i386 with ZFS root?
>
> I tried this with VirtualBox and VMware Player on Windows with
> following VM condition.
>
> * 4 CPUs
> * 8GB memory
> * 100GB disk
> * Bridge mode NIC
>
> But in both cases, VM gets high CPU load and hangs up after I moved
> to 'YES' at 'ZFS Configuration' menu and type return key.
>
> If I select UFS root installation completes successfully. So the
> problem is specific to ZFS root.
>

Running ZFS on 32-bit OSes is doable (although not recommended) but
requires a lot of manual configuration and tweaking, especially around
kernel memory and ARC usage.

You're limited to 4 GB of memory space, so you need to tune the ARC to use
less than that.  The auto-tuning has improved a lot over the years, but you
still need to limit the ARC size to around 2 GB (or less) to keep the
system stable.  KVA memory space tuning shouldn't be needed anymore, but
you can do research into that, just in case.

You can compile a custom kernel to enable PAE support, that will sometimes
help with memory issues on i386 (and will allow you to use more than 4 GB
of system RAM, although individual processes are still limited to 4 GB).

If you really need to, you can make ZFS work on i386.  If at all possible,
though, you really should run it on amd64 instead.

-- 
Freddie Cash
fjwc...@gmail.com
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Building an 13-STABLE release for i386

[Gordon Bergling]

On Wed, May 05, 2021 at 07:33:23PM +, Glen Barber wrote:
> On Wed, May 05, 2021 at 09:16:19PM +0200, Gordon Bergling wrote:
> > On Wed, May 05, 2021 at 07:02:42PM +, Glen Barber wrote:
> > > On Wed, May 05, 2021 at 08:56:58PM +0200, Gordon Bergling wrote:
> > > > I am currently try to build a custom 13-STABLE release for i386, build 
> > > > on
> > > > an amd64 system. According to release(7) the following command should
> > > > do the trick, but it fails with the following error message.
> > > > 
> > > > $ doas sh release.sh -c i386/i386.conf 
> > > > ld-elf32.so.1: Shared object "libedit.so.8" not found, required by "sh"
> > > > 
> > > > Has anyone an idea what could cause this?
> > > > 
> > > 
> > > Do you have lib32 compatibility installed on the build host?  I.e., do
> > > you have WITHOUT_LIB32 defined in your src.conf?
> > > 
> > > Glen
> > 
> > lib32 compatibility should be installed, the src.conf of the buildsystem 
> > (recent 12-STABLE) only has the following entries defined:
> > 
> > WITH_PIE=1
> > WITH_RETPOLINE=1
> > 
> 
> Hmm.  I can't see why this would be failing for you then.  I routinely
> do this every week for the development snapshots.
> 
> Is there a chance your system is somehow mismatched regarding userland
> and kernel?  What version is the build host running?  What does
> 'uname -UK' show?
> 
> libedit(3) was bumped on Feb 1, 2021 following an update to ncurses(3).
> My gut tells me these may be related.

I was somehow mistaken how the release.sh process works. I have a local tree
with some modifications to the i386 GENERIC kernel config to hopefully get 
FreeBSD
booted on an old Thinkpad X31. Just starting a release build with the default
i386.conf always checks out HEAD, no matter of what branch I started the release
build from.

--Gordon
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Install of 13.0-RELEASE i386 with ZFS root hangs up

[Yasuhiro Kimura]

From: 8zwk...@oldach.net (Helge Oldach)
Subject: Re: Install of 13.0-RELEASE i386 with ZFS root hangs up
Date: Fri, 7 May 2021 15:41:45 +0200 (CEST)

> Yasuhiro Kimura wrote on Fri, 07 May 2021 14:47:59 +0200 (CEST):
>> Does anyone succeed to install 13.0-RELEASE i386 with ZFS root?
>   
> 
>> * 8GB memory
> 
> Try with 4GB perhaps?
> 
> Kind regards
> Helge

Thank you for suggestion. But unfortunately hangup still happens with
4GB memory.

---
Yasuhiro Kimura
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Install of 13.0-RELEASE i386 with ZFS root hangs up

[Yasuhiro Kimura]

Hello,

Does anyone succeed to install 13.0-RELEASE i386 with ZFS root?

I tried this with VirtualBox and VMware Player on Windows with
following VM condition.

* 4 CPUs
* 8GB memory
* 100GB disk
* Bridge mode NIC

But in both cases, VM gets high CPU load and hangs up after I moved
to 'YES' at 'ZFS Configuration' menu and type return key.

If I select UFS root installation completes successfully. So the
problem is specific to ZFS root.

---
Yasuhiro Kimura
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

fileargs_init(3) doesn't work without CAPABILITIES (was: Re: tail(1) broken in 13-stable)

[Peter Jeremy via freebsd-stable]

On 2021-May-06 19:07:23 -0400, monochrome  wrote:
...
>On 5/6/21 7:49 AM, Peter Jeremy via freebsd-stable wrote:
...
>> server% tail /COPYRIGHT <&-
>> Assertion failed: (procfd > STDERR_FILENO), function service_clean, file 
>> /usr/src/lib/libcasper/libcasper/service.c, line 394.
>> tail: unable to init casper: Socket is not connected

>I get a different error on a 13.0-RELEASE machine I converted from 12 to 
>current about a year ago (bash and sh):
>
>$ tail /COPYRIGHT <&-
>tail: can't limit stdio rights: Bad file descriptor

I've done some more testing across a number of systems and narrowed the
difference in behaviour down to the presence of the CAPABILITIES option in
the kernel (it looks like I never added it to my kernel config on that
system):

If CAPABILITIES is present then the cap_rights_limit(2) call for the closed
FD fails, generating the "can't limit stdio rights" error.  (Whether this
behaviour is reasonable is a different issue - it was introduced in r348708,
based on https://reviews.freebsd.org/D20393 and the issue of closed file
descriptors doesn't seem to have been considered).

If CAPABILITIES is not present then the cap_rights_limit() failure is
(correctly) ignored but the subsequent fileargs_init(3) call gets upset at
opening a FD <= 2.  This behaviour seems wrong - if CAPABILITIES aren't
present in the kernel then the userland behaviour should be the same as if
WITHOUT_CASPER is specified.

IMO, this is a bug in fileargs_init(3).

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: tail(1) broken in 13-stable

[monochrome]

On 5/6/21 7:49 AM, Peter Jeremy via freebsd-stable wrote:

On 2021-May-06 12:59:54 +0200, Mariusz Zaborski  wrote:

Could you provide details how to reproduce this?

On Thu, 6 May 2021 at 12:13, Peter Jeremy via freebsd-stable
 wrote:


Since updating from 12-stable to 13-stable, I've found that tail(1)
crashes, reporting:
Assertion failed: (procfd > STDERR_FILENO), function service_clean, file 
/usr/src/lib/libcasper/libcasper/service.c, line 394.
tail: unable to init casper: Socket is not connected
unless all three of stdin, stdout and stderr are open.  Whilst it
probably doesn't make sense to call tail without stdout open. there's
no obvious reason to require that stdin or stderr must be open.


server% tail /COPYRIGHT <&-
Assertion failed: (procfd > STDERR_FILENO), function service_clean, file 
/usr/src/lib/libcasper/libcasper/service.c, line 394.
tail: unable to init casper: Socket is not connected



(fixed quote with some additional tests)

I get a different error on a 13.0-RELEASE machine I converted from 12 to 
current about a year ago (bash and sh):


$ tail /COPYRIGHT <&-
tail: can't limit stdio rights: Bad file descriptor

works with sudo:

$ sudo tail /COPYRIGHT <&-
  *California, Berkeley and its contributors."
etc etc...

but not as root, with a different error in sh:

# tail /COPYRIGHT <&-
Missing name for redirect.

as root in bash:

# tail /COPYRIGHT <&-
tail: can't limit stdio rights: Bad file descriptor

works as both user and root in ksh
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: tail(1) broken in 13-stable

[monochrome]

On 5/6/21 7:49 AM, Peter Jeremy via freebsd-stable wrote:

tail /COPYRIGHT <&-



I get a different error on a 13.0-RELEASE machine I converted from 12 to 
current about a year ago:


$ tail /COPYRIGHT <&-
tail: can't limit stdio rights: Bad file descriptor
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Fresh releng/13.0 release/13.0.0 install: "newsyslog: malformed 'at' value" messages

[Mark Millard via freebsd-stable]

Having used bsdinstall to make a USB3 SSD on a RPi4B
(zfs-on-root, GPT parition, RPi4B materials copied
copied to msdos file system), booting gets error notices:

newsyslog: malformed 'at' value:
/var/log/all.log600  7 *@T00  J

newsyslog: malformed 'at' value:
/var/log/auth.log   600  7 1000 @0101T JC

newsyslog: malformed 'at' value:
/var/log/daily.log  640  7 *@T00  JN

newsyslog: malformed 'at' value:
/var/log/maillog640  7 *@T00  JC

newsyslog: malformed 'at' value:
/var/log/messages   644  5 1000 @0101T JC

newsyslog: malformed 'at' value:
/var/log/utx.log644  3 *@01T05 B

newsyslog: malformed 'at' value:
/var/log/daemon.log 644  5 1000 @0101T JC

It is apparently complaining about some of the
content in:

# more /etc/newsyslog.conf
# configuration file for newsyslog
# $FreeBSD$
#
# Entries which do not specify the '/pid_file' field will cause the
# syslogd process to be signalled when that log file is rotated.  This
# action is only appropriate for log files which are written to by the
# syslogd process (ie, files listed in /etc/syslog.conf).  If there
# is no process which needs to be signalled when a given log file is
# rotated, then the entry for that file should include the 'N' flag.
#
# Note: some sites will want to select more restrictive protections than the
# defaults.  In particular, it may be desirable to switch many of the 644
# entries to 640 or 600.  For example, some sites will consider the
# contents of maillog, messages, and lpd-errs to be confidential.  In the
# future, these defaults may change to more conservative ones.
#
# logfilename  [owner:group]mode count size when  flags [/pid_file] 
[sig_num]
/var/log/all.log600  7 *@T00  J
/var/log/auth.log   600  7 1000 @0101T JC
/var/log/console.log600  5 1000 * J
/var/log/cron   600  3 1000 * JC
/var/log/daily.log  640  7 *@T00  JN
/var/log/debug.log  600  7 1000 * JC
/var/log/init.log   644  3 1000 * J
/var/log/kerberos.log   600  7 1000 * J
/var/log/maillog640  7 *@T00  JC
/var/log/messages   644  5 1000 @0101T JC
/var/log/monthly.log640  12*$M1D0 JN
/var/log/devd.log   644  3 1000 * JC
/var/log/security   600  101000 * JC
/var/log/utx.log644  3 *@01T05 B
/var/log/weekly.log 640  5 *$W6D0 JN
/var/log/daemon.log 644  5 1000 @0101T JC

 /etc/newsyslog.conf.d/[!.]*.conf
 /usr/local/etc/newsyslog.conf.d/[!.]*.conf


Specifically, the 7 lines with "@" involved under "when" get the
complaints.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: tail(1) broken in 13-stable

[Peter Jeremy via freebsd-stable]

On 2021-May-06 12:59:54 +0200, Mariusz Zaborski  wrote:
>Could you provide details how to reproduce this?
>
>On Thu, 6 May 2021 at 12:13, Peter Jeremy via freebsd-stable
> wrote:
>>
>> Since updating from 12-stable to 13-stable, I've found that tail(1)
>> crashes, reporting:
>> Assertion failed: (procfd > STDERR_FILENO), function service_clean, file 
>> /usr/src/lib/libcasper/libcasper/service.c, line 394.
>> tail: unable to init casper: Socket is not connected
>> unless all three of stdin, stdout and stderr are open.  Whilst it
>> probably doesn't make sense to call tail without stdout open. there's
>> no obvious reason to require that stdin or stderr must be open.

server% tail /COPYRIGHT <&-
Assertion failed: (procfd > STDERR_FILENO), function service_clean, file 
/usr/src/lib/libcasper/libcasper/service.c, line 394.
tail: unable to init casper: Socket is not connected

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: tail(1) broken in 13-stable

[Mariusz Zaborski]

Could you provide details how to reproduce this?

On Thu, 6 May 2021 at 12:13, Peter Jeremy via freebsd-stable
 wrote:
>
> Since updating from 12-stable to 13-stable, I've found that tail(1)
> crashes, reporting:
> Assertion failed: (procfd > STDERR_FILENO), function service_clean, file 
> /usr/src/lib/libcasper/libcasper/service.c, line 394.
> tail: unable to init casper: Socket is not connected
> unless all three of stdin, stdout and stderr are open.  Whilst it
> probably doesn't make sense to call tail without stdout open. there's
> no obvious reason to require that stdin or stderr must be open.
>
> --
> Peter Jeremy
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

tail(1) broken in 13-stable

[Peter Jeremy via freebsd-stable]

Since updating from 12-stable to 13-stable, I've found that tail(1)
crashes, reporting:
Assertion failed: (procfd > STDERR_FILENO), function service_clean, file 
/usr/src/lib/libcasper/libcasper/service.c, line 394.
tail: unable to init casper: Socket is not connected
unless all three of stdin, stdout and stderr are open.  Whilst it
probably doesn't make sense to call tail without stdout open. there's
no obvious reason to require that stdin or stderr must be open.

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: zpool list -p 's FREE vs. zfs list -p's AVAIL ? FREE-AVAIL == 6_675_374_080 (199G zroot pool)

[Mark Millard via freebsd-stable]

On 2021-May-5, at 17:01, Yuri Pankov  wrote:

> Mark Millard via freebsd-current wrote:
>> Context:
>> 
>> # gpart show -pl da0
>> =>   40  468862048da0  GPT  (224G)
>> 40 532480  da0p1  efiboot0  (260M)
>> 532520   2008 - free -  (1.0M)
>> 534528   25165824  da0p2  swp12a  (12G)
>>   25700352   25165824  da0p4  swp12b  (12G)
>>   50866176  417994752  da0p3  zfs0  (199G)
>>  468860928   1160 - free -  (580K)
>> 
>> There is just one pool: zroot and it is on zfs0 above.
>> 
>> # zpool list -p
>> NAME   SIZEALLOC  FREE  CKPOINT  EXPANDSZ   FRAG
>> CAP  DEDUPHEALTH  ALTROOT
>> zroot  213674622976  71075655680  142598967296- - 28 
>> 33   1.00ONLINE  -
>> 
>> So FREE: 142_598_967_296
>> (using _ to make it more readable)
>> 
>> # zfs list -p zroot 
>> NAME  USED AVAIL REFER  MOUNTPOINT
>> zroot  71073697792  135923593216 98304  /zroot
>> 
>> So AVAIL: 135_923_593_216
>> 
>> FREE-AVAIL == 6_675_374_080
>> 
>> 
>> 
>> The questions:
>> 
>> Is this sort of unavailable pool-free-space normal?
>> Is this some sort of expected overhead that just is
>> not explicitly reported? Possibly a "FRAG"
>> consequence?
> 
> From zpoolprops(8):
> 
> freeThe amount of free space available in the pool.  By contrast,
>the zfs(8) available property describes how much new data can be
>written to ZFS filesystems/volumes.  The zpool free property is
>not generally useful for this purpose, and can be substantially
>more than the zfs available space. This discrepancy is due to
>several factors, including raidz parity; zfs reservation, quota,
>refreservation, and refquota properties; and space set aside by
>spa_slop_shift (see zfs-module-parameters(5) for more
>information).

Thanks for pointing to the reference material.

6_675_374_080/213_674_622_976 =approx= 0.03124 =approx= 1.0/32.0

and spa_slop_shift's description reports:

QUOTE
   spa_slop_shift (int)
   Normally, we don't allow the last 3.2%
   (1/(2^spa_slop_shift)) of space in the pool to be consumed.
   This ensures that we don't run the pool completely out of
   space, due to unaccounted changes (e.g. to the MOS).  It
   also limits the worst-case time to allocate space.  If we
   have less than this amount of free space, most ZPL
   operations (e.g. write, create) will return ENOSPC.

   Default value: 5.
END QUOTE

So in my simple context, apparently not much else
contributes and the figures are basically as
expected.

Thanks again.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: zpool list -p 's FREE vs. zfs list -p's AVAIL ? FREE-AVAIL == 6_675_374_080 (199G zroot pool)

[Yuri Pankov]

Mark Millard via freebsd-current wrote:
> Context:
> 
> # gpart show -pl da0
> =>   40  468862048da0  GPT  (224G)
>  40 532480  da0p1  efiboot0  (260M)
>  532520   2008 - free -  (1.0M)
>  534528   25165824  da0p2  swp12a  (12G)
>25700352   25165824  da0p4  swp12b  (12G)
>50866176  417994752  da0p3  zfs0  (199G)
>   468860928   1160 - free -  (580K)
> 
> There is just one pool: zroot and it is on zfs0 above.
> 
> # zpool list -p
> NAME   SIZEALLOC  FREE  CKPOINT  EXPANDSZ   FRAG
> CAP  DEDUPHEALTH  ALTROOT
> zroot  213674622976  71075655680  142598967296- - 28 
> 33   1.00ONLINE  -
> 
> So FREE: 142_598_967_296
> (using _ to make it more readable)
> 
> # zfs list -p zroot 
> NAME  USED AVAIL REFER  MOUNTPOINT
> zroot  71073697792  135923593216 98304  /zroot
> 
> So AVAIL: 135_923_593_216
> 
> FREE-AVAIL == 6_675_374_080
> 
> 
> 
> The questions:
> 
> Is this sort of unavailable pool-free-space normal?
> Is this some sort of expected overhead that just is
> not explicitly reported? Possibly a "FRAG"
> consequence?

>From zpoolprops(8):

freeThe amount of free space available in the pool.  By contrast,
the zfs(8) available property describes how much new data can be
written to ZFS filesystems/volumes.  The zpool free property is
not generally useful for this purpose, and can be substantially
more than the zfs available space. This discrepancy is due to
several factors, including raidz parity; zfs reservation, quota,
refreservation, and refquota properties; and space set aside by
spa_slop_shift (see zfs-module-parameters(5) for more
information).
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

FreeBSD Quarterly Status Report - First Quarter 2021

[Daniel Ebdrup Jensen]

Introduction

This report covers FreeBSD related projects for the period between January and
March, and is the first of four planned reports for 2021.

The first quarter of 2021 has been very active in both FreeBSD-CURRENT and
-STABLE, with 13.0-RELEASE work starting in January and finishing up mid-April.
It provides lots of new features, and there’s even a good chance that some
workloads will experience performance improvements.

The number of entries is slightly down, and this is probably due to a
combination of factors like code slush as well as the ongoing issues with
COVID-19, but we naturally hope that things will look up next quarter. This
combined with a switch-over to AsciiDoctor and a decision to make full use of
the status report work schedule to avoid stress, means that the report can now
be expected to come out at the end of the first month after the quarter has
finished, rather than in the middle.

This report in particular includes a number of interesting entries, covering
everything from the linuxulator, various mitigation work, long-awaited work on
OpenBSM, work on kernel sanitizers, and many more things that it is hoped you
will enjoy reading about.

Yours,
Daniel Ebdrup Jensen, with a status hat on.

━━━
Table of Contents

  • FreeBSD Team Reports
  □ FreeBSD Foundation
  □ FreeBSD Release Engineering Team
  □ Cluster Administration Team
  □ Continuous Integration
  □ Ports Collection
  • Projects
  □ Git Migration Working Group
  □ LLDB Debugger Improvements
  □ Linux compatibility layer update
  □ Vulnerability Mitigations
  □ OpenBSM Synchronisation
  • Kernel
  □ ENA FreeBSD Driver Update
  □ Intel wireless update
  □ Kernel Sanitizers
  □ Marvell ARM64 SoCs support
  □ nv(9)-based audio device enumeration
  • Ports
  □ KDE on FreeBSD
  □ FreeBSD Office team 2021Q1 status report
  □ VirtualBox FreeBSD port
  • Documentation
  □ DOCNG on FreeBSD
  □ FreeBSD Translations on Weblate
  □ WebApps working group
  • Miscellaneous
  □ Discord Server & Community Growth
  • Third-Party Projects
  □ CBSD Project
  □ helloSystem
  □ PkgBase.live
  □ Potluck & Potman
  □ sysctl improvements

━━━

FreeBSD Team Reports

Entries from the various official and semi-official teams, as found in the
Administration Page.

FreeBSD Foundation

Contact: Deb Goodkin 

The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to
supporting and promoting the FreeBSD Project and community worldwide. Funding
comes from individual and corporate donations and is used to fund and manage
software development projects, conferences and developer summits, and provide
travel grants to FreeBSD contributors. The Foundation purchases and supports
hardware to improve and maintain FreeBSD infrastructure and provides resources
to improve security, quality assurance, and release engineering efforts;
publishes marketing material to promote, educate, and advocate for the FreeBSD
Project; facilitates collaboration between commercial vendors and FreeBSD
developers; and finally, represents the FreeBSD Project in executing contracts,
license agreements, and other legal arrangements that require a recognized
legal entity.

Here are some highlights of what we did to help FreeBSD last quarter:

COVID-19 Impact to the Foundation

Like most organizations, our team continued to work from home. Our temporary
ban on travel for staff members remains in effect, but continues to not affect
our output too much, since most conferences are still virtual. We continued
supporting the community and Project, even though some of our work and
responses may have been delayed because of changes in some of our priorities
and the impact of limited childcare for a few of our staff members.

Partnerships and Commercial User Support

We help facilitate collaboration between commercial users and FreeBSD
developers. We also meet with companies to discuss their needs and bring that
information back to the Project. Not surprisingly, the stay at home orders,
combined with our company ban on travel during Q1 made in-person meetings
non-existent. However, the team was able to continue meeting with our partners
and commercial users virtually. These meetings help us understand some of the
applications where FreeBSD is used.

We were thrilled for the opportunity to work with AMD early on to ensure
FreeBSD worked on their recently released third generation EPYC series. You can
read more about that here: https://freebsdfoundation.org/news-and-events/
latest-news/freebsd-well-prepared-for-amd-epyc-7003-series-processors/.

Fundraising Efforts

First, we’d like to say thank you to everyone who has given us a financial
contribution this year! Last quarter we raised $88,237, which includes
donations from 

zpool list -p 's FREE vs. zfs list -p's AVAIL ? FREE-AVAIL == 6_675_374_080 (199G zroot pool)

[Mark Millard via freebsd-stable]

Context:

# gpart show -pl da0
=>   40  468862048da0  GPT  (224G)
 40 532480  da0p1  efiboot0  (260M)
 532520   2008 - free -  (1.0M)
 534528   25165824  da0p2  swp12a  (12G)
   25700352   25165824  da0p4  swp12b  (12G)
   50866176  417994752  da0p3  zfs0  (199G)
  468860928   1160 - free -  (580K)

There is just one pool: zroot and it is on zfs0 above.

# zpool list -p
NAME   SIZEALLOC  FREE  CKPOINT  EXPANDSZ   FRAGCAP 
 DEDUPHEALTH  ALTROOT
zroot  213674622976  71075655680  142598967296- - 28 33 
  1.00ONLINE  -

So FREE: 142_598_967_296
(using _ to make it more readable)

# zfs list -p zroot 
NAME  USED AVAIL REFER  MOUNTPOINT
zroot  71073697792  135923593216 98304  /zroot

So AVAIL: 135_923_593_216

FREE-AVAIL == 6_675_374_080



The questions:

Is this sort of unavailable pool-free-space normal?
Is this some sort of expected overhead that just is
not explicitly reported? Possibly a "FRAG"
consequence?


For reference:

# zpool status
  pool: zroot
 state: ONLINE
  scan: scrub repaired 0B in 00:31:48 with 0 errors on Sun May  2 19:52:14 2021
config:

NAMESTATE READ WRITE CKSUM
zroot   ONLINE   0 0 0
  da0p3 ONLINE   0 0 0

errors: No known data errors


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: ZFS rename with associated snapshot present: odd error message

[Mark Millard via freebsd-stable]

On 2021-May-5, at 05:28, Mark Millard  wrote:

> On 2021-May-5, at 02:47, Andriy Gapon  wrote:
> 
>> On 05/05/2021 01:59, Mark Millard via freebsd-current wrote:
>>> I had a:
>>> # zfs list -tall
>>> NAME   USED  AVAIL REFER  MOUNTPOINT
>>> . . .
>>> zroot/DESTDIRs/13_0R-CA72-instwrld-norm  1.44G   117G   96K 
>>>  /usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm
>>> zroot/DESTDIRs/13_0R-CA72-instwrld-norm@dirty-style  1.44G  - 1.44G 
>>>  -. . .
>>> . . .
>>> (copied/pasted from somewhat earlier) and then attempted:
>>> # zfs rename zroot/DESTDIRs/13_0R-CA72-instwrld-norm 
>>> zroot/DESTDIRs/13_0R-CA72-instwrld-alt-0
>>> cannot open 'zroot/DESTDIRs/13_0R-CA72-instwrld-norm@dirty-style': snapshot 
>>> delimiter '@' is not expected here
>>> Despite the "cannot open" message, the result looks like:
>>> # zfs list -tall
>>> NAME   USED  AVAIL 
>>> REFER  MOUNTPOINT
>>> . . .
>>> zroot/DESTDIRs/13_0R-CA72-instwrld-alt-0  1.44G   114G  
>>>  96K  /usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt-0
>>> zroot/DESTDIRs/13_0R-CA72-instwrld-alt-0@dirty-style  1.44G  - 
>>> 1.44G  -
>>> . . .
>>> Still, it leaves me wondering if everything is okay
>>> given that internal attempt to use the old name with
>>> @dirty-style when it was apparently no longer
>>> available under that naming.
>>> For reference:
>>> # uname -apKU
>>> FreeBSD CA72_4c8G_ZFS 13.0-RELEASE FreeBSD 13.0-RELEASE #0 
>>> releng/13.0-n244733-ea31abc261ff-dirty: Thu Apr 29 21:53:20 PDT 2021 
>>> root@CA72_4c8G_ZFS:/usr/obj/BUILDs/13_0R-CA72-nodbg-clang/usr/13_0R-src/arm64.aarch64/sys/GENERIC-NODBG-CA72
>>>   arm64 aarch64 1300139 1300139
>> 
>> Cannot reproduce here (but with much simpler names and on stable/13):
>> zfs create testz/test
>> zfs snapshot testz/test@snap1
>> zfs rename testz/test testz/test2
>> 
>> All worked.
>> 
> 
> I've noticed that sometimes in my explorations it has been
> silent instead of complaining. I've no clue at this point
> what prior activity (or lack of activity) makes the
> difference for if a message will be generated vs. not.

One difference in context is that your above sort of sequence
generates the after-snapshot context (using some things I have
around now):

zroot/DESTDIRs/13_0R-CA53-poud 1.45G   127G 1.45G  
/usr/obj/DESTDIRs/13_0R-CA53-poud
zroot/DESTDIRs/13_0R-CA53-poud@test   0B  - 1.45G  -

where my example had something more like (hand edited
the above just for illustration):

zroot/DESTDIRs/13_0R-CA53-poud 1.45G   125G   96K  
/usr/obj/DESTDIRs/13_0R-CA53-poud
zroot/DESTDIRs/13_0R-CA53-poud@test1.45G  - 1.45G  -

before the rename. In other words, I'd updated the
original (almost?) completely after the snapshot
(as a side effect of my overall activity). It was
only later that I tried the rename to track a new
purpose/context that I was going to switch to.

I'm not claiming that such is sufficient to
(always? ever?) reproduce the message. I'm
just pointing out that I'd had some significant
activity on the writable file system before the
rename.

Some of my activity has been more like your test
and I'd not seen the problems from such. But it
is not a very good comparison/contrast context
so I'd not infer much. I still can not at-will
set up a context to produce the messages.



===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Building an 13-STABLE release for i386

[Glen Barber]

On Wed, May 05, 2021 at 09:16:19PM +0200, Gordon Bergling wrote:
> On Wed, May 05, 2021 at 07:02:42PM +, Glen Barber wrote:
> > On Wed, May 05, 2021 at 08:56:58PM +0200, Gordon Bergling wrote:
> > > Hi,
> > > 
> > > I am currently try to build a custom 13-STABLE release for i386, build on
> > > an amd64 system. According to release(7) the following command should
> > > do the trick, but it fails with the following error message.
> > > 
> > > $ doas sh release.sh -c i386/i386.conf 
> > > ld-elf32.so.1: Shared object "libedit.so.8" not found, required by "sh"
> > > 
> > > Has anyone an idea what could cause this?
> > > 
> > 
> > Do you have lib32 compatibility installed on the build host?  I.e., do
> > you have WITHOUT_LIB32 defined in your src.conf?
> > 
> > Glen
> 
> lib32 compatibility should be installed, the src.conf of the buildsystem 
> (recent 12-STABLE) only has the following entries defined:
> 
> WITH_PIE=1
> WITH_RETPOLINE=1
> 

Hmm.  I can't see why this would be failing for you then.  I routinely
do this every week for the development snapshots.

Is there a chance your system is somehow mismatched regarding userland
and kernel?  What version is the build host running?  What does
'uname -UK' show?

libedit(3) was bumped on Feb 1, 2021 following an update to ncurses(3).
My gut tells me these may be related.

Glen




signature.asc
Description: PGP signature

Re: Building an 13-STABLE release for i386

[Gordon Bergling]

On Wed, May 05, 2021 at 07:02:42PM +, Glen Barber wrote:
> On Wed, May 05, 2021 at 08:56:58PM +0200, Gordon Bergling wrote:
> > Hi,
> > 
> > I am currently try to build a custom 13-STABLE release for i386, build on
> > an amd64 system. According to release(7) the following command should
> > do the trick, but it fails with the following error message.
> > 
> > $ doas sh release.sh -c i386/i386.conf 
> > ld-elf32.so.1: Shared object "libedit.so.8" not found, required by "sh"
> > 
> > Has anyone an idea what could cause this?
> > 
> 
> Do you have lib32 compatibility installed on the build host?  I.e., do
> you have WITHOUT_LIB32 defined in your src.conf?
> 
> Glen

lib32 compatibility should be installed, the src.conf of the buildsystem 
(recent 12-STABLE) only has the following entries defined:

WITH_PIE=1
WITH_RETPOLINE=1

--Gordon
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Building an 13-STABLE release for i386

[Glen Barber]

On Wed, May 05, 2021 at 08:56:58PM +0200, Gordon Bergling wrote:
> Hi,
> 
> I am currently try to build a custom 13-STABLE release for i386, build on
> an amd64 system. According to release(7) the following command should
> do the trick, but it fails with the following error message.
> 
> $ doas sh release.sh -c i386/i386.conf 
> ld-elf32.so.1: Shared object "libedit.so.8" not found, required by "sh"
> 
> Has anyone an idea what could cause this?
> 

Do you have lib32 compatibility installed on the build host?  I.e., do
you have WITHOUT_LIB32 defined in your src.conf?

Glen



signature.asc
Description: PGP signature

Building an 13-STABLE release for i386

[Gordon Bergling]

Hi,

I am currently try to build a custom 13-STABLE release for i386, build on
an amd64 system. According to release(7) the following command should
do the trick, but it fails with the following error message.

$ doas sh release.sh -c i386/i386.conf 
ld-elf32.so.1: Shared object "libedit.so.8" not found, required by "sh"

Has anyone an idea what could cause this?

--Gordon
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FYI: WITH_REPRODUCIBLE_BUILD= problem for some files? [aarch64 test did not reproduce the issue]

[Mark Millard via freebsd-stable]

On 2021-May-4, at 20:26, Mark Millard  wrote:

> On 2021-May-4, at 13:38, Mark Millard  wrote:
> 
>> [The first buidlworld is still in process. So while waiting . . .]
>> 
>> On 2021-May-4, at 10:31, Mark Millard  wrote:
>> 
>>> I probably know why the huge count of differences this time
>>> unlike the original report . . .
>>> 
>>> Previously I built based on a checked-in branch as part of
>>> my experimenting. This time it was in a -dirty form (not
>>> checked in), again as part of my experimental exploration.
>>> 
>>> WITH_REPRODUCIBLE_BUILD= makes a distinction between these
>>> if I remember right: (partially?) disabling itself for
>>> -dirty style.
>>> 
>>> To reproduce the original style of test I need to create
>>> a branch with my few patches checked in and do the
>>> buildworlds from that branch.
>>> 
>>> This will, of course, take a while.
>>> 
>>> Sorry for the noise.
>>> 
>> 
>> I've confirmed some of the details of the large number of
>> files with difference while waiting for the 1st buildworld :
>> 
>> The 4 bytes at the end of the .gnu_debuglink section
>> that are ending up different are the checksum for the
>> .debug file. The .debug files have differences such as:
>> 
>> │ -<1a>   DW_AT_comp_dir: (indirect string) 
>> /usr/obj/BUILDs/13_0R-CA72-nodbg-clang-alt/usr/13_0R-src/arm64.aarch64/lib/csu/aarch64
>> │ +<1a>   DW_AT_comp_dir: (indirect string) 
>> /usr/obj/BUILDs/13_0R-CA72-nodbg-clang/usr/13_0R-src/arm64.aarch64/lib/csu/aarch64
>> 
>> So I need to build, snapshot (in case need
>> to reference), install, clean-out, build,
>> install elsewhere, compare. (Or analogous
>> that uses the same build base-path for both
>> installs despite separate buildworld's.)
>> This is separate from any potential -dirty
>> vs. checked-in handling variation by
>> WITH_REPRODUCIBLE_BUILD= .
>> 
>> My process that produced the original armv7
>> report happened to do that before I accidentally
>> discovered the presence of the few files with
>> differences. My new experiments were different
>> and I'd not though of needing to vary the
>> procedure to get you the right evidence.
>> 
> 
> The two aarch64 test installs did not show any
> differences in a "diff -rq" . Ignoring *.meta
> files generated during the builds, the build
> directory tree snapshots showed just the
> differences:
> 
> # diff -rq 
> /usr/obj/BUILDs/13_0R-CA72-nodbg-clang-alt/.zfs/snapshot/commited-style-0/usr 
> /usr/obj/BUILDs/13_0R-CA72-nodbg-clang-alt/.zfs/snapshot/commited-style-1/usr 
> | grep -v '\.meta' | more
> Files 
> /usr/obj/BUILDs/13_0R-CA72-nodbg-clang-alt/.zfs/snapshot/commited-style-0/usr/13_0R-src/arm64.aarch64/stand/ficl/softcore.c
>  and 
> /usr/obj/BUILDs/13_0R-CA72-nodbg-clang-alt/.zfs/snapshot/commited-style-1/usr/13_0R-src/arm64.aarch64/stand/ficl/softcore.c
>  differ
> Files 
> /usr/obj/BUILDs/13_0R-CA72-nodbg-clang-alt/.zfs/snapshot/commited-style-0/usr/13_0R-src/arm64.aarch64/toolchain-metadata.mk
>  and 
> /usr/obj/BUILDs/13_0R-CA72-nodbg-clang-alt/.zfs/snapshot/commited-style-1/usr/13_0R-src/arm64.aarch64/toolchain-metadata.mk
>  differ
> 
> # diff -u 
> /usr/obj/BUILDs/13_0R-CA72-nodbg-clang-alt/.zfs/snapshot/commited-style-0/usr/13_0R-src/arm64.aarch64/stand/ficl/softcore.c
>  
> /usr/obj/BUILDs/13_0R-CA72-nodbg-clang-alt/.zfs/snapshot/commited-style-1/usr/13_0R-src/arm64.aarch64/stand/ficl/softcore.c
> --- 
> /usr/obj/BUILDs/13_0R-CA72-nodbg-clang-alt/.zfs/snapshot/commited-style-0/usr/13_0R-src/arm64.aarch64/stand/ficl/softcore.c
>  2021-05-04 13:45:14.463351000 -0700
> +++ 
> /usr/obj/BUILDs/13_0R-CA72-nodbg-clang-alt/.zfs/snapshot/commited-style-1/usr/13_0R-src/arm64.aarch64/stand/ficl/softcore.c
>  2021-05-04 19:04:32.338203000 -0700
> @@ -4,7 +4,7 @@
> ** Words from CORE set written in FICL
> ** Author: John Sadler (john_sad...@alum.mit.edu)
> ** Created: 27 December 1997
> -** Last update: Tue May  4 13:45:14 PDT 2021
> +** Last update: Tue May  4 19:04:32 PDT 2021
> ***/
> /*
> ** DO NOT EDIT THIS FILE -- it is generated by softwords/softcore.awk
> 
> # diff -u 
> /usr/obj/BUILDs/13_0R-CA72-nodbg-clang-alt/.zfs/snapshot/commited-style-0/usr/13_0R-src/arm64.aarch64/toolchain-metadata.mk
>  
> /usr/obj/BUILDs/13_0R-CA72-nodbg-clang-alt/.zfs/snapshot/commited-style-1/usr/13_0R-src/arm64.aarch64/toolchain-metadata.mk
> --- 
> /usr/obj/BUILDs/13_0R-CA72-nodbg-clang-alt/.zfs/snapshot/commited-style-0/usr/13_0R-src/arm64.aarch64/toolchain-metadata.mk
>  2021-05-04 10:55:26.030179000 -0700
> +++ 
> /usr/obj/BUILDs/13_0R-CA72-nodbg-clang-alt/.zfs/snapshot/commited-style-1/usr/13_0R-src/arm64.aarch64/toolchain-metadata.mk
>  2021-05-04 16:14:24.513346000 -0700
> @@ -1,4 +1,4 @@
> -.info Using cached toolchain metadata from build at CA72_4c8G_ZFS on Tue May 
>  4 10:55:26 PDT 2021
> +.info Using cached toolchain metadata from build at CA72_4c8G_ZFS on Tue May 
>  4 16:14:24 PDT 2021
> _LOADED_TOOLCHAIN_METADATA=t
> 

Re: ZFS rename with associated snapshot present: odd error message

[Mark Millard via freebsd-stable]

On 2021-May-5, at 02:47, Andriy Gapon  wrote:

> On 05/05/2021 01:59, Mark Millard via freebsd-current wrote:
>> I had a:
>> # zfs list -tall
>> NAME   USED  AVAIL REFER  MOUNTPOINT
>> . . .
>> zroot/DESTDIRs/13_0R-CA72-instwrld-norm  1.44G   117G   96K  
>> /usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm
>> zroot/DESTDIRs/13_0R-CA72-instwrld-norm@dirty-style  1.44G  - 1.44G  
>> -. . .
>> . . .
>> (copied/pasted from somewhat earlier) and then attempted:
>> # zfs rename zroot/DESTDIRs/13_0R-CA72-instwrld-norm 
>> zroot/DESTDIRs/13_0R-CA72-instwrld-alt-0
>> cannot open 'zroot/DESTDIRs/13_0R-CA72-instwrld-norm@dirty-style': snapshot 
>> delimiter '@' is not expected here
>> Despite the "cannot open" message, the result looks like:
>> # zfs list -tall
>> NAME   USED  AVAIL 
>> REFER  MOUNTPOINT
>> . . .
>> zroot/DESTDIRs/13_0R-CA72-instwrld-alt-0  1.44G   114G   
>> 96K  /usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt-0
>> zroot/DESTDIRs/13_0R-CA72-instwrld-alt-0@dirty-style  1.44G  - 
>> 1.44G  -
>> . . .
>> Still, it leaves me wondering if everything is okay
>> given that internal attempt to use the old name with
>> @dirty-style when it was apparently no longer
>> available under that naming.
>> For reference:
>> # uname -apKU
>> FreeBSD CA72_4c8G_ZFS 13.0-RELEASE FreeBSD 13.0-RELEASE #0 
>> releng/13.0-n244733-ea31abc261ff-dirty: Thu Apr 29 21:53:20 PDT 2021 
>> root@CA72_4c8G_ZFS:/usr/obj/BUILDs/13_0R-CA72-nodbg-clang/usr/13_0R-src/arm64.aarch64/sys/GENERIC-NODBG-CA72
>>   arm64 aarch64 1300139 1300139
> 
> Cannot reproduce here (but with much simpler names and on stable/13):
> zfs create testz/test
> zfs snapshot testz/test@snap1
> zfs rename testz/test testz/test2
> 
> All worked.
> 

I've noticed that sometimes in my explorations it has been
silent instead of complaining. I've no clue at this point
what prior activity (or lack of activity) makes the
difference for if a message will be generated vs. not.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: ZFS rename with associated snapshot present: odd error message

[Andriy Gapon]

On 05/05/2021 01:59, Mark Millard via freebsd-current wrote:

I had a:

# zfs list -tall
NAME   USED  AVAIL REFER  MOUNTPOINT
. . .
zroot/DESTDIRs/13_0R-CA72-instwrld-norm  1.44G   117G   96K  
/usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm
zroot/DESTDIRs/13_0R-CA72-instwrld-norm@dirty-style  1.44G  - 1.44G  -. 
. .
. . .

(copied/pasted from somewhat earlier) and then attempted:

# zfs rename zroot/DESTDIRs/13_0R-CA72-instwrld-norm 
zroot/DESTDIRs/13_0R-CA72-instwrld-alt-0
cannot open 'zroot/DESTDIRs/13_0R-CA72-instwrld-norm@dirty-style': snapshot 
delimiter '@' is not expected here

Despite the "cannot open" message, the result looks like:

# zfs list -tall
NAME   USED  AVAIL 
REFER  MOUNTPOINT
. . .
zroot/DESTDIRs/13_0R-CA72-instwrld-alt-0  1.44G   114G   
96K  /usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt-0
zroot/DESTDIRs/13_0R-CA72-instwrld-alt-0@dirty-style  1.44G  - 
1.44G  -
. . .

Still, it leaves me wondering if everything is okay
given that internal attempt to use the old name with
@dirty-style when it was apparently no longer
available under that naming.

For reference:

# uname -apKU
FreeBSD CA72_4c8G_ZFS 13.0-RELEASE FreeBSD 13.0-RELEASE #0 
releng/13.0-n244733-ea31abc261ff-dirty: Thu Apr 29 21:53:20 PDT 2021 
root@CA72_4c8G_ZFS:/usr/obj/BUILDs/13_0R-CA72-nodbg-clang/usr/13_0R-src/arm64.aarch64/sys/GENERIC-NODBG-CA72
  arm64 aarch64 1300139 1300139


Cannot reproduce here (but with much simpler names and on stable/13):
zfs create testz/test
zfs snapshot testz/test@snap1
zfs rename testz/test testz/test2

All worked.

--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FYI: WITH_REPRODUCIBLE_BUILD= problem for some files? [aarch64 test did not reproduce the issue]

[Mark Millard via freebsd-stable]

On 2021-May-4, at 13:38, Mark Millard  wrote:

> [The first buidlworld is still in process. So while waiting . . .]
> 
> On 2021-May-4, at 10:31, Mark Millard  wrote:
> 
>> I probably know why the huge count of differences this time
>> unlike the original report . . .
>> 
>> Previously I built based on a checked-in branch as part of
>> my experimenting. This time it was in a -dirty form (not
>> checked in), again as part of my experimental exploration.
>> 
>> WITH_REPRODUCIBLE_BUILD= makes a distinction between these
>> if I remember right: (partially?) disabling itself for
>> -dirty style.
>> 
>> To reproduce the original style of test I need to create
>> a branch with my few patches checked in and do the
>> buildworlds from that branch.
>> 
>> This will, of course, take a while.
>> 
>> Sorry for the noise.
>> 
> 
> I've confirmed some of the details of the large number of
> files with difference while waiting for the 1st buildworld :
> 
> The 4 bytes at the end of the .gnu_debuglink section
> that are ending up different are the checksum for the
> .debug file. The .debug files have differences such as:
> 
> │ -<1a>   DW_AT_comp_dir: (indirect string) 
> /usr/obj/BUILDs/13_0R-CA72-nodbg-clang-alt/usr/13_0R-src/arm64.aarch64/lib/csu/aarch64
> │ +<1a>   DW_AT_comp_dir: (indirect string) 
> /usr/obj/BUILDs/13_0R-CA72-nodbg-clang/usr/13_0R-src/arm64.aarch64/lib/csu/aarch64
> 
> So I need to build, snapshot (in case need
> to reference), install, clean-out, build,
> install elsewhere, compare. (Or analogous
> that uses the same build base-path for both
> installs despite separate buildworld's.)
> This is separate from any potential -dirty
> vs. checked-in handling variation by
> WITH_REPRODUCIBLE_BUILD= .
> 
> My process that produced the original armv7
> report happened to do that before I accidentally
> discovered the presence of the few files with
> differences. My new experiments were different
> and I'd not though of needing to vary the
> procedure to get you the right evidence.
> 

The two aarch64 test installs did not show any
differences in a "diff -rq" . Ignoring *.meta
files generated during the builds, the build
directory tree snapshots showed just the
differences:

# diff -rq 
/usr/obj/BUILDs/13_0R-CA72-nodbg-clang-alt/.zfs/snapshot/commited-style-0/usr 
/usr/obj/BUILDs/13_0R-CA72-nodbg-clang-alt/.zfs/snapshot/commited-style-1/usr | 
grep -v '\.meta' | more
Files 
/usr/obj/BUILDs/13_0R-CA72-nodbg-clang-alt/.zfs/snapshot/commited-style-0/usr/13_0R-src/arm64.aarch64/stand/ficl/softcore.c
 and 
/usr/obj/BUILDs/13_0R-CA72-nodbg-clang-alt/.zfs/snapshot/commited-style-1/usr/13_0R-src/arm64.aarch64/stand/ficl/softcore.c
 differ
Files 
/usr/obj/BUILDs/13_0R-CA72-nodbg-clang-alt/.zfs/snapshot/commited-style-0/usr/13_0R-src/arm64.aarch64/toolchain-metadata.mk
 and 
/usr/obj/BUILDs/13_0R-CA72-nodbg-clang-alt/.zfs/snapshot/commited-style-1/usr/13_0R-src/arm64.aarch64/toolchain-metadata.mk
 differ

# diff -u 
/usr/obj/BUILDs/13_0R-CA72-nodbg-clang-alt/.zfs/snapshot/commited-style-0/usr/13_0R-src/arm64.aarch64/stand/ficl/softcore.c
 
/usr/obj/BUILDs/13_0R-CA72-nodbg-clang-alt/.zfs/snapshot/commited-style-1/usr/13_0R-src/arm64.aarch64/stand/ficl/softcore.c
--- 
/usr/obj/BUILDs/13_0R-CA72-nodbg-clang-alt/.zfs/snapshot/commited-style-0/usr/13_0R-src/arm64.aarch64/stand/ficl/softcore.c
 2021-05-04 13:45:14.463351000 -0700
+++ 
/usr/obj/BUILDs/13_0R-CA72-nodbg-clang-alt/.zfs/snapshot/commited-style-1/usr/13_0R-src/arm64.aarch64/stand/ficl/softcore.c
 2021-05-04 19:04:32.338203000 -0700
@@ -4,7 +4,7 @@
 ** Words from CORE set written in FICL
 ** Author: John Sadler (john_sad...@alum.mit.edu)
 ** Created: 27 December 1997
-** Last update: Tue May  4 13:45:14 PDT 2021
+** Last update: Tue May  4 19:04:32 PDT 2021
 ***/
 /*
 ** DO NOT EDIT THIS FILE -- it is generated by softwords/softcore.awk

# diff -u 
/usr/obj/BUILDs/13_0R-CA72-nodbg-clang-alt/.zfs/snapshot/commited-style-0/usr/13_0R-src/arm64.aarch64/toolchain-metadata.mk
 
/usr/obj/BUILDs/13_0R-CA72-nodbg-clang-alt/.zfs/snapshot/commited-style-1/usr/13_0R-src/arm64.aarch64/toolchain-metadata.mk
--- 
/usr/obj/BUILDs/13_0R-CA72-nodbg-clang-alt/.zfs/snapshot/commited-style-0/usr/13_0R-src/arm64.aarch64/toolchain-metadata.mk
 2021-05-04 10:55:26.030179000 -0700
+++ 
/usr/obj/BUILDs/13_0R-CA72-nodbg-clang-alt/.zfs/snapshot/commited-style-1/usr/13_0R-src/arm64.aarch64/toolchain-metadata.mk
 2021-05-04 16:14:24.513346000 -0700
@@ -1,4 +1,4 @@
-.info Using cached toolchain metadata from build at CA72_4c8G_ZFS on Tue May  
4 10:55:26 PDT 2021
+.info Using cached toolchain metadata from build at CA72_4c8G_ZFS on Tue May  
4 16:14:24 PDT 2021
 _LOADED_TOOLCHAIN_METADATA=t
 COMPILER_VERSION=110001
 X_COMPILER_VERSION=110001



I may run a 'target cortex-a7 (so: armv7) from aarch64' test
next. That was the context for the original discovery and
report.



===
Mark Millard
marklmi at yahoo.com
( 

ZFS rename with associated snapshot present: odd error message

[Mark Millard via freebsd-stable]

I had a:

# zfs list -tall
NAME   USED  AVAIL REFER  MOUNTPOINT
. . .
zroot/DESTDIRs/13_0R-CA72-instwrld-norm  1.44G   117G   96K  
/usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm
zroot/DESTDIRs/13_0R-CA72-instwrld-norm@dirty-style  1.44G  - 1.44G  -. 
. .
. . .

(copied/pasted from somewhat earlier) and then attempted:

# zfs rename zroot/DESTDIRs/13_0R-CA72-instwrld-norm 
zroot/DESTDIRs/13_0R-CA72-instwrld-alt-0
cannot open 'zroot/DESTDIRs/13_0R-CA72-instwrld-norm@dirty-style': snapshot 
delimiter '@' is not expected here

Despite the "cannot open" message, the result looks like:

# zfs list -tall
NAME   USED  AVAIL 
REFER  MOUNTPOINT
. . .
zroot/DESTDIRs/13_0R-CA72-instwrld-alt-0  1.44G   114G   
96K  /usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt-0
zroot/DESTDIRs/13_0R-CA72-instwrld-alt-0@dirty-style  1.44G  - 
1.44G  -
. . .

Still, it leaves me wondering if everything is okay
given that internal attempt to use the old name with
@dirty-style when it was apparently no longer
available under that naming.

For reference:

# uname -apKU
FreeBSD CA72_4c8G_ZFS 13.0-RELEASE FreeBSD 13.0-RELEASE #0 
releng/13.0-n244733-ea31abc261ff-dirty: Thu Apr 29 21:53:20 PDT 2021 
root@CA72_4c8G_ZFS:/usr/obj/BUILDs/13_0R-CA72-nodbg-clang/usr/13_0R-src/arm64.aarch64/sys/GENERIC-NODBG-CA72
  arm64 aarch64 1300139 1300139


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FYI: WITH_REPRODUCIBLE_BUILD= problem for some files? [Ignore recent test: -dirty vs. checked-in usage difference]

[Mark Millard via freebsd-stable]

[The first buidlworld is still in process. So while waiting . . .]

On 2021-May-4, at 10:31, Mark Millard  wrote:

> I probably know why the huge count of differences this time
> unlike the original report . . .
> 
> Previously I built based on a checked-in branch as part of
> my experimenting. This time it was in a -dirty form (not
> checked in), again as part of my experimental exploration.
> 
> WITH_REPRODUCIBLE_BUILD= makes a distinction between these
> if I remember right: (partially?) disabling itself for
> -dirty style.
> 
> To reproduce the original style of test I need to create
> a branch with my few patches checked in and do the
> buildworlds from that branch.
> 
> This will, of course, take a while.
> 
> Sorry for the noise.
> 

I've confirmed some of the details of the large number of
files with difference while waiting for the 1st buildworld :

The 4 bytes at the end of the .gnu_debuglink section
that are ending up different are the checksum for the
.debug file. The .debug files have differences such as:

│ -<1a>   DW_AT_comp_dir: (indirect string) 
/usr/obj/BUILDs/13_0R-CA72-nodbg-clang-alt/usr/13_0R-src/arm64.aarch64/lib/csu/aarch64
│ +<1a>   DW_AT_comp_dir: (indirect string) 
/usr/obj/BUILDs/13_0R-CA72-nodbg-clang/usr/13_0R-src/arm64.aarch64/lib/csu/aarch64

So I need to build, snapshot (in case need
to reference), install, clean-out, build,
install elsewhere, compare. (Or analogous
that uses the same build base-path for both
installs despite separate buildworld's.)
This is separate from any potential -dirty
vs. checked-in handling variation by
WITH_REPRODUCIBLE_BUILD= .

My process that produced the original armv7
report happened to do that before I accidentally
discovered the presence of the few files with
differences. My new experiments were different
and I'd not though of needing to vary the
procedure to get you the right evidence.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

diffoscope's odd UnicodeDecodeError error message: reason found

[Mark Millard via freebsd-stable]

I had reported in the reproducable build list messages:

> # diffoscope /.zfs/snapshot/2021-04-*-01:40:48-0/bin/sh
> [...]
> $<3/>2021-05-04 08:49:21 W: diffoscope.main: Fuzzy-matching is currently 
> disabled as the "tlsh" module is unavailable.
> UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb7 in position 18: 
> invalid start byte

Well, it turns out that the file name pattern was
incorrect and only matched one file.

By contrast:

# diffoscope /.zfs/snapshot/2021-04-*/bin/sh
$<3/>2021-05-04 11:05:25 W: diffoscope.main: Fuzzy-matching is currently 
disabled as the "tlsh" module is unavailable.

worked fine.

And making the "one file" status obvious:

# diffoscope c_tests/a.out
$<3/>2021-05-04 11:11:45 W: diffoscope.main: Fuzzy-matching is currently 
disabled as the "tlsh" module is unavailable.
$<3/>Traceback (most recent call last):
  File "/usr/local/lib/python3.7/site-packages/diffoscope/main.py", line 745, 
in main
sys.exit(run_diffoscope(parsed_args))
  File "/usr/local/lib/python3.7/site-packages/diffoscope/main.py", line 677, 
in run_diffoscope
difference = load_diff_from_path(path1)
  File "/usr/local/lib/python3.7/site-packages/diffoscope/readers/__init__.py", 
line 31, in load_diff_from_path
return load_diff(codecs.getreader("utf-8")(fp), path)
  File "/usr/local/lib/python3.7/site-packages/diffoscope/readers/__init__.py", 
line 35, in load_diff
return JSONReaderV1().load(fp, path)
  File "/usr/local/lib/python3.7/site-packages/diffoscope/readers/json.py", 
line 33, in load
raw = json.load(fp)
  File "/usr/local/lib/python3.7/json/__init__.py", line 293, in load
return loads(fp.read(),
  File "/usr/local/lib/python3.7/codecs.py", line 504, in read
newchars, decodedbytes = self.decode(data, self.errors)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb7 in position 18: 
invalid start byte

Not exactly an obvious error message for the issue.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FYI: WITH_REPRODUCIBLE_BUILD= problem for some files? [Ignore recent test: -dirty vs. checked-in usage difference]

[Mark Millard via freebsd-stable]

I probably know why the huge count of differences this time
unlike the original report . . .

Previously I built based on a checked-in branch as part of
my experimenting. This time it was in a -dirty form (not
checked in), again as part of my experimental exploration.

WITH_REPRODUCIBLE_BUILD= makes a distinction between these
if I remember right: (partially?) disabling itself for
-dirty style.

To reproduce the original style of test I need to create
a branch with my few patches checked in and do the
buildworlds from that branch.

This will, of course, take a while.

Sorry for the noise.



===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FYI: WITH_REPRODUCIBLE_BUILD= problem for some files?

[Mark Millard via freebsd-stable]

[Just adding readelf -S info since it seems to show more.]

On 2021-May-4, at 10:01, Mark Millard  wrote:


> On 2021-May-4, at 08:51, Mark Millard  wrote:
> 
>> On 2021-May-4, at 06:01, Ed Maste  wrote:
>> 
>>> On Mon, 3 May 2021 at 22:26, Mark Millard  wrote:
 
 But I'll note that I've built and stalled py37-diffoscope
 (new to me). A basic quick test showed that it reports:
 
 W: diffoscope.main: Fuzzy-matching is currently disabled as the "tlsh" 
 module is unavailable.
>>> 
>>> I just looked up tlsh - its "A Locality Sensitive Hash"; I presume
>>> diffoscope uses it to infer file renames. I believe the warning
>>> emitted here should have no impact on the output we're looking for.
>> 
>> Okay.
>> 
>>> As far as the utf-8 issues go, diffoscope requires a utf-8 locale and
>>> I suspect that is the issue. If you don't have LANG set already, try
>>> setting LANG=C.UTF-8 in your environment.
>> 
>> That is not the issue for the UnicodeDecodeError:
>> 
>> # echo $LANG
>> C.UTF-8
>> 
>> # diffoscope /.zfs/snapshot/2021-04-*-01:40:48-0/bin/sh
>> $<3/>2021-05-04 08:49:21 W: diffoscope.main: Fuzzy-matching is currently 
>> disabled as the "tlsh" module is unavailable.
>> $<3/>Traceback (most recent call last):
>> File "/usr/local/lib/python3.7/site-packages/diffoscope/main.py", line 745, 
>> in main
>>   sys.exit(run_diffoscope(parsed_args))
>> File "/usr/local/lib/python3.7/site-packages/diffoscope/main.py", line 677, 
>> in run_diffoscope
>>   difference = load_diff_from_path(path1)
>> File 
>> "/usr/local/lib/python3.7/site-packages/diffoscope/readers/__init__.py", 
>> line 31, in load_diff_from_path
>>   return load_diff(codecs.getreader("utf-8")(fp), path)
>> File 
>> "/usr/local/lib/python3.7/site-packages/diffoscope/readers/__init__.py", 
>> line 35, in load_diff
>>   return JSONReaderV1().load(fp, path)
>> File "/usr/local/lib/python3.7/site-packages/diffoscope/readers/json.py", 
>> line 33, in load
>>   raw = json.load(fp)
>> File "/usr/local/lib/python3.7/json/__init__.py", line 293, in load
>>   return loads(fp.read(),
>> File "/usr/local/lib/python3.7/codecs.py", line 504, in read
>>   newchars, decodedbytes = self.decode(data, self.errors)
>> UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb7 in position 18: 
>> invalid start byte
>> 
> 
> Well, the list of differing files is huge. But this seems to
> be .gnu_debuglink content for the area it is in.

Specifically: the last 4 bytes of the .gnu_debuglink section.

> I'll note
> that I did installworld but not the likes of distrib-dirs
> or distribution this time.
> 
> This test did buildworld to two distinct directories:
> 
> zroot/BUILDs/13_0R-CA72-nodbg-clang   5.13G   118G 5.13G  
> /usr/obj/BUILDs/13_0R-CA72-nodbg-clang
> zroot/BUILDs/13_0R-CA72-nodbg-clang-alt   4.28G   118G 4.28G  
> /usr/obj/BUILDs/13_0R-CA72-nodbg-clang-alt
> 
> and installworld to 2 distinct directories:
> 
> zroot/DESTDIRs/13_0R-CA72-instwrld-alt1.44G   118G 1.44G  
> /usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt
> zroot/DESTDIRs/13_0R-CA72-instwrld-norm   1.44G   118G 1.44G  
> /usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm
> 
> Previously (armv7 target) I had built, installed, rebuilt
> to same directory (after clean-out) and installed to an
> alternate directory. That had gotten only a few files
> different but I do not know (yet) if it was the procedural
> difference that made the difference.
> 
> Prefix of the list of different files this time:
> 
> # diff -rq /usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm/ 
> /usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt/ | more
> Files /usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm/bin/[ and 
> /usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt/bin/[ differ
> Files /usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm/bin/cat and 
> /usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt/bin/cat differ
> Files /usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm/bin/chflags and 
> /usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt/bin/chflags differ
> Files /usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm/bin/chio and 
> /usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt/bin/chio differ
> . . .
> 
> Looking, aarch64 seems to typically get a back-to-back
> sequence of 4 bytes different in native programs in my
> builds:
> 
> # cmp -x /usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm/bin/cat 
> /usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt/bin/cat
> 3bd4 1d 65
> 3bd5 eb a3
> 3bd6 bb ca
> 3bd7 8e 1a
> 
> # ls -Tld /usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm/bin/cat 
> /usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt/bin/cat
> -r-xr-xr-x  1 root  wheel  18448 May  4 08:55:01 2021 
> /usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt/bin/cat
> -r-xr-xr-x  1 root  wheel  18448 May  3 23:16:36 2021 
> /usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm/bin/cat
> 
> Sections:
> Idx Name  Size  VMA   LMA   File off  Algn
> . . .
> 25 .gnu_debuglink 0010      3bc8  2**0
>  CONTENTS, READONLY

Section 

Re: FYI: WITH_REPRODUCIBLE_BUILD= problem for some files?

[Mark Millard via freebsd-stable]

On 2021-May-4, at 08:51, Mark Millard  wrote:

> On 2021-May-4, at 06:01, Ed Maste  wrote:
> 
>> On Mon, 3 May 2021 at 22:26, Mark Millard  wrote:
>>> 
>>> But I'll note that I've built and stalled py37-diffoscope
>>> (new to me). A basic quick test showed that it reports:
>>> 
>>> W: diffoscope.main: Fuzzy-matching is currently disabled as the "tlsh" 
>>> module is unavailable.
>> 
>> I just looked up tlsh - its "A Locality Sensitive Hash"; I presume
>> diffoscope uses it to infer file renames. I believe the warning
>> emitted here should have no impact on the output we're looking for.
> 
> Okay.
> 
>> As far as the utf-8 issues go, diffoscope requires a utf-8 locale and
>> I suspect that is the issue. If you don't have LANG set already, try
>> setting LANG=C.UTF-8 in your environment.
> 
> That is not the issue for the UnicodeDecodeError:
> 
> # echo $LANG
> C.UTF-8
> 
> # diffoscope /.zfs/snapshot/2021-04-*-01:40:48-0/bin/sh
> $<3/>2021-05-04 08:49:21 W: diffoscope.main: Fuzzy-matching is currently 
> disabled as the "tlsh" module is unavailable.
> $<3/>Traceback (most recent call last):
>  File "/usr/local/lib/python3.7/site-packages/diffoscope/main.py", line 745, 
> in main
>sys.exit(run_diffoscope(parsed_args))
>  File "/usr/local/lib/python3.7/site-packages/diffoscope/main.py", line 677, 
> in run_diffoscope
>difference = load_diff_from_path(path1)
>  File 
> "/usr/local/lib/python3.7/site-packages/diffoscope/readers/__init__.py", line 
> 31, in load_diff_from_path
>return load_diff(codecs.getreader("utf-8")(fp), path)
>  File 
> "/usr/local/lib/python3.7/site-packages/diffoscope/readers/__init__.py", line 
> 35, in load_diff
>return JSONReaderV1().load(fp, path)
>  File "/usr/local/lib/python3.7/site-packages/diffoscope/readers/json.py", 
> line 33, in load
>raw = json.load(fp)
>  File "/usr/local/lib/python3.7/json/__init__.py", line 293, in load
>return loads(fp.read(),
>  File "/usr/local/lib/python3.7/codecs.py", line 504, in read
>newchars, decodedbytes = self.decode(data, self.errors)
> UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb7 in position 18: 
> invalid start byte
> 

Well, the list of differing files is huge. But this seems to
be .gnu_debuglink content for the area it is in. I'll note
that I did installworld but not the likes of distrib-dirs
or distribution this time.

This test did buildworld to two distinct directories:

zroot/BUILDs/13_0R-CA72-nodbg-clang   5.13G   118G 5.13G  
/usr/obj/BUILDs/13_0R-CA72-nodbg-clang
zroot/BUILDs/13_0R-CA72-nodbg-clang-alt   4.28G   118G 4.28G  
/usr/obj/BUILDs/13_0R-CA72-nodbg-clang-alt

and installworld to 2 distinct directories:

zroot/DESTDIRs/13_0R-CA72-instwrld-alt1.44G   118G 1.44G  
/usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt
zroot/DESTDIRs/13_0R-CA72-instwrld-norm   1.44G   118G 1.44G  
/usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm

Previously (armv7 target) I had built, installed, rebuilt
to same directory (after clean-out) and installed to an
alternate directory. That had gotten only a few files
different but I do not know (yet) if it was the procedural
difference that made the difference.

Prefix of the list of different files this time:

# diff -rq /usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm/ 
/usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt/ | more
Files /usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm/bin/[ and 
/usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt/bin/[ differ
Files /usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm/bin/cat and 
/usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt/bin/cat differ
Files /usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm/bin/chflags and 
/usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt/bin/chflags differ
Files /usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm/bin/chio and 
/usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt/bin/chio differ
. . .

Looking, aarch64 seems to typically get a back-to-back
sequence of 4 bytes different in native programs in my
builds:

# cmp -x /usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm/bin/cat 
/usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt/bin/cat
3bd4 1d 65
3bd5 eb a3
3bd6 bb ca
3bd7 8e 1a

# ls -Tld /usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm/bin/cat 
/usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt/bin/cat
-r-xr-xr-x  1 root  wheel  18448 May  4 08:55:01 2021 
/usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt/bin/cat
-r-xr-xr-x  1 root  wheel  18448 May  3 23:16:36 2021 
/usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm/bin/cat

Sections:
Idx Name  Size  VMA   LMA   File off  Algn
. . .
 25 .gnu_debuglink 0010      3bc8  2**0
  CONTENTS, READONLY

3bd4-3bc8 == 0xC

# cmp -x /usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm/bin/chflags 
/usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt/bin/chflags
2208 88 a1
2209 e6 40
220a 60 94
220b bf ce

# ls -Tld /usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm/bin/chflags 
/usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt/bin/chflags
-r-xr-xr-x  1 root  wheel  

Re: FYI: WITH_REPRODUCIBLE_BUILD= problem for some files?

[Ed Maste]

On Tue, 4 May 2021 at 11:52, Mark Millard  wrote:
>
> > As far as the utf-8 issues go, diffoscope requires a utf-8 locale and
> > I suspect that is the issue. If you don't have LANG set already, try
> > setting LANG=C.UTF-8 in your environment.
>
> That is not the issue for the UnicodeDecodeError:
>
> # echo $LANG
> C.UTF-8
>
> # diffoscope /.zfs/snapshot/2021-04-*-01:40:48-0/bin/sh
> [...]
> $<3/>2021-05-04 08:49:21 W: diffoscope.main: Fuzzy-matching is currently 
> disabled as the "tlsh" module is unavailable.
> UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb7 in position 18: 
> invalid start byte

Hmm, interesting - if you don't mind sharing I'd be interested in a
copy of /.zfs/snapshot/2021-04-*-01:40:48-0/bin/sh, in order to track
down what appears to be a diffoscope issue.

To investigate the non-reproducibility though we can just manually run
through the same sort of process that Diffoscope uses. I would suggest
cmp -x   to find the offsets of the difference(s), then
use readelf -S  to determine which section(s) have differences.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FYI: WITH_REPRODUCIBLE_BUILD= problem for some files?

[Mark Millard via freebsd-stable]

On 2021-May-4, at 06:01, Ed Maste  wrote:

> On Mon, 3 May 2021 at 22:26, Mark Millard  wrote:
>> 
>> But I'll note that I've built and stalled py37-diffoscope
>> (new to me). A basic quick test showed that it reports:
>> 
>> W: diffoscope.main: Fuzzy-matching is currently disabled as the "tlsh" 
>> module is unavailable.
> 
> I just looked up tlsh - its "A Locality Sensitive Hash"; I presume
> diffoscope uses it to infer file renames. I believe the warning
> emitted here should have no impact on the output we're looking for.

Okay.

> As far as the utf-8 issues go, diffoscope requires a utf-8 locale and
> I suspect that is the issue. If you don't have LANG set already, try
> setting LANG=C.UTF-8 in your environment.

That is not the issue for the UnicodeDecodeError:

# echo $LANG
C.UTF-8

# diffoscope /.zfs/snapshot/2021-04-*-01:40:48-0/bin/sh
$<3/>2021-05-04 08:49:21 W: diffoscope.main: Fuzzy-matching is currently 
disabled as the "tlsh" module is unavailable.
$<3/>Traceback (most recent call last):
  File "/usr/local/lib/python3.7/site-packages/diffoscope/main.py", line 745, 
in main
sys.exit(run_diffoscope(parsed_args))
  File "/usr/local/lib/python3.7/site-packages/diffoscope/main.py", line 677, 
in run_diffoscope
difference = load_diff_from_path(path1)
  File "/usr/local/lib/python3.7/site-packages/diffoscope/readers/__init__.py", 
line 31, in load_diff_from_path
return load_diff(codecs.getreader("utf-8")(fp), path)
  File "/usr/local/lib/python3.7/site-packages/diffoscope/readers/__init__.py", 
line 35, in load_diff
return JSONReaderV1().load(fp, path)
  File "/usr/local/lib/python3.7/site-packages/diffoscope/readers/json.py", 
line 33, in load
raw = json.load(fp)
  File "/usr/local/lib/python3.7/json/__init__.py", line 293, in load
return loads(fp.read(),
  File "/usr/local/lib/python3.7/codecs.py", line 504, in read
newchars, decodedbytes = self.decode(data, self.errors)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb7 in position 18: 
invalid start byte

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: bhyve and multiple network devices

[Juraj Lutter]

> On 4 May 2021, at 15:23, Shawn Webb  wrote:
> 
> Unfortunately, bhyve doesn't support renamed tap devices. You'll need
> to keep the original tapN name.
> 
> What you might want to experiment with is setting a description for
> the tap device. For example:
> 
> ifconfig tapN description "private vNIC"
> 

Fair enough. Anyway, I can specify the original name while also keeping the 
device in ifconfig’s output renamed.
It works.

I’ve been able to make a lab setup of 4x minio nodes, 1x frr router, all routed 
with BGP+ECMP.

otis

—
Juraj Lutter
o...@freebsd.org

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: bhyve and multiple network devices

[Shawn Webb]

On Mon, May 03, 2021 at 10:46:34PM +0200, Juraj Lutter wrote:
> Hi,
> 
> my bhyve command line (on 13.0-RELEASE) is:
> 
> /usr/sbin/bhyve -c 2 -m 4G -H -A -P -u -s 0:0,hostbridge -s 1:0,lpc -s 
> 2:0,virtio-net,tap100 -s 3:0,virtio-net,priv0 -s 
> 4:0,virtio-blk,/dev/zvol/zroot/data/minio/host0/root -l com1,/dev/nmdm100B mr
> 
> the result is:
> 
> device emulation initialization error: File exists
> 
> It works when using original interface name (tap105 in this case).
> 
> priv0 is renamed tap:
> priv0: flags=8902 metric 0 mtu 1500
> options=8
> ether 58:9c:fc:10:2b:0b
> groups: tap
> media: Ethernet autoselect
> status: no carrier
> nd6 options=29
> 
> Am I doing something inadequate, is this an expected behavior or is this a 
> kind of a bug?

Unfortunately, bhyve doesn't support renamed tap devices. You'll need
to keep the original tapN name.

What you might want to experiment with is setting a description for
the tap device. For example:

ifconfig tapN description "private vNIC"

Thanks,

-- 
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc


signature.asc
Description: PGP signature

Re: FYI: WITH_REPRODUCIBLE_BUILD= problem for some files?

[Ed Maste]

On Mon, 3 May 2021 at 22:26, Mark Millard  wrote:
>
> But I'll note that I've built and stalled py37-diffoscope
> (new to me). A basic quick test showed that it reports:
>
> W: diffoscope.main: Fuzzy-matching is currently disabled as the "tlsh" module 
> is unavailable.

I just looked up tlsh - its "A Locality Sensitive Hash"; I presume
diffoscope uses it to infer file renames. I believe the warning
emitted here should have no impact on the output we're looking for.

As far as the utf-8 issues go, diffoscope requires a utf-8 locale and
I suspect that is the issue. If you don't have LANG set already, try
setting LANG=C.UTF-8 in your environment.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FYI: WITH_REPRODUCIBLE_BUILD= problem for some files?

[Mark Millard via freebsd-stable]

On 2021-May-3, at 21:27, Mark Millard  wrote:

> On 2021-May-3, at 19:26, Mark Millard  wrote:
> 
>> On 2021-May-3, at 10:51, Mark Millard  wrote:
>> 
>>> On 2021-May-3, at 07:47, Ed Maste  wrote:
>>> 
 On Thu, 29 Apr 2021 at 02:50, Mark Millard via freebsd-current
  wrote:
> 
> Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/sbin/ping and 
> /usr/obj/DESTDIRs/13_0R-CA7-poud/sbin/ping differ
> Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/sbin/ping6 and 
> /usr/obj/DESTDIRs/13_0R-CA7-poud/sbin/ping6 differ
> Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/usr/bin/ntpq and 
> /usr/obj/DESTDIRs/13_0R-CA7-poud/usr/bin/ntpq differ...
 
 This is unexpected. Unfortunately I haven't looked at reproducibility
 in a while, and my work was all on x86. This could be a regression or
 a longstanding issue with arm64.
 
 If you install the diffoscope package (py37-diffoscope) and run it on
 the two directories / files it should give a more convenient view of
 the differences. (Or, if you can make a tarball of the differing files
 I can take a look.)
>>> 
>>> I no longer have the same content in those directory
>>> trees: newer rebuild and the same buildworld used to
>>> installworld to both places, instead of 2 different
>>> buildworld's. I'm also unsure how reproducible getting
>>> differences was.
>>> 
>>> I can eventually do experiments to test multiple separate
>>> buildworld's and installworld's, but the machine is busy
>>> building ports and the llvm builds involved means it
>>> will be some time before I'd switch activities. And the
>>> buildworld's involve llvm builds as well and take notable
>>> time themselves. So my next comparison will not be any
>>> time soon.
>>> 
>>> I'll let you know if I manage to generate another example,
>>> this time being sure to keep the data. If I try multiple
>>> times without finding any differences, I'll eventually
>>> decide "enough is enough" and let you know.
>> 
>> I've still got a long ways to go to do the first
>> actual comparison of builds.
>> 
>> But I'll note that I've built and stalled py37-diffoscope
>> (new to me). A basic quick test showed that it reports:
>> 
>> W: diffoscope.main: Fuzzy-matching is currently disabled as the "tlsh" 
>> module is unavailable.
>> 
>> As I'm not familiar with the tool, you might need to send
>> notes about how you want me to use the tool to get the
>> output that you would want. (And, so, I get to learn . . .)
> 
> I've tried another experiment (* in the path matches "28" and "30"):
> 
> # diffoscope /.zfs/snapshot/2021-04-*-01:40:48-0/bin/sh
> $<3/>2021-05-03 21:08:48 W: diffoscope.main: Fuzzy-matching is currently 
> disabled as the "tlsh" module is unavailable.
> $<3/>Traceback (most recent call last):
>  File "/usr/local/lib/python3.7/site-packages/diffoscope/main.py", line 745, 
> in main
>sys.exit(run_diffoscope(parsed_args))
>  File "/usr/local/lib/python3.7/site-packages/diffoscope/main.py", line 677, 
> in run_diffoscope
>difference = load_diff_from_path(path1)
>  File 
> "/usr/local/lib/python3.7/site-packages/diffoscope/readers/__init__.py", line 
> 31, in load_diff_from_path
>return load_diff(codecs.getreader("utf-8")(fp), path)
>  File 
> "/usr/local/lib/python3.7/site-packages/diffoscope/readers/__init__.py", line 
> 35, in load_diff
>return JSONReaderV1().load(fp, path)
>  File "/usr/local/lib/python3.7/site-packages/diffoscope/readers/json.py", 
> line 33, in load
>raw = json.load(fp)
>  File "/usr/local/lib/python3.7/json/__init__.py", line 293, in load
>return loads(fp.read(),
>  File "/usr/local/lib/python3.7/codecs.py", line 504, in read
>newchars, decodedbytes = self.decode(data, self.errors)
> UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb7 in position 18: 
> invalid start byte
> 
> The two older snapshots of a Boot Environment have
> bin/sh files that compare equal. But every program I
> tried the above sort of thing against on got the same
> UnicodeDecodeError result from diffoscope, byte value
> and position matching.
> 
> These snapshots have more than an installworld in them
> and so are messy to compare overall. But the
> installworld (and installkernel) content show similar
> differences to what I reported before as far as
> example files with differences go. But this is aarch64,
> not armv7.
> 
> It will still be notable time before I have simple
> installworld tree's to compare.

While waiting for the 2nd buildworld to complete, I used
the 1st buildworld's materials to installworld twice (to
different, empty directory trees) and then did a diff.
The diff reported:

# diff -rq /usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm/ 
/usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm2/ | more
diff: /usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm/usr/tests/local: No such file 
or directory
diff: 

Re: FYI: WITH_REPRODUCIBLE_BUILD= problem for some files?

[Mark Millard via freebsd-stable]

On 2021-May-3, at 19:26, Mark Millard  wrote:

> On 2021-May-3, at 10:51, Mark Millard  wrote:
> 
>> On 2021-May-3, at 07:47, Ed Maste  wrote:
>> 
>>> On Thu, 29 Apr 2021 at 02:50, Mark Millard via freebsd-current
>>>  wrote:
 
 Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/sbin/ping and 
 /usr/obj/DESTDIRs/13_0R-CA7-poud/sbin/ping differ
 Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/sbin/ping6 and 
 /usr/obj/DESTDIRs/13_0R-CA7-poud/sbin/ping6 differ
 Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/usr/bin/ntpq and 
 /usr/obj/DESTDIRs/13_0R-CA7-poud/usr/bin/ntpq differ...
>>> 
>>> This is unexpected. Unfortunately I haven't looked at reproducibility
>>> in a while, and my work was all on x86. This could be a regression or
>>> a longstanding issue with arm64.
>>> 
>>> If you install the diffoscope package (py37-diffoscope) and run it on
>>> the two directories / files it should give a more convenient view of
>>> the differences. (Or, if you can make a tarball of the differing files
>>> I can take a look.)
>> 
>> I no longer have the same content in those directory
>> trees: newer rebuild and the same buildworld used to
>> installworld to both places, instead of 2 different
>> buildworld's. I'm also unsure how reproducible getting
>> differences was.
>> 
>> I can eventually do experiments to test multiple separate
>> buildworld's and installworld's, but the machine is busy
>> building ports and the llvm builds involved means it
>> will be some time before I'd switch activities. And the
>> buildworld's involve llvm builds as well and take notable
>> time themselves. So my next comparison will not be any
>> time soon.
>> 
>> I'll let you know if I manage to generate another example,
>> this time being sure to keep the data. If I try multiple
>> times without finding any differences, I'll eventually
>> decide "enough is enough" and let you know.
> 
> I've still got a long ways to go to do the first
> actual comparison of builds.
> 
> But I'll note that I've built and stalled py37-diffoscope
> (new to me). A basic quick test showed that it reports:
> 
> W: diffoscope.main: Fuzzy-matching is currently disabled as the "tlsh" module 
> is unavailable.
> 
> As I'm not familiar with the tool, you might need to send
> notes about how you want me to use the tool to get the
> output that you would want. (And, so, I get to learn . . .)

I've tried another experiment (* in the path matches "28" and "30"):

# diffoscope /.zfs/snapshot/2021-04-*-01:40:48-0/bin/sh
$<3/>2021-05-03 21:08:48 W: diffoscope.main: Fuzzy-matching is currently 
disabled as the "tlsh" module is unavailable.
$<3/>Traceback (most recent call last):
  File "/usr/local/lib/python3.7/site-packages/diffoscope/main.py", line 745, 
in main
sys.exit(run_diffoscope(parsed_args))
  File "/usr/local/lib/python3.7/site-packages/diffoscope/main.py", line 677, 
in run_diffoscope
difference = load_diff_from_path(path1)
  File "/usr/local/lib/python3.7/site-packages/diffoscope/readers/__init__.py", 
line 31, in load_diff_from_path
return load_diff(codecs.getreader("utf-8")(fp), path)
  File "/usr/local/lib/python3.7/site-packages/diffoscope/readers/__init__.py", 
line 35, in load_diff
return JSONReaderV1().load(fp, path)
  File "/usr/local/lib/python3.7/site-packages/diffoscope/readers/json.py", 
line 33, in load
raw = json.load(fp)
  File "/usr/local/lib/python3.7/json/__init__.py", line 293, in load
return loads(fp.read(),
  File "/usr/local/lib/python3.7/codecs.py", line 504, in read
newchars, decodedbytes = self.decode(data, self.errors)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb7 in position 18: 
invalid start byte

The two older snapshots of a Boot Environment have
bin/sh files that compare equal. But every program I
tried the above sort of thing against on got the same
UnicodeDecodeError result from diffoscope, byte value
and position matching.

These snapshots have more than an installworld in them
and so are messy to compare overall. But the
installworld (and installkernel) content show similar
differences to what I reported before as far as
example files with differences go. But this is aarch64,
not armv7.

It will still be notable time before I have simple
installworld tree's to compare.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FYI: WITH_REPRODUCIBLE_BUILD= problem for some files?

[Mark Millard via freebsd-stable]

On 2021-May-3, at 10:51, Mark Millard  wrote:

> On 2021-May-3, at 07:47, Ed Maste  wrote:
> 
>> On Thu, 29 Apr 2021 at 02:50, Mark Millard via freebsd-current
>>  wrote:
>>> 
>>> Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/sbin/ping and 
>>> /usr/obj/DESTDIRs/13_0R-CA7-poud/sbin/ping differ
>>> Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/sbin/ping6 and 
>>> /usr/obj/DESTDIRs/13_0R-CA7-poud/sbin/ping6 differ
>>> Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/usr/bin/ntpq and 
>>> /usr/obj/DESTDIRs/13_0R-CA7-poud/usr/bin/ntpq differ...
>> 
>> This is unexpected. Unfortunately I haven't looked at reproducibility
>> in a while, and my work was all on x86. This could be a regression or
>> a longstanding issue with arm64.
>> 
>> If you install the diffoscope package (py37-diffoscope) and run it on
>> the two directories / files it should give a more convenient view of
>> the differences. (Or, if you can make a tarball of the differing files
>> I can take a look.)
> 
> I no longer have the same content in those directory
> trees: newer rebuild and the same buildworld used to
> installworld to both places, instead of 2 different
> buildworld's. I'm also unsure how reproducible getting
> differences was.
> 
> I can eventually do experiments to test multiple separate
> buildworld's and installworld's, but the machine is busy
> building ports and the llvm builds involved means it
> will be some time before I'd switch activities. And the
> buildworld's involve llvm builds as well and take notable
> time themselves. So my next comparison will not be any
> time soon.
> 
> I'll let you know if I manage to generate another example,
> this time being sure to keep the data. If I try multiple
> times without finding any differences, I'll eventually
> decide "enough is enough" and let you know.

I've still got a long ways to go to do the first
actual comparison of builds.

But I'll note that I've built and stalled py37-diffoscope
(new to me). A basic quick test showed that it reports:

W: diffoscope.main: Fuzzy-matching is currently disabled as the "tlsh" module 
is unavailable.

As I'm not familiar with the tool, you might need to send
notes about how you want me to use the tool to get the
output that you would want. (And, so, I get to learn . . .)

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

bhyve and multiple network devices

[Juraj Lutter]

Hi,

my bhyve command line (on 13.0-RELEASE) is:

/usr/sbin/bhyve -c 2 -m 4G -H -A -P -u -s 0:0,hostbridge -s 1:0,lpc -s 
2:0,virtio-net,tap100 -s 3:0,virtio-net,priv0 -s 
4:0,virtio-blk,/dev/zvol/zroot/data/minio/host0/root -l com1,/dev/nmdm100B mr

the result is:

device emulation initialization error: File exists

It works when using original interface name (tap105 in this case).

priv0 is renamed tap:
priv0: flags=8902 metric 0 mtu 1500
options=8
ether 58:9c:fc:10:2b:0b
groups: tap
media: Ethernet autoselect
status: no carrier
nd6 options=29

Am I doing something inadequate, is this an expected behavior or is this a kind 
of a bug?

Thanks.
otis

—
Juraj Lutter
XMPP: juraj (at) lutter.sk
GSM: +421907986576

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FYI: WITH_REPRODUCIBLE_BUILD= problem for some files?

[Mark Millard via freebsd-stable]

On 2021-May-3, at 07:47, Ed Maste  wrote:

> On Thu, 29 Apr 2021 at 02:50, Mark Millard via freebsd-current
>  wrote:
>> 
>> Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/sbin/ping and 
>> /usr/obj/DESTDIRs/13_0R-CA7-poud/sbin/ping differ
>> Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/sbin/ping6 and 
>> /usr/obj/DESTDIRs/13_0R-CA7-poud/sbin/ping6 differ
>> Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/usr/bin/ntpq and 
>> /usr/obj/DESTDIRs/13_0R-CA7-poud/usr/bin/ntpq differ...
> 
> This is unexpected. Unfortunately I haven't looked at reproducibility
> in a while, and my work was all on x86. This could be a regression or
> a longstanding issue with arm64.
> 
> If you install the diffoscope package (py37-diffoscope) and run it on
> the two directories / files it should give a more convenient view of
> the differences. (Or, if you can make a tarball of the differing files
> I can take a look.)

I no longer have the same content in those directory
trees: newer rebuild and the same buildworld used to
installworld to both places, instead of 2 different
buildworld's. I'm also unsure how reproducible getting
differences was.

I can eventually do experiments to test multiple separate
buildworld's and installworld's, but the machine is busy
building ports and the llvm builds involved means it
will be some time before I'd switch activities. And the
buildworld's involve llvm builds as well and take notable
time themselves. So my next comparison will not be any
time soon.

I'll let you know if I manage to generate another example,
this time being sure to keep the data. If I try multiple
times without finding any differences, I'll eventually
decide "enough is enough" and let you know.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FYI: WITH_REPRODUCIBLE_BUILD= problem for some files?

[Ed Maste]

On Thu, 29 Apr 2021 at 02:50, Mark Millard via freebsd-current
 wrote:
>
> Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/sbin/ping and 
> /usr/obj/DESTDIRs/13_0R-CA7-poud/sbin/ping differ
> Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/sbin/ping6 and 
> /usr/obj/DESTDIRs/13_0R-CA7-poud/sbin/ping6 differ
> Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/usr/bin/ntpq and 
> /usr/obj/DESTDIRs/13_0R-CA7-poud/usr/bin/ntpq differ...

This is unexpected. Unfortunately I haven't looked at reproducibility
in a while, and my work was all on x86. This could be a regression or
a longstanding issue with arm64.

If you install the diffoscope package (py37-diffoscope) and run it on
the two directories / files it should give a more convenient view of
the differences. (Or, if you can make a tarball of the differing files
I can take a look.)
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: wanna solve the Linux NFSv4 client puzzle?

[Alan Somers]

On Sun, May 2, 2021 at 6:27 PM Rick Macklem  wrote:

> Rick Macklem wrote:
> >Hi,
> >
> >I posted recently that enabling delegations should be avoided at this
> time,
> >especially if your FreeBSD NFS server has Linux client mounts...
> >
> >I thought some of you might be curious why, and I thought it would be
> >more fun if you look for yourselves.
> >To play the game, you need to download a packet capture:
> >fetch https://people.freebsd.org/~rmacklem/twoclientdeleg.pcap
> >and then load it into wireshark.
> >
> >192.168.1.5 - FreeBSD server with all recent patches
> >192.168.1.6 - FedoraCore 30 (Linux 5.2 kernel) client
> >192.168.1.13 - FreeBSD client
> >
> >A few hints buried in RFC5661:
> >- A fore channel is used for normal client->server RPCs and a back channel
> >  is used for server->client callback RPCs.
> >- After a new TCP is created, neither the fore nor back channels
> >  are bound to the connection.
> >- Bindings channel(s) to a connection is done by BindConnectionToSession.
> >  but an implicit binding for the fore channel is created when the first
> RPC
> >  request with a Sequence operation in it is sent on the new TCP
> connection.
> >- A server->client callback cannot be done until the back channel is bound
> >  via BindConnectionToServer.
> >
> >Ok, so we are ready...
> >- Look at packet #s 3518->3605.
> >  - What is going on here?
> Ok, so here's my solution...
> packet #3518, 3520 and 3521 are delegation recalls (CB_RECALL)
> for 3 different delegations on three different session slots.
> time: 137.5
>
> Expected response from the Linux client--> 3 replies to the CB_RECALLs.
> What does it actually do?
> --> Creates a new TCP connection using same port#. You can see it send
>   a FIN (packet# 3523) and a SYN (packet# 3527).
>   This means that the client is no longer obliged to reply to the
> CB_RECALLs
>   and the FreeBSD server will probably need to retry them.
>   --> It also means that no back channel is bound to the session, so
> the
>  server cannot do callbacks (ie. cannot retry the CB_RECALLs
> yet).
>
> packet# 3530 is a Setattr RPC, which has a Sequence operation in it.
> --> This means the fore channel is implicitly bound to the new TCP
>   connection, but no back channel, so the server cannot retry the
> CB_RECALLs.
>
> You will notice a bunch of Setattr RPCs getting NFS4ERR_DELAY replies.
> This tells the Linux client to "try again later".
> --> It happens because the FreeBSD server cannot perform the Setattr
>   until the client returns a delegation.
>   --> That requires a CB_RECALL.
>
> packet# 3582 is a Setattr RPC reply. If you look in the Sequence operation
> reply, you will see the flag SEQ4_STATUS_CB_PATH_DOWN is set.
> --> This is the FreeBSD server telling the Linux client that the callback
> path
>is down (the back channel is not bound to the new TCP connection).
> Time: 137.6  (took about 0.1sec for the server to notice that the callback
>  path/back channel is not working).
>
> packet# 3604 Linux client does a BindConnectionToSession to bind the
>back channel.
> --> This is not permitted by RFC5661, since it is required to be done on
>   the new TCP connection before the implicit binding of the fore
>   channel only, already done by packet# 3530.
> packet# 3605 FreeBSD server violates RFC5661 and allows the binding
>  to be done, so that CB_RECALLs can again be done.
> Time: 152.7
>
>   - How long does this take?
> 152.7 - 137.5 = 15.2seconds
>
> >--> One more hint. Starting with #3605, things are working again.
>   --> Things start working again because the FreeBSD server
> cheats and allows the BindConnectionToSession to be done.
> RFC5661 specifies a reply of NFS4ERR_INVAL for this.
>
> >There are actually 3 other examples of this in the pack capture.
> Every time multiple concurrent callbacks are attempted, the Linux
> client "bails out" by creating a new TCP connection.
> --> This is said to be fixed in Linux 5.3, but I haven't tested a newer
>kernel than 5.2 yet.
>
> >Btw, one of the weirdnesses is said to be fixed in Linux 5.3 and the other
> >in Linux 5.7, although I have not yet upgraded my kernel and tested this.
> The "do BindConnectionToSession after an implicit binding" is said to be
> fixed
> in Linux 5.7, however the fix is not exactly what I would have expected.
> --> I would have expected a BindConnectionToSession to be done right
>   away when a new TCP connection is created.
>   --> Linux 5.7 and newer is said to still wait (15sec?) to do the
> BindConnectionToSession, but fixes the bug by creating yet
> another new TCP connection just before doing the
> BindConnectionToSession RPC.
>   --> A SEQ4_STATUS_CB_PATH_DOWN flag set in a Sequence operation
> reply is what triggers the BindConnectionToSession and that is
> still
> required for 5.7 

Re: wanna solve the Linux NFSv4 client puzzle?

[Rick Macklem]

Rick Macklem wrote:
>Hi,
>
>I posted recently that enabling delegations should be avoided at this time,
>especially if your FreeBSD NFS server has Linux client mounts...
>
>I thought some of you might be curious why, and I thought it would be
>more fun if you look for yourselves.
>To play the game, you need to download a packet capture:
>fetch https://people.freebsd.org/~rmacklem/twoclientdeleg.pcap
>and then load it into wireshark.
>
>192.168.1.5 - FreeBSD server with all recent patches
>192.168.1.6 - FedoraCore 30 (Linux 5.2 kernel) client
>192.168.1.13 - FreeBSD client
>
>A few hints buried in RFC5661:
>- A fore channel is used for normal client->server RPCs and a back channel
>  is used for server->client callback RPCs.
>- After a new TCP is created, neither the fore nor back channels
>  are bound to the connection.
>- Bindings channel(s) to a connection is done by BindConnectionToSession.
>  but an implicit binding for the fore channel is created when the first RPC
>  request with a Sequence operation in it is sent on the new TCP connection.
>- A server->client callback cannot be done until the back channel is bound
>  via BindConnectionToServer.
>
>Ok, so we are ready...
>- Look at packet #s 3518->3605.
>  - What is going on here?
Ok, so here's my solution...
packet #3518, 3520 and 3521 are delegation recalls (CB_RECALL)
for 3 different delegations on three different session slots.
time: 137.5

Expected response from the Linux client--> 3 replies to the CB_RECALLs.
What does it actually do?
--> Creates a new TCP connection using same port#. You can see it send
  a FIN (packet# 3523) and a SYN (packet# 3527).
  This means that the client is no longer obliged to reply to the CB_RECALLs
  and the FreeBSD server will probably need to retry them.
  --> It also means that no back channel is bound to the session, so the
 server cannot do callbacks (ie. cannot retry the CB_RECALLs yet).

packet# 3530 is a Setattr RPC, which has a Sequence operation in it.
--> This means the fore channel is implicitly bound to the new TCP
  connection, but no back channel, so the server cannot retry the 
CB_RECALLs.

You will notice a bunch of Setattr RPCs getting NFS4ERR_DELAY replies.
This tells the Linux client to "try again later".
--> It happens because the FreeBSD server cannot perform the Setattr
  until the client returns a delegation.
  --> That requires a CB_RECALL.

packet# 3582 is a Setattr RPC reply. If you look in the Sequence operation
reply, you will see the flag SEQ4_STATUS_CB_PATH_DOWN is set.
--> This is the FreeBSD server telling the Linux client that the callback path
   is down (the back channel is not bound to the new TCP connection).
Time: 137.6  (took about 0.1sec for the server to notice that the callback
 path/back channel is not working).

packet# 3604 Linux client does a BindConnectionToSession to bind the
   back channel.
--> This is not permitted by RFC5661, since it is required to be done on
  the new TCP connection before the implicit binding of the fore
  channel only, already done by packet# 3530.
packet# 3605 FreeBSD server violates RFC5661 and allows the binding
 to be done, so that CB_RECALLs can again be done.
Time: 152.7

  - How long does this take?
152.7 - 137.5 = 15.2seconds

>--> One more hint. Starting with #3605, things are working again.
  --> Things start working again because the FreeBSD server
cheats and allows the BindConnectionToSession to be done.
RFC5661 specifies a reply of NFS4ERR_INVAL for this.

>There are actually 3 other examples of this in the pack capture.
Every time multiple concurrent callbacks are attempted, the Linux
client "bails out" by creating a new TCP connection.
--> This is said to be fixed in Linux 5.3, but I haven't tested a newer
   kernel than 5.2 yet.

>Btw, one of the weirdnesses is said to be fixed in Linux 5.3 and the other
>in Linux 5.7, although I have not yet upgraded my kernel and tested this.
The "do BindConnectionToSession after an implicit binding" is said to be fixed
in Linux 5.7, however the fix is not exactly what I would have expected.
--> I would have expected a BindConnectionToSession to be done right
  away when a new TCP connection is created.
  --> Linux 5.7 and newer is said to still wait (15sec?) to do the
BindConnectionToSession, but fixes the bug by creating yet
another new TCP connection just before doing the
BindConnectionToSession RPC.
  --> A SEQ4_STATUS_CB_PATH_DOWN flag set in a Sequence operation
reply is what triggers the BindConnectionToSession and that is still
required for 5.7 or newer, but I'll need to test to see how long it 
takes
for newer kernels?

The old "cheat", which is still in the released server code (recently removed
by a patch in main, stable/12 and stable/13) implicitly bound both the fore
and back 

Re: FreeBSD 13.0 terrible performance in KVM

[Crest]

On 25.04.21 11:15, dashdruid via freebsd-stable wrote:


Hello,

I have reinstalled it with GPT/ZFS and your right it's much better. Same search 
taking 3-6 seconds so I have deleted now all my old UFS based FreeBSD images.


If the partitioning alone changed something it was probably an alignment 
problem. These are things you can try:


* Create a VM with two virtual disks.

* Install a UFS system on the first disk.

* Create and mount a UFS on the unpartitioned second disk.

* Copy the whole system with tar to the second disk.

* Reboot the VM.

* Compare performance on both file disks.

Maybe your virtual disk backend is is just terrible with unaligned accesses.

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

mergemaster (was: Congratulations on the stable/13 release!)

[Felix Palmen]

* Andrew Reilly  [20210501 11:45]:
> mergemaster -p
> make -s installworld
> mergemaster -U

Note you shouldn't use mergemaster any more. It works fine for upgrading
to 13, but after that, I'd expect problems because it relies on the old
VCS tags. Use etcupdate instead, see here for details:


It's also documented in the handbook:


-- 
 Dipl.-Inform. Felix Palmen ,.//..
 {web}  http://palmen-it.de  {jabber} [see email]   ,//palmen-it.de
 {pgp public key} http://palmen-it.de/pub.txt   //   """
 {pgp fingerprint} A891 3D55 5F2E 3A74 3965 B997 3EF2 8B0A BC02 DA2A


signature.asc
Description: PGP signature

Re: Congratulations on the stable/13 release!

[Peter Libassi]

> 1 maj 2021 kl. 03:45 skrev Andrew Reilly :
> 
> In case anyone's interested: for this morning's software maintenance 
> session (at home) I upgraded my file server from FreeBSD stable/12
> to the recently released stable/13.  From source, in-place, on a
> running, on-line system.  Despite the fact that the entire ZFS
> subsystem has been replaced, which is what caused me to wait for a
> couple of weeks, the upgrade appears to have been flawless.  Not a
> single error message on boot-up.  Not a single failed service.
> Everything is working perfectly.  Zpool status told me that I should
> upgrade the pools, and did: that turned on a dozen or so new features
> that I'm sure are useful.  Total downtime about a minute or so:
> just the time it took to reboot.  I'm amazed.  Good on the FreeBSD
> developers and (especially) the release engineers!
> 
> cd /usr/src
> git switch stable/13
> make -s -j20 buildworld kernel
> mergemaster -p
> make -s installworld
> mergemaster -U
> shutdown -r now
> 
> zpool status
> zpool upgrade backup20
> zpool upgrade root
> zpool upgrade tank
> 
> Done!
> 
> Cheers,
> 
> Andrew
> 
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org”


I will join the gratulations! I’ve also upgraded my home NAS server and my 
remote Backup server without a glitch including upgrade of ZFS and all ports. 
Everything now works as on 12.2.

freebsd-update -r 13.0-RELEASE upgrade
/usr/sbin/freebsd-update install
fix /etc/ssh/sshd_conf
shutdown -r now
freebsd-update install
pkg-static install -f pkg
pkg bootstrap -f
pkg update
pkg upgrade
freebsd-update install
shutdown -r now
zpool upgrade nas

Excellent work from the FreeBSD team!

Thanks
Peter

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Congratulations on the stable/13 release!

[Andrew Reilly]

In case anyone's interested: for this morning's software maintenance 
session (at home) I upgraded my file server from FreeBSD stable/12
to the recently released stable/13.  From source, in-place, on a
running, on-line system.  Despite the fact that the entire ZFS
subsystem has been replaced, which is what caused me to wait for a
couple of weeks, the upgrade appears to have been flawless.  Not a
single error message on boot-up.  Not a single failed service.
Everything is working perfectly.  Zpool status told me that I should
upgrade the pools, and did: that turned on a dozen or so new features
that I'm sure are useful.  Total downtime about a minute or so:
just the time it took to reboot.  I'm amazed.  Good on the FreeBSD
developers and (especially) the release engineers!

cd /usr/src
git switch stable/13
make -s -j20 buildworld kernel
mergemaster -p
make -s installworld
mergemaster -U
shutdown -r now

zpool status
zpool upgrade backup20
zpool upgrade root
zpool upgrade tank

Done!

Cheers,

Andrew

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: How to make 'named' rc script invokded earlier at boot time

[Chris]

On 2021-04-30 00:30, Yasuhiro Kimura wrote:

I installed dns/bind916 on my home server and configured it so it
worked as both authoritative and recursor. Then I added
'nameserver 127.0.0.1' to /etc/resolv.conf and everything worked fine.

But after updating OS from 12.2-RELEASE to 13.0-RELEASE I noticed
execution of some rc scripts fails at boot time because of DNS lookup
error. And I also found these scripts are executed earlier than
'named'.

I've been plagued with this for years (well, a couple anyways) on several
of my servers. As I never saw anyone else mention it. I assumed it was just
"me". ;-)
rc(8) has a mountlate. Seems to me there ought to be a "startlate" key as
well. While this won't fix the cause introduced. It might at least solve
the problem.
create an /etc/rc.conf.local and move your host/nic related things into
it followed by your "named" entry. Leaving everything else in /etc/rc.conf
This (should) source all the rc.conf.local entries ahead of the rc.conf
entries. Thereby providing name resolution before ntpdate(8)/time sync
service(s)

HTH

--Chris


Now let me use 'ntpdate' as an example.

If I run `rcorder /etc/rc.d/* /usr/local/etc/rc.d/*` on 12.2-RELEASE,
then I get following result.

--
root@rolling-vm-freebsd3[474]# uname -a
FreeBSD rolling-vm-freebsd3.home.utahime.org 12.2-RELEASE-p6 FreeBSD
12.2-RELEASE-p6 GENERIC  amd64
root@rolling-vm-freebsd3[475]# rcorder /etc/rc.d/* /usr/local/etc/rc.d/*
/etc/rc.d/growfs
/etc/rc.d/sysctl
/etc/rc.d/hostid
/etc/rc.d/zvol
/etc/rc.d/dumpon
(snip)
/etc/rc.d/static_arp
/etc/rc.d/bridge
/etc/rc.d/route6d
/etc/rc.d/NETWORKING
/etc/rc.d/mountcritremote
/etc/rc.d/devfs
/etc/rc.d/ipmon
/etc/rc.d/kdc
/etc/rc.d/mdconfig2
/etc/rc.d/newsyslog
/etc/rc.d/syslogd
/usr/local/etc/rc.d/tcsd
/usr/local/etc/rc.d/named
/etc/rc.d/watchdogd
/etc/rc.d/savecore
/etc/rc.d/archdep
/etc/rc.d/linux
/etc/rc.d/sysvipc
/etc/rc.d/SERVERS
/usr/local/etc/rc.d/tpmd
/usr/local/etc/rc.d/stunnel
/etc/rc.d/accounting
/etc/rc.d/ntpdate
/etc/rc.d/rpcbind
/etc/rc.d/nfsclient
/etc/rc.d/nisdomain
(snip)
--

As you can see, while 'named' is executed before SERVERS, 'ntpdate' is
done after it.

On the other hand I get following result on 13.0-RELEASE.

--
root@rolling-vm-freebsd2[332]# uname -a
FreeBSD rolling-vm-freebsd2.home.utahime.org 13.0-RELEASE FreeBSD 
13.0-RELEASE #0

releng/13.0-n244733-ea31abc261f: Fri Apr  9 04:24:09 UTC 2021
r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64
root@rolling-vm-freebsd2[333]# rcorder /etc/rc.d/* /usr/local/etc/rc.d/*
/etc/rc.d/dhclient
/etc/rc.d/dumpon
/etc/rc.d/growfs
/etc/rc.d/natd
(snip)
/etc/rc.d/netwait
/etc/rc.d/blacklistd
/etc/rc.d/local_unbound
/etc/rc.d/NETWORKING
/etc/rc.d/pppoed
/etc/rc.d/kdc
/etc/rc.d/kfd
/etc/rc.d/nfsuserd
/etc/rc.d/iscsid
/etc/rc.d/ipropd_slave
/etc/rc.d/nfscbd
/etc/rc.d/iscsictl
/etc/rc.d/ipropd_master
/etc/rc.d/kadmind
/etc/rc.d/kpasswdd
/etc/rc.d/mountcritremote
/etc/rc.d/wpa_supplicant
/etc/rc.d/motd
/etc/rc.d/accounting
/etc/rc.d/cleartmp
/etc/rc.d/dmesg
/etc/rc.d/archdep
/etc/rc.d/gptboot
/etc/rc.d/hostapd
/etc/rc.d/virecover
/etc/rc.d/mdconfig2
/etc/rc.d/devfs
/etc/rc.d/os-release
/etc/rc.d/newsyslog
/etc/rc.d/linux
/etc/rc.d/syslogd
/etc/rc.d/sysvipc
/etc/rc.d/watchdogd
/etc/rc.d/savecore
/etc/rc.d/ntpdate
/etc/rc.d/localpkg
/etc/rc.d/auditd
/etc/rc.d/bsnmpd
/etc/rc.d/pwcheck
/etc/rc.d/power_profile
/etc/rc.d/rpcbind
/etc/rc.d/auditdistd
/usr/local/etc/rc.d/named
/etc/rc.d/nfsclient
/etc/rc.d/hastd
/etc/rc.d/SERVERS
/etc/rc.d/nisdomain
/usr/local/etc/rc.d/stunnel
/usr/local/etc/rc.d/tpmd
/usr/local/etc/rc.d/tcsd
(snip)
--

Now both 'named' and 'ntpdate' are executed before SERVERS. And
unfortunately the latter is earlier than the former. So it is natural
that execution of 'ntpdate' fails with DNS lookup failure.

I compared ntpdate rc script between releng/12.2 and releng/13.0 but
there is no difference.

--
yasu@rolling-vm-freebsd2[1035]% pwd
/usr/src
yasu@rolling-vm-freebsd2[1036]% git diff origin/releng/12.2 
origin/releng/13.0  --

libexec/rc/rc.d/ntpdate
yasu@rolling-vm-freebsd2[1037]%
--

And of cource there is no difference with /usr/local/etc/rc.d/named
either. So it seems evaluation of rcorder(8) is changed between
12.2-RELASE and 13.0-RELEASE.

Then is there any way to make 'named' rc script invoked earlier at
boot time on 13.0-RELEASE?

Best Regards.

---
Yasuhiro Kimura
___
freebsd-po...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to 

Re: How to make 'named' rc script invokded earlier at boot time

[Eugene Grosbein]

30.04.2021 14:30, Yasuhiro Kimura wrote:
> I installed dns/bind916 on my home server and configured it so it
> worked as both authoritative and recursor. Then I added
> 'nameserver 127.0.0.1' to /etc/resolv.conf and everything worked fine.
> 
> But after updating OS from 12.2-RELEASE to 13.0-RELEASE I noticed
> execution of some rc scripts fails at boot time because of DNS lookup
> error. And I also found these scripts are executed earlier than
> 'named'.
> 
> Now let me use 'ntpdate' as an example.

named sometimes *requires* correct time to be set before it is started,
so you should either use some IP addressess for NTP bootstrapping at boot time,
or put NTP server hostname to /etc/hosts with its IP, so it resolves before 
named fires.


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: How to make 'named' rc script invokded earlier at boot time

[Yasuhiro Kimura]

From: b56...@oldach.net (Helge Oldach)
Subject: Re: How to make 'named' rc script invokded earlier at boot time
Date: Fri, 30 Apr 2021 11:25:03 +0200 (CEST)

> Looks like this is caused by security/trousers which has "BEFORE: named 
> hastd". This port had been touched 3 weeks ago.

You provide me very good hint!

On my home server security/trousers and emulators/tpm-emulator are
installed as dependencies of security/gnutls. They install
/usr/local/etc/rc.d/tcsd and /usr/local/etc/rc.d/tpmd respectivley.
And there is circular dependency between these 2 rc srcipts and
/usr/local/etc/rc.d/named.

--
root@eastasia[1067]# rcorder /etc/rc.d/* /usr/local/etc/rc.d/* > /dev/null
rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown provision `kerberos'
rcorder: Circular dependency on file `/usr/local/etc/rc.d/named'.
rcorder: Circular dependency on provision `fake_prov_0004': 
/usr/local/etc/rc.d/tcsd -> /usr/local/etc/rc.d/tpmd -> /etc/rc.d/SERVERS -> 
/usr/local/etc/rc.d/named -> /usr/local/etc/rc.d/tcsd.
rcorder: `/usr/local/etc/rc.d/named' was seen in circular dependencies for 1 
times.
rcorder: `/etc/rc.d/SERVERS' was seen in circular dependencies for 1 times.
rcorder: `/usr/local/etc/rc.d/tpmd' was seen in circular dependencies for 1 
times.
rcorder: `/usr/local/etc/rc.d/tcsd' was seen in circular dependencies for 1 
times.
rcorder: `/usr/local/etc/rc.d/named' was seen in circular dependencies for 1 
times.
root@eastasia[1068]#
--

If I temporally move /usr/local/etc/rc.d/tcsd to somewhere else and
add 'ntpdate' to 'BEFORE' line of /usr/local/etc/rc.d/named, then
'named' comes before 'ntpupdate' in the result of rcorder.

---
Yasuhiro Kimura
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Slow iSCSI discovery on boot halting the boot process.

[Andrea Brancatelli via freebsd-stable]

On 2021-04-30 11:12, Arrigo Marchiori via freebsd-stable wrote:

> On Fri, Apr 30, 2021 at 10:29:33AM +0200, Andrea Brancatelli via 
> freebsd-stable wrote:
> 
>> Hello,  
>> 
>> I'm having an annoying problem with FreeBSD 12.2-RELEASE-p6, iscsid,
>> geom multiparty, a Dell MD3200i and fstab. 
>> 
>> Long story short, iSCSI login/connection/whatever is slower than the
>> boot process and the machine always get stuck with "cannot find
>> /san_storage (/dev/multipath/...) please enter /bin/sh location"
> 
> Did you try putting in /boot/loader.conf:
> kern.cam.boot_delay=1
> 
> It should wait for 10 seconds before attempting to mount the root
> partition.

OK, I've put it in /boot/loader.conf, let's see if it helps. 

Unfortunately it's a production machine so I cannot reboot it now to try
it. 

Thanks for the suggestion.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: How to make 'named' rc script invokded earlier at boot time

[Yasuhiro Kimura]

From: Yasuhiro Kimura 
Subject: Re: How to make 'named' rc script invokded earlier at boot time
Date: Fri, 30 Apr 2021 17:18:26 +0900 (JST)

>> The only way I can see is modify the named rc script and add the
>> services that needs named to be started on the BEFORE line at the
>> beginning of the script. Mind you, it really needs to start after
>> syslog (unless you log directly to files and do not use syslog.)
> 
> Thanks for advice. I'll try it.

I tried it but am confused by the result.

I modified /usr/local/etc/rc.d/named on my home server as following.

--
root@eastasia[1051]# head /usr/local/etc/rc.d/named
#!/bin/sh

# PROVIDE: named
# REQUIRE: NETWORKING ldconfig syslogd
# BEFORE: SERVERS ntpdate
# KEYWORD: shutdown

#
# Add the following lines to /etc/rc.conf to enable BIND:
# named_enable (bool):  Run named, the DNS server (or NO).
root@eastasia[1052]#
--

And I executed `rcorder /etc/rc.d/* /usr/local/etc/rc.d/*`. Then I got
just same result as before the modification.

So I modifed /etc/rc.d/ntpdate as following.

--
root@eastasia[1053]# head /etc/rc.d/ntpdate 
 ~
#!/bin/sh
#
# $FreeBSD$
#

# PROVIDE: ntpdate
# REQUIRE: NETWORKING syslogd named
# KEYWORD: nojail

. /etc/rc.subr
root@eastasia[1054]#
--

But the result still didn't changed.

As I wrote another mail my result of `rcorder -p` is different from
that of Helge Oldach. These oddities may be related.

I'll investigate further but it may take for a while.

---
Yasuhiro Kimura
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Slow iSCSI discovery on boot halting the boot process.

[Arrigo Marchiori via freebsd-stable]

Hello,

On Fri, Apr 30, 2021 at 10:29:33AM +0200, Andrea Brancatelli via freebsd-stable 
wrote:

> Hello,  
> 
> I'm having an annoying problem with FreeBSD 12.2-RELEASE-p6, iscsid,
> geom multiparty, a Dell MD3200i and fstab. 
> 
> Long story short, iSCSI login/connection/whatever is slower than the
> boot process and the machine always get stuck with "cannot find
> /san_storage (/dev/multipath/...) please enter /bin/sh location"  

Did you try putting in /boot/loader.conf:
kern.cam.boot_delay=1

It should wait for 10 seconds before attempting to mount the root
partition.

This solves the issue for me on certain embedded systems, and when
trying to boot from cheap USB pen drives.

I hope this helps.

Best regards,
-- 
Arrigo
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Slow iSCSI discovery on boot halting the boot process.

[Andrea Brancatelli via freebsd-stable]

On 2021-04-30 10:29, Andrea Brancatelli via freebsd-stable wrote:

> Hello,  
> 
> I'm having an annoying problem with FreeBSD 12.2-RELEASE-p6, iscsid,
> geom multiparty, a Dell MD3200i and fstab.

Geom multiparty is probably the best typo/autocorrect ever. 

---

Andrea Brancatelli
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Slow iSCSI discovery on boot halting the boot process.

[Andrea Brancatelli via freebsd-stable]

Hello,  

I'm having an annoying problem with FreeBSD 12.2-RELEASE-p6, iscsid,
geom multiparty, a Dell MD3200i and fstab. 

Long story short, iSCSI login/connection/whatever is slower than the
boot process and the machine always get stuck with "cannot find
/san_storage (/dev/multipath/...) please enter /bin/sh location"  

Usually we just press enter, press control-d, and the boot process
continues. 

The problem is that the machine cannot boot unattended. 

Those are some cfg files: 

[root@arsenico ~]# cat /etc/fstab
# Device Mountpoint FStype Options Dump Pass#
/dev/mirror/gm0s1a / ufs rw 1 1
/dev/mirror/gm0s1b none swap sw 0 0
md98 none swap sw,file=/usr/swap1,late 0 0
md99 none swap sw,file=/usr/swap0,late 0 0
/dev/mirror/gm0s1d /var ufs rw 2 2
/dev/mirror/gm0s1e /tmp ufs rw 2 2
/dev/mirror/gm0s1f /usr ufs rw 2 2
/dev/mirror/gm0s1g /repository ufs rw 2 2
fdesc /dev/fd fdescfs rw 0 0
/dev/multipath/Krypton /san_storage ufs rw,late 0 0 

As you see the filesystem is already flagged as "late"... 

[root@arsenico ~]# cat /etc/iscsi.conf 

Krypton_C0_P0 {
TargetName=iqn.1984-05.com.dell:powervault.md3200i.6782bcb0007496a24f1e49ee
TargetAddress=10.40.3.200
} 

That's the SAN, we dropped the dual connection so maybe we could get rid
of geom_multipath if that is the problem, but... hey... 

[root@arsenico ~]# gmultipath list
Geom name: Krypton
Type: AUTOMATIC
Mode: Active/Active
UUID: 101b1867-c623-11e8-8bab-90e2ba021650
State: DEGRADED
Providers:
1. Name: multipath/Krypton
Mediasize: 15998753177088 (15T)
Sectorsize: 512
Mode: r1w1e1
State: DEGRADED
Consumers:
1. Name: da2
Mediasize: 15998753177600 (15T)
Sectorsize: 512
Mode: r2w2e2
State: ACTIVE 

[root@arsenico ~]# camcontrol devlist
 at scbus0 target 5 lun 0 (pass0,da0)
 at scbus0 target 6 lun 0 (pass1,da1)
 at scbus3 target 0 lun 0 (cd0,pass2)
 at scbus5 target 0 lun 0 (da2,pass3)
 at scbus5 target 0 lun 1f (da3,pass4) 

Any interesting suggestions? 

Thanks a lot. 

-- 

Andrea Brancatelli
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: How to make 'named' rc script invokded earlier at boot time

[Yasuhiro Kimura]

From: Mathieu Arnold 
Subject: Re: How to make 'named' rc script invokded earlier at boot time
Date: Fri, 30 Apr 2021 10:02:31 +0200

> There is an option in the port to have named start later, but up to now,
> it was starting early enough.
> 
> The only way I can see is modify the named rc script and add the
> services that needs named to be started on the BEFORE line at the
> beginning of the script. Mind you, it really needs to start after
> syslog (unless you log directly to files and do not use syslog.)

Thanks for advice. I'll try it.

---
Yasuhiro Kimura
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: How to make 'named' rc script invokded earlier at boot time

[Yasuhiro Kimura]

From: b56...@oldach.net (Helge Oldach)
Subject: Re: How to make 'named' rc script invokded earlier at boot time
Date: Fri, 30 Apr 2021 10:01:47 +0200 (CEST)

> Can you try rcorder -p? That will group equally ranked scripts on the same 
> line.
> 
> On 13, I'm seeing:
> 
> (snip)
> /etc/rc.d/pwcheck /etc/rc.d/watchdogd /usr/local/etc/rc.d/named 
> /etc/rc.d/auditd /etc/rc.d/ntpdate /etc/rc.d/bsnmpd /etc/rc.d/savecore 
> /etc/rc.d/power_profile /etc/rc.d/localpkg /etc/rc.d/hastd
> /etc/rc.d/rpcbind /etc/rc.d/SERVERS /etc/rc.d/auditdistd
> (snip)
> 
> which implies that the ordering of named and ntpdate is random however both 
> are before SERVERS.
> 
> Kind regards
> Helge

I get following result.

(snip)
/etc/rc.d/NETWORKING
/etc/rc.d/kdc /etc/rc.d/kfd /etc/rc.d/pppoed /etc/rc.d/nfsuserd /etc/rc.d/iscsid
/etc/rc.d/iscsictl /etc/rc.d/nfscbd /etc/rc.d/kpasswdd /etc/rc.d/kadmind 
/etc/rc.d/ipropd_slave /etc/rc.d/ipropd_master/etc/rc.d/mountcritremote
/etc/rc.d/devfs /etc/rc.d/virecover /etc/rc.d/os-release /etc/rc.d/motd 
/etc/rc.d/archdep /etc/rc.d/mdconfig2 /etc/rc.d/gptboot 
/etc/rc.d/wpa_supplicant /etc/rc.d/accounting /etc/rc.d/dmesg 
/etc/rc.d/cleartmp /etc/rc.d/hostapd /etc/rc.d/newsyslog
/etc/rc.d/syslogd /etc/rc.d/sysvipc /etc/rc.d/linux
/etc/rc.d/pwcheck /etc/rc.d/localpkg /etc/rc.d/power_profile /etc/rc.d/auditd 
/etc/rc.d/bsnmpd /etc/rc.d/ntpdate /etc/rc.d/savecore /etc/rc.d/watchdogd
/etc/rc.d/rpcbind /etc/rc.d/auditdistd
/etc/rc.d/nfsclient
/usr/local/etc/rc.d/tpmd
/usr/local/etc/rc.d/tcsd
/etc/rc.d/hastd /usr/local/etc/rc.d/named
/etc/rc.d/SERVERS
(snip)

'named' is still later than 'ntpdate' on my home server.

---
Yasuhiro Kimura
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: How to make 'named' rc script invokded earlier at boot time

[Mathieu Arnold]

On Fri, Apr 30, 2021 at 04:30:54PM +0900, Yasuhiro Kimura wrote:
> Then is there any way to make 'named' rc script invoked earlier at
> boot time on 13.0-RELEASE?

There is an option in the port to have named start later, but up to now,
it was starting early enough.

The only way I can see is modify the named rc script and add the
services that needs named to be started on the BEFORE line at the
beginning of the script. Mind you, it really needs to start after
syslog (unless you log directly to files and do not use syslog.)

-- 
Mathieu Arnold


signature.asc
Description: PGP signature

How to make 'named' rc script invokded earlier at boot time

[Yasuhiro Kimura]

I installed dns/bind916 on my home server and configured it so it
worked as both authoritative and recursor. Then I added
'nameserver 127.0.0.1' to /etc/resolv.conf and everything worked fine.

But after updating OS from 12.2-RELEASE to 13.0-RELEASE I noticed
execution of some rc scripts fails at boot time because of DNS lookup
error. And I also found these scripts are executed earlier than
'named'.

Now let me use 'ntpdate' as an example.

If I run `rcorder /etc/rc.d/* /usr/local/etc/rc.d/*` on 12.2-RELEASE,
then I get following result.

--
root@rolling-vm-freebsd3[474]# uname -a
FreeBSD rolling-vm-freebsd3.home.utahime.org 12.2-RELEASE-p6 FreeBSD 
12.2-RELEASE-p6 GENERIC  amd64
root@rolling-vm-freebsd3[475]# rcorder /etc/rc.d/* /usr/local/etc/rc.d/*
/etc/rc.d/growfs
/etc/rc.d/sysctl
/etc/rc.d/hostid
/etc/rc.d/zvol
/etc/rc.d/dumpon
(snip)
/etc/rc.d/static_arp
/etc/rc.d/bridge
/etc/rc.d/route6d
/etc/rc.d/NETWORKING
/etc/rc.d/mountcritremote
/etc/rc.d/devfs
/etc/rc.d/ipmon
/etc/rc.d/kdc
/etc/rc.d/mdconfig2
/etc/rc.d/newsyslog
/etc/rc.d/syslogd
/usr/local/etc/rc.d/tcsd
/usr/local/etc/rc.d/named
/etc/rc.d/watchdogd
/etc/rc.d/savecore
/etc/rc.d/archdep
/etc/rc.d/linux
/etc/rc.d/sysvipc
/etc/rc.d/SERVERS
/usr/local/etc/rc.d/tpmd
/usr/local/etc/rc.d/stunnel
/etc/rc.d/accounting
/etc/rc.d/ntpdate
/etc/rc.d/rpcbind
/etc/rc.d/nfsclient
/etc/rc.d/nisdomain
(snip)
--

As you can see, while 'named' is executed before SERVERS, 'ntpdate' is
done after it.

On the other hand I get following result on 13.0-RELEASE.

--
root@rolling-vm-freebsd2[332]# uname -a
FreeBSD rolling-vm-freebsd2.home.utahime.org 13.0-RELEASE FreeBSD 13.0-RELEASE 
#0 releng/13.0-n244733-ea31abc261f: Fri Apr  9 04:24:09 UTC 2021 
r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64
root@rolling-vm-freebsd2[333]# rcorder /etc/rc.d/* /usr/local/etc/rc.d/*
/etc/rc.d/dhclient
/etc/rc.d/dumpon
/etc/rc.d/growfs
/etc/rc.d/natd
(snip)
/etc/rc.d/netwait
/etc/rc.d/blacklistd
/etc/rc.d/local_unbound
/etc/rc.d/NETWORKING
/etc/rc.d/pppoed
/etc/rc.d/kdc
/etc/rc.d/kfd
/etc/rc.d/nfsuserd
/etc/rc.d/iscsid
/etc/rc.d/ipropd_slave
/etc/rc.d/nfscbd
/etc/rc.d/iscsictl
/etc/rc.d/ipropd_master
/etc/rc.d/kadmind
/etc/rc.d/kpasswdd
/etc/rc.d/mountcritremote
/etc/rc.d/wpa_supplicant
/etc/rc.d/motd
/etc/rc.d/accounting
/etc/rc.d/cleartmp
/etc/rc.d/dmesg
/etc/rc.d/archdep
/etc/rc.d/gptboot
/etc/rc.d/hostapd
/etc/rc.d/virecover
/etc/rc.d/mdconfig2
/etc/rc.d/devfs
/etc/rc.d/os-release
/etc/rc.d/newsyslog
/etc/rc.d/linux
/etc/rc.d/syslogd
/etc/rc.d/sysvipc
/etc/rc.d/watchdogd
/etc/rc.d/savecore
/etc/rc.d/ntpdate
/etc/rc.d/localpkg
/etc/rc.d/auditd
/etc/rc.d/bsnmpd
/etc/rc.d/pwcheck
/etc/rc.d/power_profile
/etc/rc.d/rpcbind
/etc/rc.d/auditdistd
/usr/local/etc/rc.d/named
/etc/rc.d/nfsclient
/etc/rc.d/hastd
/etc/rc.d/SERVERS
/etc/rc.d/nisdomain
/usr/local/etc/rc.d/stunnel
/usr/local/etc/rc.d/tpmd
/usr/local/etc/rc.d/tcsd
(snip)
--

Now both 'named' and 'ntpdate' are executed before SERVERS. And
unfortunately the latter is earlier than the former. So it is natural
that execution of 'ntpdate' fails with DNS lookup failure.

I compared ntpdate rc script between releng/12.2 and releng/13.0 but
there is no difference.

--
yasu@rolling-vm-freebsd2[1035]% pwd
/usr/src
yasu@rolling-vm-freebsd2[1036]% git diff origin/releng/12.2 origin/releng/13.0  
-- libexec/rc/rc.d/ntpdate
yasu@rolling-vm-freebsd2[1037]%
--

And of cource there is no difference with /usr/local/etc/rc.d/named
either. So it seems evaluation of rcorder(8) is changed between
12.2-RELASE and 13.0-RELEASE.

Then is there any way to make 'named' rc script invoked earlier at
boot time on 13.0-RELEASE?

Best Regards.

---
Yasuhiro Kimura
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Updated to 13-STABLE in VirtualBox; on shutdown stuck after uhub[01] being detached

[Antony Uspensky]

On Wed, 28 Apr 2021, parv/freebsd wrote:


Solved the issue via ...

 % sysctl hw.efi.poweroff=0
... after that shudown went on as expected. Got that from  ...

https://forums.freebsd.org/threads/freebsd-13-does-not-shut-down-my-laptop.79853/


Well, this also solved my problem described in a message to this list:

Date: Thu, 1 Apr 2021 18:58:01 +0300 (MSK)
From: Antony Uspensky 
To: freebsd-stable@freebsd.org
Subject: ACPI poweroff is not working on 13.0
Message-ID: 

I was wrong: it was EFI poweroff that did not work, not ACPI one.
I was too lazy to do a bisection, now I am OK.
Thank you for the tip!

Seems, this problem (non-working shutdown in EFI environment) is a POLA 
violation in 13.0. 
A.

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

FYI: WITH_REPRODUCIBLE_BUILD= problem for some files?

[Mark Millard via freebsd-stable]

I did 2 test buildworld's based on:

# ~/fbsd-based-on-what-freebsd.sh 
branch: releng/13.0
merge-base: ea31abc261ffc01b6ff5671bffb15cf910a07f4b
merge-base: CommitDate: 2021-04-09 00:14:30 +
ea31abc261ff (HEAD -> releng/13.0, tag: release/13.0.0, freebsd/releng/13.0) 
13.0: update to RELEASE
n244733 (--first-parent --count for merge-base)

and produced separate build trees. I also installed the
world build into two separate directory trees:

/usr/obj/DESTDIRs/13_0R-CA7-chroot/
vs.
/usr/obj/DESTDIRs/13_0R-CA7-poud/

This was for other reasons. But eventually I happened
to do a diff -rq of the two trees and ended up with
the output showing some differing files:

Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/sbin/ping and 
/usr/obj/DESTDIRs/13_0R-CA7-poud/sbin/ping differ
Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/sbin/ping6 and 
/usr/obj/DESTDIRs/13_0R-CA7-poud/sbin/ping6 differ
Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/usr/bin/ntpq and 
/usr/obj/DESTDIRs/13_0R-CA7-poud/usr/bin/ntpq differ
Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/usr/lib/debug/sbin/ping.debug and 
/usr/obj/DESTDIRs/13_0R-CA7-poud/usr/lib/debug/sbin/ping.debug differ
Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/usr/lib/debug/usr/sbin/ntpd.debug and 
/usr/obj/DESTDIRs/13_0R-CA7-poud/usr/lib/debug/usr/sbin/ntpd.debug differ
Files 
/usr/obj/DESTDIRs/13_0R-CA7-chroot/usr/lib/debug/usr/tests/sbin/ping/in_cksum_test.debug
 and 
/usr/obj/DESTDIRs/13_0R-CA7-poud/usr/lib/debug/usr/tests/sbin/ping/in_cksum_test.debug
 differ
Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/usr/sbin/ntp-keygen and 
/usr/obj/DESTDIRs/13_0R-CA7-poud/usr/sbin/ntp-keygen differ
Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/usr/sbin/ntpd and 
/usr/obj/DESTDIRs/13_0R-CA7-poud/usr/sbin/ntpd differ
Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/usr/sbin/ntpdate and 
/usr/obj/DESTDIRs/13_0R-CA7-poud/usr/sbin/ntpdate differ
Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/usr/sbin/ntpdc and 
/usr/obj/DESTDIRs/13_0R-CA7-poud/usr/sbin/ntpdc differ
Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/usr/sbin/sntp and 
/usr/obj/DESTDIRs/13_0R-CA7-poud/usr/sbin/sntp differ
Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/usr/tests/sbin/ping/in_cksum_test and 
/usr/obj/DESTDIRs/13_0R-CA7-poud/usr/tests/sbin/ping/in_cksum_test differ

(That is all.)

For as much as I've looked at (not much), it looks to be
variations in byte-padding values.

The builds both were set up to tune for cortex-a7 explicitly.
I patch top's source code. I patch the OOM kill code to report
the specific reason for a kill. I still have some bcm2838
pci/xhci patching in place from an old investigation, but
that would be kernel code. None of the patching is specific
to the above list of files.

The hosting context was:

# uname -apKU
FreeBSD CA72_4c8G_ZFS 13.0-RELEASE FreeBSD 13.0-RELEASE #1 
releng/13.0-n244733-ea31abc261ff-dirty: Wed Apr 28 05:45:27 PDT 2021 
root@CA72_4c8G_ZFS:/usr/obj/BUILDs/13_0R-CA72-nodbg-clang/usr/src/arm64.aarch64/sys/GENERIC-NODBG-CA72
  arm64 aarch64 1300139 1300139

based on building the same source code (tuning for
cortex-a72).

It was the same media for all the activity. Unlike
the past many years for me, the context is using ZFS
instead of UFS, not that I think that makes a
difference here.

The differences do not mess up my activity but others
might notice and care about such differences.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Updated to 13-STABLE in VirtualBox; on shutdown stuck after uhub[01] being detached

[parv/freebsd]

(Changed my email address to the one I used to subscribe to the mailing
list.)

On Wed, Apr 28, 2021 at 10:05 AM Guido Falsi wrote:

Hi,


On 28/04/21 00:12, parv wrote:
> > I had updated FreeBSD, in VirtualBox 5.22 on Windows with EFI, from
> > 12-STABLE
> > to 13-STABLE; upgraded the ZFS pools & the EFI boot loader. Currently
> > testing with 13 GENERIC kernel.
>
> You mean you enabled EFI inside virtualbox? Why do you need that?


For testing if FreeBSD can boot with EFI (with ZFS-on-root) ... one day I
may just install the thing directly on a disk, outside of a virtual machine
... one day!



> EFI
> support in VirtualBox is experimental and is available for OSes unable
> to boot without EFI. FreeBSD is perfectly able to boot in virtualbox
> without EFI so no need for it.
>

I am aware.



> > Now on shutdown, "shutdown -p now" (in single user mode, after manually
> > unmounting
> > ZFS datasets [...] the shutting down process gets stuck,
> > and CPU use jumps to 80%
>
...

> > In the end I chose "Power Off" from VirutalBox menu. "Reset" reboots the
> > machine.
> > None of these have any effect ...
> >- Send the shutdown signal
> >- ACPI Shutdown
> >
> > Help please.
>

Solved the issue via ...

  % sysctl hw.efi.poweroff=0
... after that shudown went on as expected. Got that from  ...


https://forums.freebsd.org/threads/freebsd-13-does-not-shut-down-my-laptop.79853/


NOt sure even which further information to ask about this, but to be
> sure I understand correctly, FreeBSD is the guest here, correct?


Yes, FreeBSD is the guest on Windows 10 host.

- parv
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Updated to 13-STABLE in VirtualBox; on shutdown stuck after uhub[01] being detached

[Guido Falsi via freebsd-stable]

On 28/04/21 00:12, parv wrote:

Hi there,

I had updated FreeBSD, in VirtualBox 5.22 on Windows with EFI, from
12-STABLE
to 13-STABLE; upgraded the ZFS pools & the EFI boot loader. Currently
testing with 13 GENERIC kernel.


You mean you enabled EFI inside virtualbox? Why do you need that? EFI 
support in VirtualBox is experimental and is available for OSes unable 
to boot without EFI. FreeBSD is perfectly able to boot in virtualbox 
without EFI so no need for it.


Now I understand reconfiguring the VM to not use EFI can be annoying, 
but you should really verify if the problem goes away without EFI.


Also can you try installing another FreeBSD VM and verify the problem 
happens for that one too? This could help understand if the problem is 
with virtualization or specific to the VM.




Now on shutdown, "shutdown -p now" (in single user mode, after manually
unmounting
ZFS datasets via "zfs unmount -a"), the shutting down process gets stuck,
and
CPU use jumps to 80% (Intel i5 6300U, 3 CPUs given to VM, of Thinkpad
X260). Last
few lines are ...

...
All buffers synced.
Uptime: 
uhub0: detached
uhub1: detached


In the end I chose "Power Off" from VirutalBox menu. "Reset" reboots the
machine.
None of these have any effect ...
   - Send the shutdown signal
   - ACPI Shutdown

Help please.


NOt sure even which further information to ask about this, but to be 
sure I understand correctly, FreeBSD is the guest here, correct?


--
Guido Falsi 
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Updated to 13-STABLE in VirtualBox; on shutdown stuck after uhub[01] being detached

[parv]

Hi there,

I had updated FreeBSD, in VirtualBox 5.22 on Windows with EFI, from
12-STABLE
to 13-STABLE; upgraded the ZFS pools & the EFI boot loader. Currently
testing with 13 GENERIC kernel.

Now on shutdown, "shutdown -p now" (in single user mode, after manually
unmounting
ZFS datasets via "zfs unmount -a"), the shutting down process gets stuck,
and
CPU use jumps to 80% (Intel i5 6300U, 3 CPUs given to VM, of Thinkpad
X260). Last
few lines are ...

...
All buffers synced.
Uptime: 
uhub0: detached
uhub1: detached


In the end I chose "Power Off" from VirutalBox menu. "Reset" reboots the
machine.
None of these have any effect ...
  - Send the shutdown signal
  - ACPI Shutdown

Help please.


- parv
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"