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: 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 bo

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:
>>>>
>>>> # di

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 w

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 ex

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 

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_th

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

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

[Rick Macklem]

h-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 
>/mnt/devel/ice/files/patch-cpp-include-IceUtil-ScannerConfig.h
>-rw-r--r--  1 root  wheel   588 Apr 21 21:07:54 2021 
>/mnt/devel/ice/files/patch-cpp-src->Glacier2CryptPermissionsVerifier-CryptPermissionsVerifierI.cpp
>-rw-r--r--  1 root  wheel   384 Apr 21 21:07:54 2021 
>/mnt/devel/ice/files/patch-cpp-src-Ice-ProxyFactory.cpp
>-rw-r--r--  1 root  wheel   691 Apr 21 21:07:54 2021 
>/mnt/devel/ice/files/patch-cpp-src-IceGrid-PluginFacadeI.cpp
>-rw-r--r--  1 root  wheel   440 Apr 21 21:07:54 2021 
>/mnt/devel/ice/files/patch-cpp-src-IceGrid-RegistryI.cpp
>-rw-r--r--  1 root  wheel   543 Apr 21 21:07:54 2021 
>/mnt/devel/ice/files/patch-cpp-src-IceSSL-Makefile
>-rw-r--r--  1 root  wheel   990 Apr 21 21:07:54 2021 
>/mnt/devel/ice/files/patch-cpp-test-Glacier2-ssl-Server.cpp
>-rw-r--r--  1 root  wheel  1280 Apr 21 21:07:54 2021 
>/mnt/devel/ice/files/patch-cpp-test-Glacier2-staticFiltering-run.py
>-rw-r--r--  1 root  wheel   867 Apr 21 21:07:54 2021 
>/mnt/devel/ice/files/patch-cpp-test-Ice-info-AllTests.cpp
>-rw-r--r--  1 root  wheel  3337 Apr 21 21:07:54 2021 
>/mnt/devel/ice/files/patch-cpp-test-Ice-metrics-AllTests.cpp
>-rw-r--r--  1 root  wheel   752 Apr 21 21:07:54 2021 
>/mnt/devel/ice/files/patch-cpp-test-Ice-objects-Makefile
>-rw-r--r--  1 root  wheel   730 Apr 21 21:07:54 2021 
>/mnt/devel/ice/files/patch-cpp-test-Ice-properties-run.py
>-rw-r--r--  1 root  wheel   718 Apr 21 21:07:54 2021 
>/mnt/devel/ice/files/patch-cpp-test-IceGrid-admin-run.py
>-rw-r--r--  1 root  wheel  8800 Apr 21 21:07:54 2021 
>/mnt/devel/ice/files/patch-cpp-test-IceGrid-deployer-AllTests.cpp
>-rw-r--r--  1 root  wheel   438 Apr 21 21:07:54 2021 
>/mnt/devel/ice/files/patch-cpp-test-IceGrid-deployer-Makefile
>-rw-r--r--  1 root  wheel   787 Apr 21 21:07:54 2021 
>/mnt/devel/ice/files/patch-cpp-test-IceGrid-deployer-application.xml
>-rw-r--r--  1 root  wheel   997 Apr 21 21:07:54 2021 
>/mnt/devel/ice/files/patch-cpp-test-IceGrid-distribution-AllTests.cpp
>-rw-r--r--  1 root  wheel   434 Apr 21 21:07:54 2021 
>/mnt/devel/ice/files/patch-cpp-test-IceGrid-distribution-application.xml
>-rw-r--r--  1 root  wheel   459 Apr 21 21:07:54 2021 
>/mnt/devel/ice/files/patch-cpp-test-IceGrid-distribution-run.py
>-rw-r--r--  1 root  wheel   741 Apr 21 21:07:54 2021 
>/mnt/devel/ice/files/patch-cpp-test-IceGrid-session-run.py
>-rw-r--r--  1 root  wheel  1179 Apr 21 21:07:54 2021 
>/mnt/devel/ice/files/patch-cpp-test-IceSSL-configuration-AllTests.cpp
>-rw-r--r--  1 root  wheel  1038 Apr 21 21:07:54 2021 
>/mnt/devel/ice/files/patch-cpp-test-IceSSL-configuration-run.py
>-rw-r--r--  1 root  wheel  3490 Apr 21 21:07:54 2021 
>/mnt/devel/ice/files/patch-cpp-test-Slice-headers-run.py
>-rw-r--r--  1 root  wheel   484 Apr 21 21:07:54 2021 
>/mnt/devel/ice/files/patch-cpp-test-Slice-unicodePaths-run.py
>-rw-r--r--  1 root  wheel   608 Apr 21 21:07:54 2021 
>/mnt/devel/ice/files/patch-cpp-test-include-TestCommon.h
>-rw-r--r--  1 root  wheel   341 Apr 21 21:07:54 2021 
>/mnt/devel/ice/files/patch-php-Makefile
>-rw-r--r--  1 root  wheel   951 Apr 21 21:07:54 2021 
>/mnt/devel/ice/files/patch-php-config-Make.rules.php
>-rw-r--r--  1 root  wheel   434 Apr 21 21:07:54 2021 
>/mnt/devel/ice/files/patch-php-lib-Makefile
>-rw-r--r--  1 root  wheel   322 Apr 21 21:07:54 2021 
>/mnt/devel/ice/files/patch-python-Makefile
>-rw-r--r--  1 root  wheel  2629 Apr 21 21:07:54 2021 
>/mnt/devel/ice/files/patch-python-config-Make.rules
>-rw-r--r--  1 root  wheel  3394 Apr 21 21:07:54 2021 
>/mnt/devel/ice/files/patch-python-modules-IcePy-Types.cpp
>-rw-r--r--  1 root  wheel  5092 Apr 21 21:07:54 2021 
>/mnt/devel/ice/files/patch-python-modules-IcePy-Types.h
>-rw-r--r--  1 root  wheel   668 Apr 21 21:07:54 2021 
>/mnt/devel/ice/files/patch-python-python-Makefile
>-rw-r--r--  1 root  wheel  2640 Apr 21 21:07:54 2021 
>/mnt/devel/ice/files/patch-python-test-Ice-info-AllTests.py
>-rw-r--r--  1 root  wheel   736 Apr 21 21:07:54 2021 
>/mnt/devel/ice/files/patch-python-test-Ice-properties-run.py
>-rw-r--r--  1 root  wheel   490 Apr 21 21:07:54 2021 
>/mnt/devel/ice/files/patch-python-test-Slice-unicodePaths-run.py
>-rw-r--r--  1 root  wheel   381 Apr 21 21:07:54 2021 
>/mnt/devel/ice/files/patch-scripts-Expect.py
>-rw-r--r--  1 root  wheel   793 Apr 21 21:07:54 2021 
>/mnt/devel/ice/files/patch-scripts-IceGridAdmin.py
>-rw-r--r--  1 root  wheel  2588 Apr 21 21:07:54 2021 
>/mnt/devel/ice/files/patch-scripts-TestUtil.py
>
&g

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

[Mark Millard via freebsd-stable]

-ScannerConfig.h
-rw-r--r--  1 root  wheel   588 Apr 21 21:07:54 2021 
/mnt/devel/ice/files/patch-cpp-src-Glacier2CryptPermissionsVerifier-CryptPermissionsVerifierI.cpp
-rw-r--r--  1 root  wheel   384 Apr 21 21:07:54 2021 
/mnt/devel/ice/files/patch-cpp-src-Ice-ProxyFactory.cpp
-rw-r--r--  1 root  wheel   691 Apr 21 21:07:54 2021 
/mnt/devel/ice/files/patch-cpp-src-IceGrid-PluginFacadeI.cpp
-rw-r--r--  1 root  wheel   440 Apr 21 21:07:54 2021 
/mnt/devel/ice/files/patch-cpp-src-IceGrid-RegistryI.cpp
-rw-r--r--  1 root  wheel   543 Apr 21 21:07:54 2021 
/mnt/devel/ice/files/patch-cpp-src-IceSSL-Makefile
-rw-r--r--  1 root  wheel   990 Apr 21 21:07:54 2021 
/mnt/devel/ice/files/patch-cpp-test-Glacier2-ssl-Server.cpp
-rw-r--r--  1 root  wheel  1280 Apr 21 21:07:54 2021 
/mnt/devel/ice/files/patch-cpp-test-Glacier2-staticFiltering-run.py
-rw-r--r--  1 root  wheel   867 Apr 21 21:07:54 2021 
/mnt/devel/ice/files/patch-cpp-test-Ice-info-AllTests.cpp
-rw-r--r--  1 root  wheel  3337 Apr 21 21:07:54 2021 
/mnt/devel/ice/files/patch-cpp-test-Ice-metrics-AllTests.cpp
-rw-r--r--  1 root  wheel   752 Apr 21 21:07:54 2021 
/mnt/devel/ice/files/patch-cpp-test-Ice-objects-Makefile
-rw-r--r--  1 root  wheel   730 Apr 21 21:07:54 2021 
/mnt/devel/ice/files/patch-cpp-test-Ice-properties-run.py
-rw-r--r--  1 root  wheel   718 Apr 21 21:07:54 2021 
/mnt/devel/ice/files/patch-cpp-test-IceGrid-admin-run.py
-rw-r--r--  1 root  wheel  8800 Apr 21 21:07:54 2021 
/mnt/devel/ice/files/patch-cpp-test-IceGrid-deployer-AllTests.cpp
-rw-r--r--  1 root  wheel   438 Apr 21 21:07:54 2021 
/mnt/devel/ice/files/patch-cpp-test-IceGrid-deployer-Makefile
-rw-r--r--  1 root  wheel   787 Apr 21 21:07:54 2021 
/mnt/devel/ice/files/patch-cpp-test-IceGrid-deployer-application.xml
-rw-r--r--  1 root  wheel   997 Apr 21 21:07:54 2021 
/mnt/devel/ice/files/patch-cpp-test-IceGrid-distribution-AllTests.cpp
-rw-r--r--  1 root  wheel   434 Apr 21 21:07:54 2021 
/mnt/devel/ice/files/patch-cpp-test-IceGrid-distribution-application.xml
-rw-r--r--  1 root  wheel   459 Apr 21 21:07:54 2021 
/mnt/devel/ice/files/patch-cpp-test-IceGrid-distribution-run.py
-rw-r--r--  1 root  wheel   741 Apr 21 21:07:54 2021 
/mnt/devel/ice/files/patch-cpp-test-IceGrid-session-run.py
-rw-r--r--  1 root  wheel  1179 Apr 21 21:07:54 2021 
/mnt/devel/ice/files/patch-cpp-test-IceSSL-configuration-AllTests.cpp
-rw-r--r--  1 root  wheel  1038 Apr 21 21:07:54 2021 
/mnt/devel/ice/files/patch-cpp-test-IceSSL-configuration-run.py
-rw-r--r--  1 root  wheel  3490 Apr 21 21:07:54 2021 
/mnt/devel/ice/files/patch-cpp-test-Slice-headers-run.py
-rw-r--r--  1 root  wheel   484 Apr 21 21:07:54 2021 
/mnt/devel/ice/files/patch-cpp-test-Slice-unicodePaths-run.py
-rw-r--r--  1 root  wheel   608 Apr 21 21:07:54 2021 
/mnt/devel/ice/files/patch-cpp-test-include-TestCommon.h
-rw-r--r--  1 root  wheel   341 Apr 21 21:07:54 2021 
/mnt/devel/ice/files/patch-php-Makefile
-rw-r--r--  1 root  wheel   951 Apr 21 21:07:54 2021 
/mnt/devel/ice/files/patch-php-config-Make.rules.php
-rw-r--r--  1 root  wheel   434 Apr 21 21:07:54 2021 
/mnt/devel/ice/files/patch-php-lib-Makefile
-rw-r--r--  1 root  wheel   322 Apr 21 21:07:54 2021 
/mnt/devel/ice/files/patch-python-Makefile
-rw-r--r--  1 root  wheel  2629 Apr 21 21:07:54 2021 
/mnt/devel/ice/files/patch-python-config-Make.rules
-rw-r--r--  1 root  wheel  3394 Apr 21 21:07:54 2021 
/mnt/devel/ice/files/patch-python-modules-IcePy-Types.cpp
-rw-r--r--  1 root  wheel  5092 Apr 21 21:07:54 2021 
/mnt/devel/ice/files/patch-python-modules-IcePy-Types.h
-rw-r--r--  1 root  wheel   668 Apr 21 21:07:54 2021 
/mnt/devel/ice/files/patch-python-python-Makefile
-rw-r--r--  1 root  wheel  2640 Apr 21 21:07:54 2021 
/mnt/devel/ice/files/patch-python-test-Ice-info-AllTests.py
-rw-r--r--  1 root  wheel   736 Apr 21 21:07:54 2021 
/mnt/devel/ice/files/patch-python-test-Ice-properties-run.py
-rw-r--r--  1 root  wheel   490 Apr 21 21:07:54 2021 
/mnt/devel/ice/files/patch-python-test-Slice-unicodePaths-run.py
-rw-r--r--  1 root  wheel   381 Apr 21 21:07:54 2021 
/mnt/devel/ice/files/patch-scripts-Expect.py
-rw-r--r--  1 root  wheel   793 Apr 21 21:07:54 2021 
/mnt/devel/ice/files/patch-scripts-IceGridAdmin.py
-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):

# uname -apKU
FreeBSD CA72_16Gp_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

# ~/

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

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: 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"

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"

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: 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"

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: using interface groups in pf tables stopped working in 13.0-RELEASE

[Peter Ankerstål]

>>> 
>> I can 
>> It looks like there’s some confusion inside pfctl about the network group. 
>> It ends up in pfctl_parser.c, append_addr_host(), and expects an AF_INET or 
>> AF_INET6, but instead gets an AF_LINK.
>> 
>> It’s probably related to 250994 or possibly 
>> d2568b024da283bd2b88a633eecfc9abf240b3d8.
>> Either way it’s pretty deep in a part of the pfctl code I don’t much like. 
>> I’ll try to poke at it some more over the weekend.
>> 
> It should be fixed as of d5b08e13dd6beb3436e181ff1f3e034cc8186584 in main. 
> I’ll MFC that in about a week, and then it’ll turn up in 13.1 in the fullness 
> of time.

Nice thanks. 

I also seem to have problem even in anchors (not while using tables). But maybe 
this will also be fixed by this change.



smime.p7s
Description: S/MIME cryptographic signature

Re: using interface groups in pf tables stopped working in 13.0-RELEASE

[Kristof Provost]

On 16 Apr 2021, at 17:58, Kristof Provost wrote:

On 14 Apr 2021, at 16:16, Peter Ankerstål wrote:
In pf I use the interface group syntax alot to make the configuration 
more readable. All interfaces are assigned to a group representing 
its use/vlan name.


For example:

ifconfig_igb1_102="172.22.0.1/24 group iot description 'iot vlan' up"
ifconfig_igb1_102_ipv6="inet6 2001:470:de59:22::1/64"

ifconfig_igb1_300="172.26.0.1/24 group mgmt description 'mgmt vlan’ 
up"

ifconfig_igb1_300_ipv6="inet6 2001:470:de59:26::1/64”

in pf.conf I use these group names all over the place. But since I 
upgraded to 13.0-RELEASE it no longer works to define a table using 
the :network syntax and interface groups:


tableconst { trusted:network mgmt:network 
dmz:network guest:network edmz:network \

admin:network iot:network client:network }

If I reload the configuration I get the following:
# pfctl -f /etc/pf.conf
/etc/pf.conf:12: cannot create address buffer: Invalid argument
pfctl: Syntax error in config file: pf rules not loaded


I can reproduce that.

It looks like there’s some confusion inside pfctl about the network 
group. It ends up in pfctl_parser.c, append_addr_host(), and expects 
an AF_INET or AF_INET6, but instead gets an AF_LINK.


It’s probably related to 250994 or possibly 
d2568b024da283bd2b88a633eecfc9abf240b3d8.
Either way it’s pretty deep in a part of the pfctl code I don’t 
much like. I’ll try to poke at it some more over the weekend.


It should be fixed as of d5b08e13dd6beb3436e181ff1f3e034cc8186584 in 
main. I’ll MFC that in about a week, and then it’ll turn up in 13.1 
in the fullness of time.


Best regards,
Kristof
___
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"

13.0-RELEASE bsdinstall failure : looked for MANIFEST in wrong place (not with *.txz files)

[Mark Millard via freebsd-stable]

Booted RPi4 via micrsd card dd'd from:

FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img

I attempted a bsdinstall onto a USB3 SSD. The following
reports what happened.

# bsdinstall

default keymap Select
Hostname OK
ftp mirror OK
Auto (ZFS) OK
Install Select
stripe OK
[*] da0 OK
Last Chance! da0 YES

Error while fetching
file:///usr/freebsd-dist/MANIFEST │
: No such file or directory

OK
Exit

NOTE: the path is /usr/freebsd-dist/MANIFEST instead
of /mnt/usr/freebsd-dist/MANIFEST but . . .

# df -m
Filesystem 1M-blocks Used  Avail Capacity  Mounted on
/dev/ufs/rootfs28862 3217  2333612%/
devfs  00  0   100%/dev
/dev/msdosfs/MSDOSBOOT49   24 2549%/boot/msdos
tmpfs 500 49 1%/tmp
zroot/ROOT/default197406  183 197222 0%/mnt
zroot/tmp 1972220 197222 0%/mnt/tmp
zroot/usr/home1972220 197222 0%/mnt/usr/home
zroot/usr/ports   1972220 197222 0%/mnt/usr/ports
zroot/usr/src 1972220 197222 0%/mnt/usr/src
zroot/var/audit   1972220 197222 0%/mnt/var/audit
zroot/var/crash   1972220 197222 0%/mnt/var/crash
zroot/var/log 1972220 197222 0%/mnt/var/log
zroot/var/mail1972220 197222 0%/mnt/var/mail
zroot/var/tmp 1972220 197222 0%/mnt/var/tmp
zroot 1972220 197222 0%/mnt/zroot

# ls -Tla /mnt/usr/freebsd-dist/
total 187454
drwxr-xr-x  2 root  wheel  4 Apr  9 07:39:20 2021 .
drwxr-xr-x  6 root  wheel  6 Apr  9 07:39:20 2021 ..
-rw-r--r--  1 root  wheel  165248188 Apr  9 07:39:20 2021 base.txz
-rw-r--r--  1 root  wheel   26552108 Apr  9 07:39:21 2021 kernel.txz

# ls -Tla /usr/freebsd-dist/
ls: /usr/freebsd-dist/: No such file or directory


NOTE: creating /usr/freebsd-dist/ with a copy of the MANIFEST
file in it was enough to get past this issue: it is doing
Archive Extraction now.

===
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: using interface groups in pf tables stopped working in 13.0-RELEASE

[Kristof Provost]

On 14 Apr 2021, at 16:16, Peter Ankerstål wrote:
In pf I use the interface group syntax alot to make the configuration 
more readable. All interfaces are assigned to a group representing its 
use/vlan name.


For example:

ifconfig_igb1_102="172.22.0.1/24 group iot description 'iot vlan' up"
ifconfig_igb1_102_ipv6="inet6 2001:470:de59:22::1/64"

ifconfig_igb1_300="172.26.0.1/24 group mgmt description 'mgmt vlan’ 
up"

ifconfig_igb1_300_ipv6="inet6 2001:470:de59:26::1/64”

in pf.conf I use these group names all over the place. But since I 
upgraded to 13.0-RELEASE it no longer works to define a table using 
the :network syntax and interface groups:


tableconst { trusted:network mgmt:network 
dmz:network guest:network edmz:network \

admin:network iot:network client:network }

If I reload the configuration I get the following:
# pfctl -f /etc/pf.conf
/etc/pf.conf:12: cannot create address buffer: Invalid argument
pfctl: Syntax error in config file: pf rules not loaded


I can reproduce that.

It looks like there’s some confusion inside pfctl about the network 
group. It ends up in pfctl_parser.c, append_addr_host(), and expects an 
AF_INET or AF_INET6, but instead gets an AF_LINK.


It’s probably related to 250994 or possibly 
d2568b024da283bd2b88a633eecfc9abf240b3d8.
Either way it’s pretty deep in a part of the pfctl code I don’t much 
like. I’ll try to poke at it some more over the weekend.


Best regards,
Kristof
___
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"

13.0-RELEASE MemStick does not install EFI Loader

[Nils Johannsen]

Hi all together,

I have downloaded the memstick (link below), dd it to a usb stick, added the 
`installerconfig` (see below) to `/etc/installerconfig` and tried to install 
FreeBSD 13.0-RELEASE automatically to a PC. After rebooting the system came not 
up, because the `efi` partition should be created by `bsdinstall` was empty and 
did not include the `bootx64.efi`. After mounting the `efi` partition, creating 
the directory and copied the `/boot/loader.efi` to `/efi/boot/bootx64.efi` the 
new installed system booted up.

After `mount -u -rw /`, adding some `f_dprintf` to 
`/usr/libexec/bsdinstall/bootconfig` and a manual installation with `bsdinstall 
script /root/installerconfig | tee /root/installer.log` it generates this log:
- https://gitlab.com/-/snippets/2105237

This log indicates me, that the `efi` partition is not mounted while the 
`bootconfig` script tries to copy the `loader` to it... see below the extract 
from the `installer.log`.

MemStick:
- 
https://download.freebsd.org/ftp/releases/amd64/amd64/ISO-IMAGES/13.0/FreeBSD-13.0-RELEASE-amd64-memstick.img

installerconfig:
```
export nonInteractive="YES"
export ZFSBOOT_DISKS=ada0
DISTRIBUTIONS="kernel.txz base.txz"

#!/bin/sh
# see `man bsdinstall`
sysrc ifconfig_DEFAULT=DHCP
sysrc sshd_enable=YES
```

installer.log:
```
DEBUG: Running installation step: bootconfig
DEBUG: dialog.subr: DEBUG_SELF_INITIALIZE=[]
DEBUG: UNAME_S=[FreeBSD] UNAME_P=[amd64] UNAME_R=[13.0-RELEASE]
DEBUG: common.subr: Successfully loaded.
DEBUG:  uname -m => amd64
DEBUG:  mount => /dev/ufs/FreeBSD_Install on / (ufs, local)
devfs on /dev (devfs)
tmpfs on /tmp (tmpfs, local)
tmpfs on /var (tmpfs, local)
zroot/ROOT/default on /mnt (zfs, local, noatime, nfsv4acls)
zroot/tmp on /mnt/tmp (zfs, local, noatime, nosuid, nfsv4acls)
zroot/usr/home on /mnt/usr/home (zfs, local, noatime, nfsv4acls)
zroot/usr/ports on /mnt/usr/ports (zfs, local, noatime, nosuid, nfsv4acls)
zroot/usr/src on /mnt/usr/src (zfs, local, noatime, nfsv4acls)
zroot/var/audit on /mnt/var/audit (zfs, local, noatime, noexec, nosuid, 
nfsv4acls)
zroot/var/crash on /mnt/var/crash (zfs, local, noatime, noexec, nosuid, 
nfsv4acls)
zroot/var/log on /mnt/var/log (zfs, local, noatime, noexec, nosuid, nfsv4acls)
zroot/var/mail on /mnt/var/mail (zfs, local, nfsv4acls)
zroot/var/tmp on /mnt/var/tmp (zfs, local, noatime, nosuid, nfsv4acls)
zroot on /mnt/zroot (zfs, local, noatime, nfsv4acls)
DEBUG: Installing loader.efi onto ESP
DEBUG:  mkdir -p "/mnt/boot/efi//efi/freebsd" "/mnt/boot/efi//efi/boot"
DEBUG:  cp "/mnt/boot/loader.efi" "/mnt/boot/efi//efi/freebsd/loader.efi"
DEBUG: Creating UEFI boot entry
DEBUG:  efibootmgr --create --activate --label "FreeBSD" --loader 
"/mnt/boot/efi//efi/freebsd/loader.efi"
DEBUG: Finished configuring ESP
```

Regards from Lübeck, Nils
Beckhoff Automation GmbH & Co. KG | Managing Director: Dipl. Phys. Hans 
Beckhoff Registered office: Verl, Germany | Register court: Guetersloh HRA 7075


___
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: using interface groups in pf tables stopped working in 13.0-RELEASE

[Chris]

On 2021-04-14 11:04, Chris wrote:

On 2021-04-14 10:44, Peter Ankerstål wrote:

const { trusted:network mgmt:network dmz:network

guest:network edmz:network \
   admin:network iot:network client:network }
If I reload the configuration I get the following:
# pfctl -f /etc/pf.conf
/etc/pf.conf:12: cannot create address buffer: Invalid argument
pfctl: Syntax error in config file: pf rules not loaded

Some changes in the pf source have been made over the last couple
of months. The error returned appears to be related. It appears
that your running into a table size/count and memory allocation
related error. The first change moved/changed memory allocation to
kernel space, requiring one to increase allocation via loader.conf(5).
It was recently moved back to userspace allowing one to make changes
to a running system via sysctl.conf(5) or the commandline.
IOW if your on the recent change you should be able to simply
increase your table count by executing something like:
# echo "set limit table-entries " | pfctl -m -f -
OTOH if your stuck with the change in kernelspace, increase
net.pf.request_maxcount=
by some amount in loader.conf(5). If you are on the newer userspace
change, you can issue the sysctl(8) command at your terminal for
net.pf.request_maxcount=
as well.


I dont think so. Everything works normally if I switch from group name to 
interface name

in the config.
Sure. I only mentioned it because 1) the error you received looked almost 
exactly
the same as the one I encountered after the (pf source) changes, 2) alot of 
work

has been done recently (as I mentioned above). :-)
I'll defer to kp@ (Kristof Provost) for more insightful possibilities. As 
he's done

most all the recent work. :-)

--Chris

CC'ing pf@ for better coverage of your problem.



It seems to me that pf for some reason changed how it interprets group 
names

differently from
12.2-RELEASE-p4 and 13.0-RELEASE.

I dont really get how "anchor in from trusted:network” can resolve to 
"anchor in inet6 all”


/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"

___
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: using interface groups in pf tables stopped working in 13.0-RELEASE

[Chris]

On 2021-04-14 10:44, Peter Ankerstål wrote:

const { trusted:network mgmt:network dmz:network

guest:network edmz:network \
   admin:network iot:network client:network }
If I reload the configuration I get the following:
# pfctl -f /etc/pf.conf
/etc/pf.conf:12: cannot create address buffer: Invalid argument
pfctl: Syntax error in config file: pf rules not loaded

Some changes in the pf source have been made over the last couple
of months. The error returned appears to be related. It appears
that your running into a table size/count and memory allocation
related error. The first change moved/changed memory allocation to
kernel space, requiring one to increase allocation via loader.conf(5).
It was recently moved back to userspace allowing one to make changes
to a running system via sysctl.conf(5) or the commandline.
IOW if your on the recent change you should be able to simply
increase your table count by executing something like:
# echo "set limit table-entries " | pfctl -m -f -
OTOH if your stuck with the change in kernelspace, increase
net.pf.request_maxcount=
by some amount in loader.conf(5). If you are on the newer userspace
change, you can issue the sysctl(8) command at your terminal for
net.pf.request_maxcount=
as well.


I dont think so. Everything works normally if I switch from group name to 
interface name

in the config.
Sure. I only mentioned it because 1) the error you received looked almost 
exactly
the same as the one I encountered after the (pf source) changes, 2) alot of 
work

has been done recently (as I mentioned above). :-)
I'll defer to kp@ (Kristof Provost) for more insightful possibilities. As 
he's done

most all the recent work. :-)

--Chris


It seems to me that pf for some reason changed how it interprets group names
differently from
12.2-RELEASE-p4 and 13.0-RELEASE.

I dont really get how "anchor in from trusted:network” can resolve to 
"anchor in inet6 all”


/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"

___
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: using interface groups in pf tables stopped working in 13.0-RELEASE

[Peter Ankerstål]

const { trusted:network mgmt:network dmz:network
>> guest:network edmz:network \
>>admin:network iot:network client:network }
>> If I reload the configuration I get the following:
>> # pfctl -f /etc/pf.conf
>> /etc/pf.conf:12: cannot create address buffer: Invalid argument
>> pfctl: Syntax error in config file: pf rules not loaded
> Some changes in the pf source have been made over the last couple
> of months. The error returned appears to be related. It appears
> that your running into a table size/count and memory allocation
> related error. The first change moved/changed memory allocation to
> kernel space, requiring one to increase allocation via loader.conf(5).
> It was recently moved back to userspace allowing one to make changes
> to a running system via sysctl.conf(5) or the commandline.
> IOW if your on the recent change you should be able to simply
> increase your table count by executing something like:
> # echo "set limit table-entries " | pfctl -m -f -
> OTOH if your stuck with the change in kernelspace, increase
> net.pf.request_maxcount=
> by some amount in loader.conf(5). If you are on the newer userspace
> change, you can issue the sysctl(8) command at your terminal for
> net.pf.request_maxcount=
> as well.

I dont think so. Everything works normally if I switch from group name to 
interface name
in the config. 

It seems to me that pf for some reason changed how it interprets group names 
differently from
12.2-RELEASE-p4 and 13.0-RELEASE. 

I dont really get how "anchor in from trusted:network” can resolve to "anchor 
in inet6 all”

/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"

Re: using interface groups in pf tables stopped working in 13.0-RELEASE

[Chris]

On 2021-04-14 07:16, Peter Ankerstål wrote:

In pf I use the interface group syntax alot to make the configuration more
readable. All interfaces are assigned to a group representing its use/vlan 
name.


For example:

ifconfig_igb1_102="172.22.0.1/24 group iot description 'iot vlan' up"
ifconfig_igb1_102_ipv6="inet6 2001:470:de59:22::1/64"

ifconfig_igb1_300="172.26.0.1/24 group mgmt description 'mgmt vlan’ up"
ifconfig_igb1_300_ipv6="inet6 2001:470:de59:26::1/64”

in pf.conf I use these group names all over the place. But since I upgraded 
to
13.0-RELEASE it no longer works to define a table using the :network syntax 
and

interface groups:

tableconst { trusted:network mgmt:network dmz:network
guest:network edmz:network \
admin:network iot:network client:network }

If I reload the configuration I get the following:
# pfctl -f /etc/pf.conf
/etc/pf.conf:12: cannot create address buffer: Invalid argument
pfctl: Syntax error in config file: pf rules not loaded

Some changes in the pf source have been made over the last couple
of months. The error returned appears to be related. It appears
that your running into a table size/count and memory allocation
related error. The first change moved/changed memory allocation to
kernel space, requiring one to increase allocation via loader.conf(5).
It was recently moved back to userspace allowing one to make changes
to a running system via sysctl.conf(5) or the commandline.
IOW if your on the recent change you should be able to simply
increase your table count by executing something like:
# echo "set limit table-entries " | pfctl -m -f -
OTOH if your stuck with the change in kernelspace, increase
net.pf.request_maxcount=
by some amount in loader.conf(5). If you are on the newer userspace
change, you can issue the sysctl(8) command at your terminal for
net.pf.request_maxcount=
as well.

HTH

--Chris


I have tried to use just one network, double check the interface group 
setting and

so on, but with no luck.

to use actual interface works just fine:

table{ igb1.300:network }

but using the group fails:

# ifconfig -g mgmt
igb1.300

table{ mgmt:network }

# pfctl -f /etc/pf.conf
/etc/pf.conf:12: cannot create address buffer: Invalid argument
pfctl: Syntax error in config file: pf rules not loaded

Any ideas?

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"

___
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: using interface groups in pf tables stopped working in 13.0-RELEASE

[Peter Ankerstål]

> On 14 Apr 2021, at 16:16, Peter Ankerstål  wrote:
> 
> In pf I use the interface group syntax alot to make the configuration more 
> readable. All interfaces are assigned to a group representing its use/vlan 
> name. 

It seems that the rest of my ruleset is also affected by this, and interface 
groups combined with :network no longer work.

For example I have this anchor:
anchor in from trusted:network {
}

which before resolved to 
anchor in inet from 172.25.0.0/24 to any {
}

but now resolves to:
anchor in inet6 all {
}

/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"

using interface groups in pf tables stopped working in 13.0-RELEASE

[Peter Ankerstål]

In pf I use the interface group syntax alot to make the configuration more 
readable. All interfaces are assigned to a group representing its use/vlan 
name. 

For example:

ifconfig_igb1_102="172.22.0.1/24 group iot description 'iot vlan' up"
ifconfig_igb1_102_ipv6="inet6 2001:470:de59:22::1/64"

ifconfig_igb1_300="172.26.0.1/24 group mgmt description 'mgmt vlan’ up"
ifconfig_igb1_300_ipv6="inet6 2001:470:de59:26::1/64”

in pf.conf I use these group names all over the place. But since I upgraded to 
13.0-RELEASE it no longer works to define a table using the :network syntax and 
interface groups:

tableconst { trusted:network mgmt:network dmz:network 
guest:network edmz:network \
admin:network iot:network client:network }

If I reload the configuration I get the following:
# pfctl -f /etc/pf.conf
/etc/pf.conf:12: cannot create address buffer: Invalid argument
pfctl: Syntax error in config file: pf rules not loaded

I have tried to use just one network, double check the interface group setting 
and so on, but with no luck. 

to use actual interface works just fine:

table{ igb1.300:network }

but using the group fails:

# ifconfig -g mgmt
igb1.300

table{ mgmt:network }

# pfctl -f /etc/pf.conf
/etc/pf.conf:12: cannot create address buffer: Invalid argument
pfctl: Syntax error in config file: pf rules not loaded

Any ideas? 

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"

Re: Update to the 13.0-RELEASE schedule

[Lars Liedtke]

We don't even start before .1 is out.

Am 31.03.21 um 19:24 schrieb Rainer Duffner:
>
>> Am 31.03.2021 um 17:58 schrieb Glen Barber :
>>
>> A small set of updates that we consider blocking the 13.0 release have
>> been brought to our attention.  As such, the 13.0-RELEASE schedule has
>> been updated to include a fifth release candidate (RC5).
>>
>> The updated schedule is available on the FreeBSD Project website:
>>
>> https://www.freebsd.org/releases/13.0R/schedule/
>>
>> As usual, we will continue to consider critical bug fixes only for the
>> duration of this release cycle.
>>
>> Thank you for your cooperation, and for your patience.
>>
>> Glen
>> On behalf of:re@
>>
>
>
> The truth is that a lot people don’t really start testing until the later 
> release candidates.
>
> So, having more of these release candidates with just refinements is a good 
> thing, IMHO.
>
>
>
> ___
> 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"

-- 
---
punkt.de GmbH
Lars Liedtke
.infrastructure

Kaiserallee 13a 
76133 Karlsruhe

Tel. +49 721 9109 500
https://infrastructure.punkt.de
i...@punkt.de

AG Mannheim 108285
Geschäftsführer: Jürgen Egeling, Daniel Lienert, Fabian Stein

___
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: Update to the 13.0-RELEASE schedule

[Rainer Duffner]

> Am 31.03.2021 um 17:58 schrieb Glen Barber :
> 
> A small set of updates that we consider blocking the 13.0 release have
> been brought to our attention.  As such, the 13.0-RELEASE schedule has
> been updated to include a fifth release candidate (RC5).
> 
> The updated schedule is available on the FreeBSD Project website:
> 
> https://www.freebsd.org/releases/13.0R/schedule/
> 
> As usual, we will continue to consider critical bug fixes only for the
> duration of this release cycle.
> 
> Thank you for your cooperation, and for your patience.
> 
> Glen
> On behalf of: re@
> 



The truth is that a lot people don’t really start testing until the later 
release candidates.

So, having more of these release candidates with just refinements is a good 
thing, IMHO.



___
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: Update to the 13.0-RELEASE schedule

[The Doctor via freebsd-stable]

On Wed, Mar 31, 2021 at 03:58:51PM +, Glen Barber wrote:
> A small set of updates that we consider blocking the 13.0 release have
> been brought to our attention.  As such, the 13.0-RELEASE schedule has
> been updated to include a fifth release candidate (RC5).
> 
> The updated schedule is available on the FreeBSD Project website:
> 
> https://www.freebsd.org/releases/13.0R/schedule/
> 
> As usual, we will continue to consider critical bug fixes only for the
> duration of this release cycle.
> 
> Thank you for your cooperation, and for your patience.
> 
> Glen
> On behalf of: re@
> 

I rather that than a buggy realease.

Good show.

I will continue to test on my workstation running
a Supermicro X10sL7-f

-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising!
Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b  
We cannot change human failings by ridding ourselves of machines.  -unknown
___
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"

Update to the 13.0-RELEASE schedule

[Glen Barber]

A small set of updates that we consider blocking the 13.0 release have
been brought to our attention.  As such, the 13.0-RELEASE schedule has
been updated to include a fifth release candidate (RC5).

The updated schedule is available on the FreeBSD Project website:

https://www.freebsd.org/releases/13.0R/schedule/

As usual, we will continue to consider critical bug fixes only for the
duration of this release cycle.

Thank you for your cooperation, and for your patience.

Glen
On behalf of:   re@



signature.asc
Description: PGP signature

13.0-RELEASE schedule update

[Glen Barber]

At least one issue has been brought to our attention that affects new
installations, which as we currently have no precedent for re-rolling
ISOs and/or VM images post-release, warrant adding RC4 to the 13.0
schedule.

Please be advised that we are still only accepting critical changes
only, with the exception of a few post-RC3 requests for approval that
have trickled in.

The updated remaining milestones of the 13.0 schedule have been
committed to the Project website and also follows:

 RC4 build starts:March 26, 2021
 RELEASE build starts:April 2, 2021
 RELEASE announcement:April 6, 2021

As always, thank you for your cooperation and hard work that went into
this release, and thank you to all that have helped test the BETAs and
RCs during this cycle.

Glen
On behalf of:   re@



signature.asc
Description: PGP signature

Upgrade-report: 12.1-RELEASE --> 12.2-RELEASE

[andrew glaeser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


In a while I had not installed any package-upgrades, no idea how
dns-resolving became de-registered, when that was solved by manually
changing /etc/resolv.conf, sys-upgrade was a pure pleasure, it was so good,
boring myself to death almost in the waiting-time, just perfect (inside the
frame of today's possibilities, of course):

[see my session transscipt:]

https://attachment.irregulaire.info/FBSD12.1-upgrade-report.tx.xz

Greetings, we need much more boredom and unspectacular software-upgrades, even
system-upgrades without any regressions!



-BEGIN PGP SIGNATURE-

iF0EARECAB0WIQTF9uNaslvnJpWt8kXn6sEfJS3nCwUCYFC05gAKCRDn6sEfJS3n
C43IAJ41TFeVeZ3TzWi0TBnItSU2fbRQ5ACeOHcObQYfhM6CSK1jEtf3Fpsxgfc=
=0L9M
-END PGP SIGNATURE-
___
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: 12.2-RELEASE buildworld fail at cddl/zfs / libuutil.so

[Tomasz CEDRO]

On 27.01.2021 19:31, parv/freebsd wrote:
# git log --pretty=fuller --grep libuutil release/12.2.0. 
<http://12.2.0.>.stable/12


commit 30ec3f368d
Author:     Eugene Grosbein 
AuthorDate: Dec.2020.1206-1622 +
Commit:     Eugene Grosbein 
CommitDate: Dec.2020.1206-1622 +

     MFC r364027 by arichardson: Fix linker error in libuutil with 
recent LLVM


     This also fixes nanobsd-style build (cross-compiling).
     Original commit log:

       Not marking the function as static can result in a linker error:
       undefined reference to __assfail [--no-allow-shlib-undefined]
       I noticed this error after updating our CHERI LLVM to the latest 
upstream

       LLVM HEAD revision.

       This change effectively reverts r329984 and marks 
dmu_buf_init_user as

       static (which keeps the GCC build happy).
... above seems to (as I haven't bisected) be the fix in 12-STABLE which 
allows

the build to finish with success.
   - parv


Whoah! Mystery solved! This commit did not jump into the releng/12.2 yet 
it seems. Thank you PARV!! :-)


--
CeDeROM, SQ7MHZ, https://www.tomek.cedro.info
___
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: 12.2-RELEASE buildworld fail at cddl/zfs / libuutil.so

[parv/freebsd]

On Wed, Jan 27, 2021 at 6:10 AM Tomasz CEDRO wrote:

Hi Tomasz,

On 27.01.2021 12:52, parv/freebsd wrote:
>
...

> > # /usr/bin/time -h make buildkernel buildworld NO_CLEAN=1
> > .   ^ ^ ^ ^ ^ ^
> > Perhaps try with cleaning out first buildworld, then kernel?
>
> Well I did remove all from /usr/obj, build failed, then checked out
> /usr/src from svn, build failed, then checked out /usr/src from git, and
> it failed.
>
> Just to make sure this is not a local environment problem I have
> switched to stable/12 branch (that is 12-STABLE) and it builds fine!!
>

Thanks for the clue ...

# git log --pretty=fuller --grep libuutil release/12.2.0..stable/12

commit 30ec3f368d
Author: Eugene Grosbein 
AuthorDate: Dec.2020.1206-1622 +
Commit: Eugene Grosbein 
CommitDate: Dec.2020.1206-1622 +

MFC r364027 by arichardson: Fix linker error in libuutil with recent
LLVM

This also fixes nanobsd-style build (cross-compiling).
Original commit log:

  Not marking the function as static can result in a linker error:
  undefined reference to __assfail [--no-allow-shlib-undefined]
  I noticed this error after updating our CHERI LLVM to the latest
upstream
  LLVM HEAD revision.

  This change effectively reverts r329984 and marks dmu_buf_init_user as
  static (which keeps the GCC build happy).
... above seems to (as I haven't bisected) be the fix in 12-STABLE which
allows
the build to finish with success.

  - parv



> # git branch
>main
>releng/12.2
> * stable/12
>
...

> # /usr/bin/time -h make buildkernel buildworld release -j12
>
...

> --- kernel.full ---
> linking kernel.full
> ctfmerge -L VERSION -g -o kernel.full ...
>text  data   bssdec hex   filename
>23861318   1836970   3798784   29497072   0x1c216f0   kernel.full
> --- kernel.debug ---
> objcopy --only-keep-debug kernel.full kernel.debug
> --- kernel ---
> objcopy --strip-debug --add-gnu-debuglink=kernel.debug  kernel.full kernel
> --
>  >>> Kernel build for GENERIC completed on Wed Jan 27 08:03:22 CET 2021
> --
> `release' is up to date.
>  1h16m12.69s real5h45m44.19s user
>   28m53.59s sys
>
>
> Did anyone manage to build 12.2-RELEASE from repo? :-)
>

--
___
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: 12.2-RELEASE buildworld fail at cddl/zfs / libuutil.so

[Tomasz CEDRO]

Hello PARV :-)

On 27.01.2021 12:52, parv/freebsd wrote:
> What is the git commit hash (for others)?

For the 12.2-RELEASE:

# git branch
  main
* releng/12.2
  stable/12

# git log --pretty=oneline | head
97eb1441ca7b602510a81fd512d830563998b3e7 PS/2 Synaptics touchpad 
identification fix.
2120d07af09cb830873554ba5405c5d3e51b41cc Fix OpenSSL NULL pointer 
de-reference.
fc825298b84729facaced36d32c3fc8d111648c1 Add UPDATING entries and bump 
version.
85b4a006794d02f6e0e2f53bca3782732932a7c2 Fix multiple vulnerabilities in 
rtsold.
229d311aa42306953eb45bc55a8c5ca97312025e Fix ICMPv6 use-after-free in 
error message handling.
7b3386dba21f57907931b2e6f09f741633ea3349 Fix race condition in callout 
CPU migration.

0b4300a472c89506709341530788ad9815c05bd3 Fix uninitialized variable in ipfw.
d20c61bbc2792d5c256d4d3a1c62156ccc9eb66a Update timezone database 
information.
30710f108d29a61635778e82f300781a097caec4 Fix execve/fexecve system call 
auditing.
1d21fe9cea3f530b4cfca495632d5a1595a32270 - Switch releng/12.2 from RC3 
to RELEASE. - Add the anticipated 12.2-RELEASE date to UPDATING.  Fix 
a missing colon in the previous UPDATING entry while here. - Set a 
static __FreeBSD_version.


The first one is a simple one liner that I want to test for PS/2 
Synaptics mux identification fix.





# /usr/bin/time -h make buildkernel buildworld NO_CLEAN=1
.   ^ ^ ^ ^ ^ ^
Perhaps try with cleaning out first buildworld, then kernel?


Well I did remove all from /usr/obj, build failed, then checked out 
/usr/src from svn, build failed, then checked out /usr/src from git, and 
it failed.


Just to make sure this is not a local environment problem I have 
switched to stable/12 branch (that is 12-STABLE) and it builds fine!!


# git branch
  main
  releng/12.2
* stable/12

# git log --pretty=oneline | head
f56d7f838f5b3aa0f55b10406eaa7eb760a3ba18 elfctl: prefix disable flags 
with "no"
d7e23b5cdd8465bd50f88b1e38cb695a361a26f5 elfctl: allow features to be 
specified by value
49d3dcb041f058880486e3489ca79c9476ac7abf elfctl: add backwards 
compatibility for "no" prefixes
70cdab054c8ffe7f5561ab8f31db33ee62d12c9c rctl(4): support throttling 
resource usage to 0
7baf7a45385962d06cd2a2213109b910d40a7936 ndis: Per user request, delay 
removal to 14
2a0be7b0331c5245418cdf2893c8ba6b42a0afa5 VFS_QUOTACTL: Remove needless 
casts of arg

085997e8f05e69c66a8ffc0804b275a386ba1ca8 contrib/tzdata: import tzdata 2021a
5071cbacfb343f024bc1c9969aa43d20daa8241a safexcel: Simplify request 
allocation
804d63c0ee8f56dfac29e1fe5879740a3549d0cb safexcel: Handle command/result 
descriptor exhaustion gracefully
24ee73604483152baff9e5e3cf61047eb1c3 safexcel: Add counters for some 
resource exhaustion conditions


# /usr/bin/time -h make buildkernel buildworld release -j12
(..)
cc -target x86_64-unknown-freebsd12.2 
--sysroot=/usr/obj/usr/src/amd64.amd64/tmp 
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -c -O2 -pipe 
-fno-strict-aliasing  -g -nostdinc  -I. -I/usr/src/sys 
-I/usr/src/sys/contrib/ck/include -I/usr/src/sys/contrib/libfdt 
-D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common 
 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer 
-fdebug-prefix-map=./machine=/usr/src/sys/amd64/include 
-fdebug-prefix-map=./x86=/usr/src/sys/x86/include -mcmodel=kernel 
-mno-red-zone -mno-mmx -mno-sse -msoft-float 
-fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector 
-gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes 
-Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef 
-Wno-pointer-sign -D__printf__=__freebsd_kprintf__ 
-Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas 
-Wno-error-tautological-compare -Wno-error-empty-body 
-Wno-error-parentheses-equality -Wno-error-unused-function 
-Wno-error-pointer-sign -Wno-error-shift-negative-value 
-Wno-address-of-packed-member -Wno-format-zero-length  -mno-aes -mno-avx 
 -std=iso9899:1999 -Werror  vers.c

ctfconvert -L VERSION -g vers.o
--- kernel.full ---
linking kernel.full
ctfmerge -L VERSION -g -o kernel.full ...
  text  data   bssdec hex   filename
  23861318   1836970   3798784   29497072   0x1c216f0   kernel.full
--- kernel.debug ---
objcopy --only-keep-debug kernel.full kernel.debug
--- kernel ---
objcopy --strip-debug --add-gnu-debuglink=kernel.debug  kernel.full kernel
--
>>> Kernel build for GENERIC completed on Wed Jan 27 08:03:22 CET 2021
------
`release' is up to date.
1h16m12.69s real5h45m44.19s user 
 28m53.59s sys



Did anyone manage to build 12.2-RELEASE from repo? :-)

--
CeDeROM, SQ7MHZ, https://www.tomek.cedro.info
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubs

Re: 12.2-RELEASE buildworld fail at cddl/zfs / libuutil.so

[parv/freebsd]

 On Tue, Jan 26, 2021 at 7:45 PM Tomasz CEDRO wrote:

> I cannot buildworld for 12.2-RELEASE. Using /usr/src as svn or git no
> matter (its set to releng/12.2). Did clean /usr/obj. Any hints welcome :-)
>
> # uname -a
> FreeBSD hexagon 12.2-RELEASE-p1 FreeBSD 12.2-RELEASE-p1 GENERIC  amd64
>

What is the git commit hash (for others)?

I had recently compiled 12-STABLE (c243308-ge82353584c58) without issues;
running
as guest in VirtualBox on MS Windows 10.



> # /usr/bin/time -h make buildkernel buildworld NO_CLEAN=1
>
.   ^ ^ ^ ^ ^ ^
Perhaps try with cleaning out first buildworld, then kernel?

  - parv

(..)
> ===> bin/tests (all)
> ===> cddl (all)
> ===> cddl/lib (all)
> ===> cddl/lib/drti (all)
> ===> cddl/lib/libavl (all)
> ===> cddl/lib/libctf (all)
> ===> cddl/lib/libdtrace (all)
> ===> cddl/lib/libnvpair (all)
> ===> cddl/lib/libumem (all)
> ===> cddl/lib/libuutil (all)
> ===> cddl/lib/libzfs_core (all)
> ===> cddl/lib/libzfs (all)
> ===> cddl/lib/libzpool (all)
> ===> cddl/lib/tests (all)
> ===> cddl/sbin (all)
> ===> cddl/sbin/zfs (all)
> cc -target x86_64-unknown-freebsd12.2
> --sysroot=/usr/obj/usr/src/amd64.amd64/tmp
> -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe -fno-common
> -I/usr/src/cddl/contrib/opensolaris/lib/libzpool/common
> -I/usr/src/cddl/compat/opensolaris/include
> -I/usr/src/cddl/compat/opensolaris/lib/libumem
> -I/usr/src/sys/cddl/compat/opensolaris
> -I/usr/src/cddl/contrib/opensolaris/head
> -I/usr/src/cddl/contrib/opensolaris/lib/libuutil/common
> -I/usr/src/cddl/contrib/opensolaris/lib/libzfs/common
> -I/usr/src/cddl/contrib/opensolaris/lib/libzfs_core/common
> -I/usr/src/cddl/contrib/opensolaris/lib/libumem/common
> -I/usr/src/cddl/contrib/opensolaris/lib/libnvpair
> -I/usr/src/sys/cddl/contrib/opensolaris/uts/common
> -I/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs
> -I/usr/src/sys/cddl/contrib/opensolaris/common/zfs
> -DNEED_SOLARIS_BOOLEAN -g -O0 -std=gnu99 -fstack-protector-strong
> -Wno-pointer-sign -Wno-unknown-pragmas -Wno-empty-body
> -Wno-string-plus-int -Wno-unused-const-variable
> -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality
> -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef
> -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum
> -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments   -o
> zfs.full zfs_main.o zfs_iter.o   -ljail  -lnvpair  -luutil  -lzfs_core
> -lzfs
> ld: error: /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libuutil.so:
> undefined reference to __assfail
> cc: error: linker command failed with exit code 1 (use -v to see
> invocation)
> *** Error code 1
>
> Stop.
> make[5]: stopped in /usr/src/cddl/sbin/zfs
> *** Error code 1
> (..)
>

--
___
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"

12.2-RELEASE buildworld fail at cddl/zfs / libuutil.so

[Tomasz CEDRO]

Hello world!

I cannot buildworld for 12.2-RELEASE. Using /usr/src as svn or git no 
matter (its set to releng/12.2). Did clean /usr/obj. Any hints welcome :-)


# uname -a
FreeBSD hexagon 12.2-RELEASE-p1 FreeBSD 12.2-RELEASE-p1 GENERIC  amd64

# /usr/bin/time -h make buildkernel buildworld NO_CLEAN=1
(..)
===> bin/tests (all)
===> cddl (all)
===> cddl/lib (all)
===> cddl/lib/drti (all)
===> cddl/lib/libavl (all)
===> cddl/lib/libctf (all)
===> cddl/lib/libdtrace (all)
===> cddl/lib/libnvpair (all)
===> cddl/lib/libumem (all)
===> cddl/lib/libuutil (all)
===> cddl/lib/libzfs_core (all)
===> cddl/lib/libzfs (all)
===> cddl/lib/libzpool (all)
===> cddl/lib/tests (all)
===> cddl/sbin (all)
===> cddl/sbin/zfs (all)
cc -target x86_64-unknown-freebsd12.2 
--sysroot=/usr/obj/usr/src/amd64.amd64/tmp 
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe -fno-common 
-I/usr/src/cddl/contrib/opensolaris/lib/libzpool/common 
-I/usr/src/cddl/compat/opensolaris/include 
-I/usr/src/cddl/compat/opensolaris/lib/libumem 
-I/usr/src/sys/cddl/compat/opensolaris 
-I/usr/src/cddl/contrib/opensolaris/head 
-I/usr/src/cddl/contrib/opensolaris/lib/libuutil/common 
-I/usr/src/cddl/contrib/opensolaris/lib/libzfs/common 
-I/usr/src/cddl/contrib/opensolaris/lib/libzfs_core/common 
-I/usr/src/cddl/contrib/opensolaris/lib/libumem/common 
-I/usr/src/cddl/contrib/opensolaris/lib/libnvpair 
-I/usr/src/sys/cddl/contrib/opensolaris/uts/common 
-I/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs 
-I/usr/src/sys/cddl/contrib/opensolaris/common/zfs 
-DNEED_SOLARIS_BOOLEAN -g -O0 -std=gnu99 -fstack-protector-strong 
-Wno-pointer-sign -Wno-unknown-pragmas -Wno-empty-body 
-Wno-string-plus-int -Wno-unused-const-variable 
-Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality 
-Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef 
-Wno-address-of-packed-member -Wno-switch -Wno-switch-enum 
-Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments   -o 
zfs.full zfs_main.o zfs_iter.o   -ljail  -lnvpair  -luutil  -lzfs_core 
-lzfs
ld: error: /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libuutil.so: 
undefined reference to __assfail

cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** Error code 1

Stop.
make[5]: stopped in /usr/src/cddl/sbin/zfs
*** Error code 1
(..)
39m18.71s real  33m45.09s user  4m10.23s sys

--
CeDeROM, SQ7MHZ, https://www.tomek.cedro.info
___
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: 12.2-RELEASE and ctwm

[Greg Balfour]

On Mon, Dec 14, 2020 at 8:33 AM Greg Balfour  wrote:
>
> I just upgraded a machine from 11.4-RELEASE to 12.2-RELEASE.  Using
> the same version of ctwm (4.0.3,1 installed from packages) with the
> same .ctwmrc, things behave differently and I don't know why.
>
> My first problem is the middle button on my Logitech TrackMan Marble
> PS/2 mouse is no longer recognized by ctwm.
>
> Button2 =   : root  : f.menu "windowops"
>
> This worked under 11.4-RELEASE but doesn't any more.  Using Button1
> or Button3 works fine.  However the middle button does work within
> an xterm to do a paste.
>
> Secondly, these two lines from .ctwmrc don't work until I restart ctwm
> with either a kill -HUP or by calling f.restart from a ctwm menu.
>
> "Right" = c : all   : f.nextworkspace
> "Left" = c  : all   : f.prevworkspace
>
> After restarting ctwm these key bindings work.
>
> This machine has integrated Intel(R) HD Graphics 2000 and I'm using
> the xf86-video-intel driver package along with building the
> graphics/drm-kmod port.
>
> Can someone recommend some things to look at to resolve these issues?

So on a whim I built a new kernel commenting out these lines:

#optionsEVDEV_SUPPORT   # evdev support in legacy drivers
#device evdev   # input event device support
#device uinput  # install /dev/uinput cdev

Which also necessitated commenting out the following in /etc/rc.conf:

#kld_list="/boot/modules/drm.ko /boot/modules/i915kms.ko"

And after rebooting all the issues I mentioned above went away.
So I guess I have an evdev problem.  But I still don't know what
to do about it.
___
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: 12.2-RELEASE and ctwm

[Kurt Jaeger]

Hi!

> I just upgraded a machine from 11.4-RELEASE to 12.2-RELEASE.  Using
> the same version of ctwm (4.0.3,1 installed from packages) with the
> same .ctwmrc, things behave differently and I don't know why.
> 
> My first problem is the middle button on my Logitech TrackMan Marble
> PS/2 mouse is no longer recognized by ctwm.
> 
> Button2 =   : root  : f.menu "windowops"

Thanks -- I've seen the same with tvtwm (from 12.1 to 12.2!)

> Can someone recommend some things to look at to resolve these issues?

I hope for the same answer 8-}

-- 
p...@opsec.eu+49 171 3101372Now what ?
___
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"

12.2-RELEASE and ctwm

[Greg Balfour]

I just upgraded a machine from 11.4-RELEASE to 12.2-RELEASE.  Using
the same version of ctwm (4.0.3,1 installed from packages) with the
same .ctwmrc, things behave differently and I don't know why.

My first problem is the middle button on my Logitech TrackMan Marble
PS/2 mouse is no longer recognized by ctwm.

Button2 =   : root  : f.menu "windowops"

This worked under 11.4-RELEASE but doesn't any more.  Using Button1
or Button3 works fine.  However the middle button does work within
an xterm to do a paste.

Secondly, these two lines from .ctwmrc don't work until I restart ctwm
with either a kill -HUP or by calling f.restart from a ctwm menu.

"Right" = c : all   : f.nextworkspace
"Left" = c  : all   : f.prevworkspace

After restarting ctwm these key bindings work.

This machine has integrated Intel(R) HD Graphics 2000 and I'm using
the xf86-video-intel driver package along with building the
graphics/drm-kmod port.

Can someone recommend some things to look at to resolve these issues?
___
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"

12.2 release, blacklistd with ipfw gives error

[Kris von Mach via freebsd-stable]

Hello,

I've upgraded a working blacklistd with ipfw server from 12.1 to 12.2 
and now it gives the following error:


blacklistd[51583]: getnum: /etc/blacklistd.conf, 22: Bad number for 
service []


My config:

rc.conf:
blacklistd_enable="YES" # 
activates blacklistd
sshd_flags="-o UseBlackList=yes"    # instruct sshd to report to 
blacklistd

firewall_enable="YES"
firewall_type="OPEN"
blacklistd_flags="-f"

/etc/ipfw-blacklist.rc exists:
-rw-r--r--  1 root  wheel  0 Nov  4  2018 /etc/ipfw-blacklist.rc

blacklistd.conf:
# $FreeBSD: releng/12.2/usr.sbin/blacklistd/blacklistd.conf 336977 
2018-07-31 16:39:38Z brd $

#
# Blacklist rule
# adr/mask:port type    proto   owner   name    nfail disable
[local]
ssh stream  *   *   *   3   24h
ftp stream  *   *   *   3   24h
smtp    stream  *   *   *   3   24h
submission  stream  *   *   *   3   24h
#6161   stream  tcp6    christos    *   2   10m
*   *   *   *   *   3   60

# adr/mask:port type    proto   owner   name    nfail disable
[remote]
#129.168.0.0/16 *   *   *   =   *   *
#6161   =   =   =   =/24    =   =
#*  stream  tcp *   =   =   =


services are running:
root 37234    0.0  0.0    19600    8224  -  Is   04:41 0:00.00 
/usr/sbin/sshd -o UseBlackList=yes
root 52033    0.0  0.0    11740    2840  -  Ss   04:41 0:00.00 
/usr/sbin/blacklistd -f


ipfw list
1 deny ip from table(1) to me
00100 allow ip from any to any via lo0
00200 deny ip from any to 127.0.0.0/8
00300 deny ip from 127.0.0.0/8 to any
00400 deny ip from any to ::1
00500 deny ip from ::1 to any
00600 allow ipv6-icmp from :: to ff02::/16
00700 allow ipv6-icmp from fe80::/10 to fe80::/10
00800 allow ipv6-icmp from fe80::/10 to ff02::/16
00900 allow ipv6-icmp from any to any icmp6types 1
01000 allow ipv6-icmp from any to any icmp6types 2,135,136
65000 allow ip from any to any
65535 deny ip from any to any

table port22 isn't created

Is this a bug or am I missing some change in the config?

___
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: Waiting for FreeBSD 12.2-RELEASE

[Ruben van Staveren via freebsd-stable]

Hi Jack,

> On 26 Oct 2020, at 22:31, Jack Raats  wrote:
> 
> 
> I bought a new a PC and now eager waiting for the new release to arrive!!!


Don’t hold your horses, install now (unless your hardware is not listed as 
supported in https://www.freebsd.org/releases/12.1R/hardware.html) and use the 
excellent freebsd-update when it arrives!

Good luck!


> 
> 
> 
> ___
> 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"
> 



signature.asc
Description: Message signed with OpenPGP

Waiting for FreeBSD 12.2-RELEASE

[Jack Raats]

I bought a new a PC and now eager waiting for the new release to arrive!!!



___
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"

11.4-RELEASE i386 won't boot

[Greg Balfour]

I have an ancient Pentium machine(*) that I've been keeping up to
date using freebsd-update.  It has run everything fine up through
11.3-RELEASE-p11.  However it does not like the 11.4-RELEASE kernel.

  /boot/kernel/kernel text=0x128f22b data=0xe9748+0x2890f4
syms=[0x4+0xea3e0+0x4+0x1797e9]
  /boot/entropy size=0x1000

  Hit [Enter] to boot immediately, or any other key for command prompt.
  Booting [/boot/kernel/kernel] in 9 seconds...

  Type '?' for a list of commands, 'help' for more detailed help.
  OK set boot_verbose
  OK boot
  Booting...
  \
  int=0006  err=  efl=00010002  eip=c0ba6fa2
  eax=0001  ebx=0201ec00  ecx=  edx=c19ef18c
  esi=c19eed34  edi=c19eeaa0  ebp=c201fd08  esp=c19ee704
  cs=0008  ds=0010  es=0010fs=0010  gs=0010  ss=0010
  cs:eip=0f 45 d1 c1 e0 04 89 56-20 66 89 46 26 a1 d0 2c
 95 c1 89 46 28 5e 5d c3-90 90 90 90 90 90 55 89
  ss:esp=00 00 00 00 00 00 00 00-00 00 00 00 0c e7 9e c1
 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
  BTX halted

The old 11.3 kernel still boots fine.

  /boot/kernel.old/kernel text=0x12941cb data=0xe8e74+0x2890ec
syms=[0x4+0xe9c90+0x4+0x178d4c]
  OK boot -s
  Booting...
  Copyright (c) 1992-2019 The FreeBSD Project.
  Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
  The Regents of the University of California. All rights reserved.
  FreeBSD is a registered trademark of The FreeBSD Foundation.
  FreeBSD 11.3-RELEASE-p11 #0: Wed Jul  8 05:39:37 UTC 2020
r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386
  FreeBSD clang version 8.0.0 (tags/RELEASE_800/final 356365) (based
on LLVM 8.0.0)
  VT(vga): resolution 640x480
  CPU: Pentium/P55C (233.03-MHz 586-class CPU)
Origin="GenuineIntel"  Id=0x543  Family=0x5  Model=0x4  Stepping=3
Features=0x8001bf
  real memory  = 133169152 (127 MB)
  avail memory = 98197504 (93 MB)
  ...

The kernel file is good and there's nothing in loader.conf that
should cause a problem.

# md5 -r /boot/kernel/kernel
40f1065ab4aff80489b456386e9721c0 /boot/kernel/kernel

# cat /boot/loader.conf
console="comconsole vidconsole"
hint.acpi.0.disabled=1  # removing this doesn't help
beastie_disable="YES"

Any suggestions?

(*) I occasionally have to pull data off 5-1/4 inch floppies and this
machine is equipped to do that.
___
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: `efivar -l` fails on UEFI booted 11.4-RELEASE

[Warner Losh]

On Sun, Jun 28, 2020, 1:52 AM Dimitry Andric  wrote:

> On 28 Jun 2020, at 04:21, Kyle Evans  wrote:
> >
> > On Sat, Jun 27, 2020 at 8:04 PM Yasuhiro KIMURA 
> wrote:
> >>
> >> On UEFI booted 11.4-RELEASE system `efivar -l` fails as following.
> >>
> >> root@rolling-vm-freebsd3[160]# uname -a
> >> FreeBSD rolling-vm-freebsd3.home.utahime.org 11.4-RELEASE FreeBSD
> 11.4-RELEASE #0 r362094: Fri Jun 12 18:27:15 UTC 2020
>  r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64
> >> root@rolling-vm-freebsd3[161]# efivar -l
> >> efivar: Error listing names: No such file or directory
>
> Perhaps the efivar utility could suggest loading the module in this case?
>

The trouble I'd that this error also means other things too. It's a lot
more than changing the printf here.

Warner

>
___
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: `efivar -l` fails on UEFI booted 11.4-RELEASE

[Dimitry Andric]

On 28 Jun 2020, at 04:21, Kyle Evans  wrote:
> 
> On Sat, Jun 27, 2020 at 8:04 PM Yasuhiro KIMURA  wrote:
>> 
>> On UEFI booted 11.4-RELEASE system `efivar -l` fails as following.
>> 
>> root@rolling-vm-freebsd3[160]# uname -a
>> FreeBSD rolling-vm-freebsd3.home.utahime.org 11.4-RELEASE FreeBSD 
>> 11.4-RELEASE #0 r362094: Fri Jun 12 18:27:15 UTC 2020 
>> r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64
>> root@rolling-vm-freebsd3[161]# efivar -l
>> efivar: Error listing names: No such file or directory

Perhaps the efivar utility could suggest loading the module in this case?

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: `efivar -l` fails on UEFI booted 11.4-RELEASE

[Yasuhiro KIMURA]

From: Kyle Evans 
Subject: Re: `efivar -l` fails on UEFI booted 11.4-RELEASE
Date: Sat, 27 Jun 2020 21:21:10 -0500

> This should be an easy fix. :-) EFI Runtime Services on FreeBSD
> ("EFIRT") wasn't necessarily globally stable until right around 12.0.
> For 11.x, you'll need to `kldload efirt` or add `options EFIRT` to
> your kernel config before efivar/efibootmgr become usable.

Thank you for reply. After loading efirt.ko `efivar -l` succesfully
lists UEFI environment variables.

---
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: `efivar -l` fails on UEFI booted 11.4-RELEASE

[Kyle Evans]

On Sat, Jun 27, 2020 at 8:04 PM Yasuhiro KIMURA  wrote:
>
> On UEFI booted 11.4-RELEASE system `efivar -l` fails as following.
>
> root@rolling-vm-freebsd3[160]# uname -a
> FreeBSD rolling-vm-freebsd3.home.utahime.org 11.4-RELEASE FreeBSD 
> 11.4-RELEASE #0 r362094: Fri Jun 12 18:27:15 UTC 2020 
> r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64
> root@rolling-vm-freebsd3[161]# efivar -l
> efivar: Error listing names: No such file or directory
> root@rolling-vm-freebsd3[162]#
>
> It also happens with latest (20200625) 11-STABLE snapshot, but not
> with either 12.1-RELEASE or 13-CURRENT.
>

Hi,

This should be an easy fix. :-) EFI Runtime Services on FreeBSD
("EFIRT") wasn't necessarily globally stable until right around 12.0.
For 11.x, you'll need to `kldload efirt` or add `options EFIRT` to
your kernel config before efivar/efibootmgr become usable.

Thanks,

Kyle Evans
___
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"

`efivar -l` fails on UEFI booted 11.4-RELEASE

[Yasuhiro KIMURA]

On UEFI booted 11.4-RELEASE system `efivar -l` fails as following.

root@rolling-vm-freebsd3[160]# uname -a
FreeBSD rolling-vm-freebsd3.home.utahime.org 11.4-RELEASE FreeBSD 11.4-RELEASE 
#0 r362094: Fri Jun 12 18:27:15 UTC 2020 
r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64
root@rolling-vm-freebsd3[161]# efivar -l
efivar: Error listing names: No such file or directory
root@rolling-vm-freebsd3[162]#

It also happens with latest (20200625) 11-STABLE snapshot, but not
with either 12.1-RELEASE or 13-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: 11.4-RELEASE make delete-old

[Dimitry Andric]

On 27 Jun 2020, at 03:55, Greg Balfour  wrote:
> 
> On a fresh install of 11.4-RELEASE, rebuilding the operating system
> results in several files being deleted during the "make delete-old"
> step.  This surprised me.  I wouldn't have expected this on a rebuild
> of a new install without any updates applied.  See below, but for
> example /usr/bin/llvm-ar is present after the initial install but is then
> removed by the "make delete-old" step.  Is this to be expected?
> Is the correct action to respond y when prompted about the files?
> 
> root@test:/usr/src # make -j 4 buildworld buildkernel
> ...
> root@test:/usr/src # make installkernel
> ...
> root@test:/usr/src # make installworld
> ...
> root@test:/usr/src # make delete-old
>>>> Removing old files (only deletes safe to delete libs)
> remove /usr/bin/llvm-ar? y
> remove /usr/lib/debug/usr/bin/llvm-ar.debug? y
> remove /usr/bin/llvm-nm? y
> remove /usr/lib/debug/usr/bin/llvm-nm.debug? y
> remove /usr/bin/llvm-ranlib? y
> remove /usr/share/man/man1/llvm-ar.1.gz? y
> remove /usr/share/man/man1/llvm-nm.1.gz? y
> remove /usr/share/man/man1/llvm-symbolizer.1.gz? y
>>>> Old files removed
>>>> Removing old directories
>>>> Old directories removed
> To remove old libraries run 'make delete-old-libs'.

Hmm, you found an issue in tools/build/mk/OptionalObsoleteFiles.inc. At
some point llvm-ar, llvm-nm, llvm-objdump and llvm-symbolizer got
promoted out of MK_CLANG_EXTRAS, so they always get installed. But in
OptionalObsoleteFiles they are still under MK_CLANG_EXTRAS, so if you
don't have that enabled, they are proposed for deletion.

I have MFCd a few additional changes to fix this, in:
https://svnweb.freebsd.org/changeset/base/362674

but this will have to be manually applied to your source tree, if you
don't want to get prompted anymore. Otherwise, simply ignore the
removal requests.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

11.4-RELEASE make delete-old

[Greg Balfour]

On a fresh install of 11.4-RELEASE, rebuilding the operating system
results in several files being deleted during the "make delete-old"
step.  This surprised me.  I wouldn't have expected this on a rebuild
of a new install without any updates applied.  See below, but for
example /usr/bin/llvm-ar is present after the initial install but is then
removed by the "make delete-old" step.  Is this to be expected?
Is the correct action to respond y when prompted about the files?

root@test:/usr/src # make -j 4 buildworld buildkernel
...
root@test:/usr/src # make installkernel
...
root@test:/usr/src # make installworld
...
root@test:/usr/src # make delete-old
>>> Removing old files (only deletes safe to delete libs)
remove /usr/bin/llvm-ar? y
remove /usr/lib/debug/usr/bin/llvm-ar.debug? y
remove /usr/bin/llvm-nm? y
remove /usr/lib/debug/usr/bin/llvm-nm.debug? y
remove /usr/bin/llvm-ranlib? y
remove /usr/share/man/man1/llvm-ar.1.gz? y
remove /usr/share/man/man1/llvm-nm.1.gz? y
remove /usr/share/man/man1/llvm-symbolizer.1.gz? y
>>> Old files removed
>>> Removing old directories
>>> Old directories removed
To remove old libraries run 'make delete-old-libs'.
___
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: Firefox pkg for 11.4-RELEASE amd64

[Kurt Jaeger]

Hi!

> After looking at this some more I see the problem.
> 
> http://pkg.freebsd.org/FreeBSD:11:amd64/release_4/All/
[...]
> Anyone know why firefox didn't make it into release_4?

No, but I've started a build on https://repo.nepustil.net/114/, so
that you can get it from there in a few hours.

-- 
p...@opsec.eu+49 171 3101372Now what ?
___
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: Firefox pkg for 11.4-RELEASE amd64

[Greg Balfour]

After looking at this some more I see the problem.

http://pkg.freebsd.org/FreeBSD:11:amd64/release_4/All/

is missing firefox.  Both

http://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/
and
http://pkg.freebsd.org/FreeBSD:11:amd64/quarterly/All/

have it.  I had created a /usr/local/etc/pkg/repos/FreeBSD.conf
with the url set to "pkg+http://pkg.FreeBSD.org/${ABI}/release_4;
so pkg wasn't seeing it.  I do this with new releases since I
don't want to track latest or quarterly packages.  (It makes
adding packages at a much later date easier.)

Anyone know why firefox didn't make it into release_4?

On Wed, Jun 17, 2020 at 4:22 PM Greg Balfour  wrote:
>
> I don't see a firefox package for 11.4-RELEASE amd64.  There's one
> for i386, but not amd64.  Do I have to use firefox-esr for amd64?
> (I'm looking for a prebuilt package, don't want to build the port.)
___
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"

Firefox pkg for 11.4-RELEASE amd64

[Greg Balfour]

I don't see a firefox package for 11.4-RELEASE amd64.  There's one
for i386, but not amd64.  Do I have to use firefox-esr for amd64?
(I'm looking for a prebuilt package, don't want to build the port.)
___
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"

esting FreeBSD-11.3-RELEASE-amd64-bootonly.iso / Installation (UEFI) fails

[Christian Jeannot]

Hello Community,

I am testing FreeBSD-11.3-RELEASE-amd64-bootonly.iso. It fails to boot 
from UEFI.


My environment:
- CPU: AMD Ryze 3900X
- Mainboard: MSI MEG ACE X570, Default settings, latest BIOS 7C35v18
- RAM: G.Skill RipJaws V DIMM Kit 64GB, DDR4-3200, CL16-18-18-38
- GPU: Sapphire Nitro RX 5700XT

Image was created on a Mac mini 2014 with the following procedure 
described and discussed In 
https://forums.freebsd.org/threads/howto-create-freebsd-usb-bootable-disk-from-a-mac.38774/.


FreeBSD 11.3 release is not booting. It hangs after
- Entering boot menu (BIOS)
- selecting the proper entry
- pressing enter
- Messages from Boat loader from Image showing up

I can see on the screen:
…
BootCurrent: 000b
BootOrder 0003 0004 0009 000a 000b(*) 0001 0002
Failed to find bootable partition.

I am able to use 12.1 RELEASE boot only iso image for an installation so 
my actual system setup should be fine in general.


I have checked the Release Notes, Errata and bugzilla but found nothing 
obviously for my issue.

I tested several USB sticks. No difference.
The SHA256 checksum is ok.

Is there an error on my doing or did I miss something?
Could this still be an issue on my mainboard?

Regards

—Christian


--

christian jeannot
vogelmauer 17
86152 augsburg
+49 821 81552861
i...@os-plus.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"

FreeBSD 11.3-RELEASE-p7 is approaching its End-of-Life date ?

[Andreas Ott]

[I am not sure if this is the correct mailing list but trying to access
other "releng" archives is giving me only 502 at the moment]


I am trying to run freebsd-upgrade this morning to get fixes for the SAs.
The system gives me this message:


WARNING: FreeBSD 11.3-RELEASE-p7 is approaching its End-of-Life date.
It is strongly recommended that you upgrade to a newer
release within the next 2 months.


Neither security page nor releng page show any end of support dates
within two months, combining "11.4-RELEASE + 3 months" and "11.4-RELEASE 
June 2020" respectively.

Would it be possible to update whatever file this trigger comes from to
make the warning message be in line with upcoming release schedules?

Thanks, andreas
- 
Andreas Ott   K6OTT   +1.408.431.8727   andr...@naund.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: /usr/src/release/release.sh -> ports -> fetch pkg -> Bad system call (core dumped)

[Tomasz CEDRO]

Summing up the time cost for a clean svn co and make buildkernel
buildworld release is around 75minutes while the chroot build with
release(7) is around 100minutes for my hardware setup. Builds using
make are more reasonable for driver fixes because then I can only
rebuild small part of the code which will result in much shorter build
times. Very nice to experience :-)

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
___
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: /usr/src/release/release.sh -> ports -> fetch pkg -> Bad system call (core dumped)

[Tomasz CEDRO]

On Wed, Apr 8, 2020 at 8:19 PM Ruslan Garipov wrote:
> > I need to see how it works with `make release` :-)
> This is what I meant when saying "you can build the source tree for
> 13.0-CURRENT on 12.1-RELEASE"; sorry if I've confused you.

No worries, my little confusion came from `make release` being a bit picky:
1. I need to buildworld first (can use -j switch, make release will
not call it).
2. I need to buildkernel first (can use -j switch, make release will
not call it).
3. Only then I can run `make release` (cannot use -j switch).

I get as good result as I need with memstick and iso images in around
19 minutes plus I can build CURRENT that way.. now I may be ready to
cross-compile :-)

3858.923u 331.683s 19:19.24 361.4%  171+561k 499674+1215072io 131833pf+0w


> Check ``Building with release.sh on -STABLE'' thread[1] on the forum.
> May be it can help you.

Thank you for the reference! :-)


> "2h looks really cool" because release(7) may build chrooted build
> environment, where it then may build port(s) and builds the target.  My
> Xeons usually spends 1.5 hours on clean release(7) (with 16 make(1)
> jobs).

A bit better but very similar result, thanks for reference.. and the
SSD hint :-)

With this power I can compile a clean firmware for my projects based
on ARM mbedOS  in 2 minutes instead 12 minutes (as compared to laptop
build) and connect the build to a git hook.. then speeding up a bit
could return a binary right away as a result of git push :-) :-)

In a free moment it would be fun to play with FreeBSD on ARM.. I have
tried that several times before but with no luck.. and I really have
different boards around to test :-)

Again GREAT THANK YOU Ruslan for your time support and all hints!! :-)

Tomek

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
___
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: /usr/src/release/release.sh -> ports -> fetch pkg -> Bad system call (core dumped)

[Ruslan Garipov]

On 4/8/2020 9:05 PM, Tomasz CEDRO wrote:
> On Sun, Apr 5, 2020 at 7:53 PM Ruslan Garipov wrote:
>>> I wrongly assumed that release will simply update this svn repo that I
>>> am working on.. but it fetches HEAD.. so I was trying to build
>>> 13/HEAD/CURRENT on 12/STABLE/RELEASE that have different ABI thus bad
>>> syscall.. and I need CURRENT to build CURRENT, right? :-)
>> I believe in order to build the source tree you just need a compatible
>> toolchain.  So you can build the source tree for 13.0-CURRENT on
>> 12.1-RELEASE system.  But you need CURRENT to **run** userland with ABI
>> from the CURRENT.
> 
> Long story short I need 13-CURRENT to create a 13-CURRENT release with
> release(7) because on 12-STABLE/RELEASE chroot with 13-CURRENT does
> not work.
Of course, because release(7) runs built userland; in your case it runs
userland with FreeBSD 13 ABI on FreeBSD 12.x host.

> I need to see how it works with `make release` :-)
This is what I meant when saying "you can build the source tree for
13.0-CURRENT on 12.1-RELEASE"; sorry if I've confused you.

Check ``Building with release.sh on -STABLE'' thread[1] on the forum.
May be it can help you.

> 
> 
>> Once again: for native build `make release` may be quite easy and fast.
>> release(7) guarantees "absolutely clean build environment".
> 
> Will try that `make release` as well, also for 13-CURRENT on
> 12-STABLE, thank you! Also will compare the time cost with the one
> presented below :-)
> 
> 
> Creating a "release" also has this advantage that I have memstick
> images that I can boot from directly, test what I need, even no need
> to install :-)
> 
> Here are my build times, for a release for AMD64/12-STABLE, I did not
> select DOC nor PORTS to build, only Kernel and Base :-)
> 
> BUILD HOST (~$500): HP PROLIANT DL380G7X (HDD 1TB, 128GB RAM, 24vCPU =
> 2 x Intel Xeon X5660 @2.8GHz = 2 PACKAGES x 6 CORES x 2 HW THREADS )
> INTERNET: 600/60MBit
> 
> time make clean buildkernel (16x speedup with SMP):
> 2472.027u 291.657s 46:34.54 98.8%   38592+3123k
> 195123+3315182io 80167pf+0w
> -j122355.140u 282.807s 3:40.12 1198.4%  38509+3121k
> 190142+3361605io 71356pf+0w
> -j243672.641u 382.254s 2:54.85 2319.0%  39837+3149k
> 218567+3361605io 64857pf+0w
> -j483722.707u 352.940s 3:07.10 2178.3%  40328+3169k
> 214359+3361607io 66526pf+0w
> 
> time make clean buildworld (12.5x speedup with SMP):
> 32223.598u 1940.942s 9:28:07.59 100.2% 46920+3430k
> 563493+3074126io 234706pf+0w
> -j1233644.438u 1818.147s 54:46.68 1078.9% 47324+3449k
> 485257+3255853io 236896pf+0w
> -j2450728.732u 2556.953s 45:06.66 1968.6% 47556+3455k
> 560905+3255862io 229433pf+0w
> -j4851129.166u 2454.564s 44:38.12 2000.7% 47630+3458k
> 525602+3255854io 210237pf+0w
> 
> release.sh (seems to auto-adjust -j optimization and below 2h looks
> really cool):
Yes, release(7) sets number of make(1) jobs to the number of available
CPUs (hw.ncpu) for buildworld target, and half of that number for
buildkernel one.

"2h looks really cool" because release(7) may build chrooted build
environment, where it then may build port(s) and builds the target.  My
Xeons usually spends 1.5 hours on clean release(7) (with 16 make(1)
jobs).

> 94556.462u 5583.273s 1:43:14.24 1616.6% 50234+3336k
> 1457023+16921354io 615421pf+0w
> -j12   94477.001u 5577.692s 1:42:59.60 1619.1% 50251+3337k
> 1463964+16932952io 617689pf+0w
> -j24   94480.274u 5574.117s 1:43:38.89 1608.8% 50213+3336k
> 1468685+16931170io 617425pf+0w
> -j48   94588.653u 5569.909s 1:43:10.62 1617.9% 50211+3336k
> 1460546+16925145io 611229pf+0w
> 
> These times may be even smaller when SSD is used instead of HDD.
For me it almost changed nothing, only CPU resources counted.

> Also
> I wonder how to utilize all RAM to speed up the compilation because I
> can see 8..34GB utilization while the rest of 128GB remains unused.
By installing additional CPU(s) which will allow you to run more make(1)
jobs in parallel.  My -j16 builds consume about 16-18 GB (at peaks).

> I
> saw some ramdisk tricks I need to try that as well :-)
> 
> Best regards :-)
> Tomek
> 

[1]
https://forums.freebsd.org/threads/building-with-release-sh-on-stable.70889/
___
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: /usr/src/release/release.sh -> ports -> fetch pkg -> Bad system call (core dumped)

[Tomasz CEDRO]

On Sun, Apr 5, 2020 at 7:53 PM Ruslan Garipov wrote:
> > I wrongly assumed that release will simply update this svn repo that I
> > am working on.. but it fetches HEAD.. so I was trying to build
> > 13/HEAD/CURRENT on 12/STABLE/RELEASE that have different ABI thus bad
> > syscall.. and I need CURRENT to build CURRENT, right? :-)
> I believe in order to build the source tree you just need a compatible
> toolchain.  So you can build the source tree for 13.0-CURRENT on
> 12.1-RELEASE system.  But you need CURRENT to **run** userland with ABI
> from the CURRENT.

Long story short I need 13-CURRENT to create a 13-CURRENT release with
release(7) because on 12-STABLE/RELEASE chroot with 13-CURRENT does
not work. I need to see how it works with `make release` :-)


> Once again: for native build `make release` may be quite easy and fast.
> release(7) guarantees "absolutely clean build environment".

Will try that `make release` as well, also for 13-CURRENT on
12-STABLE, thank you! Also will compare the time cost with the one
presented below :-)


Creating a "release" also has this advantage that I have memstick
images that I can boot from directly, test what I need, even no need
to install :-)

Here are my build times, for a release for AMD64/12-STABLE, I did not
select DOC nor PORTS to build, only Kernel and Base :-)

BUILD HOST (~$500): HP PROLIANT DL380G7X (HDD 1TB, 128GB RAM, 24vCPU =
2 x Intel Xeon X5660 @2.8GHz = 2 PACKAGES x 6 CORES x 2 HW THREADS )
INTERNET: 600/60MBit

time make clean buildkernel (16x speedup with SMP):
2472.027u 291.657s 46:34.54 98.8%   38592+3123k
195123+3315182io 80167pf+0w
-j122355.140u 282.807s 3:40.12 1198.4%  38509+3121k
190142+3361605io 71356pf+0w
-j243672.641u 382.254s 2:54.85 2319.0%  39837+3149k
218567+3361605io 64857pf+0w
-j483722.707u 352.940s 3:07.10 2178.3%  40328+3169k
214359+3361607io 66526pf+0w

time make clean buildworld (12.5x speedup with SMP):
32223.598u 1940.942s 9:28:07.59 100.2% 46920+3430k
563493+3074126io 234706pf+0w
-j1233644.438u 1818.147s 54:46.68 1078.9% 47324+3449k
485257+3255853io 236896pf+0w
-j2450728.732u 2556.953s 45:06.66 1968.6% 47556+3455k
560905+3255862io 229433pf+0w
-j4851129.166u 2454.564s 44:38.12 2000.7% 47630+3458k
525602+3255854io 210237pf+0w

release.sh (seems to auto-adjust -j optimization and below 2h looks
really cool):
94556.462u 5583.273s 1:43:14.24 1616.6% 50234+3336k
1457023+16921354io 615421pf+0w
-j12   94477.001u 5577.692s 1:42:59.60 1619.1% 50251+3337k
1463964+16932952io 617689pf+0w
-j24   94480.274u 5574.117s 1:43:38.89 1608.8% 50213+3336k
1468685+16931170io 617425pf+0w
-j48   94588.653u 5569.909s 1:43:10.62 1617.9% 50211+3336k
1460546+16925145io 611229pf+0w

These times may be even smaller when SSD is used instead of HDD. Also
I wonder how to utilize all RAM to speed up the compilation because I
can see 8..34GB utilization while the rest of 128GB remains unused. I
saw some ramdisk tricks I need to try that as well :-)

Best regards :-)
Tomek

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
___
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: /usr/src/release/release.sh -> ports -> fetch pkg -> Bad system call (core dumped)

[Ruslan Garipov]

On 4/5/2020 10:05 PM, Tomasz CEDRO wrote:
> On Sun, Apr 5, 2020 at 4:59 PM Ruslan Garipov wrote:
>> I'm sorry, I forgot to ask how do you call /usr/src/release/release.sh?
>> Do you pass a configuration file to this script?
>>
>> By default /usr/src/release/release.sh checks out the source tree for
>> the CURRENT branch (svn://svn.FreeBSD.org/base/head@rHEAD).  In this
>> case (if you doesn't change it) chrooted environment definitely will
>> fail to run on STABLE and/or RELEASE.
>>
>> May be it's easy for you to use `make release` directly.
> 
> Case solved! =)
> 
> I wrongly assumed that release will simply update this svn repo that I
> am working on.. but it fetches HEAD.. so I was trying to build
> 13/HEAD/CURRENT on 12/STABLE/RELEASE that have different ABI thus bad
> syscall.. and I need CURRENT to build CURRENT, right? :-)
I believe in order to build the source tree you just need a compatible
toolchain.  So you can build the source tree for 13.0-CURRENT on
12.1-RELEASE system.  But you need CURRENT to **run** userland with ABI
from the CURRENT.

In order to build, for example, 12.1-RELEASE image with release(7) you
should assign the SRCBRANCH variable to "base/release/12.1.0@rHEAD", and
for 12.0-STABLE: SRCBRANCH="base/stable/12@rHEAD".  Either in your
configuration file for release(7) or directly in your shell:

env SRCBRANCH="base/release/12.1.0@rHEAD" /usr/src/release/release.sh

> 
> I will provide a release.conf, make.conf, src.conf and maybe KERNCONF
> if I need something beyond GENERIC. For now I just need to work with
> 12-STABLE. Good hint! :-)
Sure.  Just as a note, by default (when the caller doesn't provide a
configuration file to release(7), or the file provided doesn't exists),
release(7) builds GENERIC kernel and uses no make.conf and src.conf.

Once again: for native build `make release` may be quite easy and fast.
release(7) guarantees "absolutely clean build environment".

> 
> Thank you Ruslan!! :-)
> 
> Tomek
> 
> ps/2: Can I provide a patch that will print out what actually is being
> fetched by release.sh? That could save some time for first time users
> :-)
Why not :-)

For me reading /usr/src/release/release.sh and default configs for ARM
saved me a lot of time.
___
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: /usr/src/release/release.sh -> ports -> fetch pkg -> Bad system call (core dumped)

[Tomasz CEDRO]

On Sun, Apr 5, 2020 at 4:59 PM Ruslan Garipov wrote:
> I'm sorry, I forgot to ask how do you call /usr/src/release/release.sh?
> Do you pass a configuration file to this script?
>
> By default /usr/src/release/release.sh checks out the source tree for
> the CURRENT branch (svn://svn.FreeBSD.org/base/head@rHEAD).  In this
> case (if you doesn't change it) chrooted environment definitely will
> fail to run on STABLE and/or RELEASE.
>
> May be it's easy for you to use `make release` directly.

Case solved! =)

I wrongly assumed that release will simply update this svn repo that I
am working on.. but it fetches HEAD.. so I was trying to build
13/HEAD/CURRENT on 12/STABLE/RELEASE that have different ABI thus bad
syscall.. and I need CURRENT to build CURRENT, right? :-)

I will provide a release.conf, make.conf, src.conf and maybe KERNCONF
if I need something beyond GENERIC. For now I just need to work with
12-STABLE. Good hint! :-)

Thank you Ruslan!! :-)

Tomek

ps/2: Can I provide a patch that will print out what actually is being
fetched by release.sh? That could save some time for first time users
:-)

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
___
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: /usr/src/release/release.sh -> ports -> fetch pkg -> Bad system call (core dumped)

[Ruslan Garipov]

On 4/5/2020 6:52 PM, Tomasz CEDRO wrote:
> Hello Ruslav and thank you for your feedback! :-)
> 
> On Sun, Apr 5, 2020 at 3:07 PM Ruslan Garipov wrote:
>> On 4/4/2020 7:50 PM, Tomasz CEDRO wrote:
>>> 1. Is it a good build / testing environment? Maybe there is a simpler
>>> / better way to cross compile binaries and test on another machine?
>>> Both are using 12.1-RELEASE AMD64 installations so far. All /usr/local
>>> should work both with 12.1-RELEASE and 12-STABLE right?
>> Both machines have the same architecture, therefore it is not a cross
>> build, I believe.  For my direct builds (both build and consumer
>> machines are x86-64) I use the procedure described in the handbook
>> (``23.6. Tracking for Multiple Machines''[1]).
> 
> I know that method, thank you :-) But I also want to try out the
> binary release, which seems a bit more flexible to have just
> everything in one place, may be used to install on an external machine
> without NFS access, etc :-)
> 
> It would be also nice to know the time cost of those two methods, so I
> want to verify :-)
> 
> 
>>> 3. During /usr/src/release/release.sh I get following error as pasted
>>> below. Does release.sh update /usr/ports just as it snaps from svn or
>>> it will use the /usr/porst that are just there and I need to provide
>>> /usr/ports in a state that will be bindled into a /scratch release?
>> A quote from release(7) man page:
>>
>> release.sh checks out the src/, ports/, and doc/ trees to CHROOTDIR...
>>
>> Therefore, release(7) "ignores" /usr/ports and uses
>> ${CHROOTDIR}/usr/ports.  My build machine doesn't have access to the
>> Internet, therefore, I have to define the PORTS_UPDATE_SKIP variable and
>> provide ports tree into the ${CHROOTDIR}/usr/ports before
>> I will call /usr/src/release/release.sh.
> 
> Okay, so the build uses totally separate CHROOT in /scratch? I wonder
> if that "Bad System Call" is caused by my Host tools or the CHROOT
> tools?
> 
> It looks like the /scratch has its own compiled in tools not a copy
> from my host?
> 
> # diff -u /usr/bin/fetch /scratch/usr/bin/fetch
> Binary files /usr/bin/fetch and /scratch/usr/bin/fetch differ
I'm sorry, I forgot to ask how do you call /usr/src/release/release.sh?
Do you pass a configuration file to this script?

By default /usr/src/release/release.sh checks out the source tree for
the CURRENT branch (svn://svn.FreeBSD.org/base/head@rHEAD).  In this
case (if you doesn't change it) chrooted environment definitely will
fail to run on STABLE and/or RELEASE.

May be it's easy for you to use `make release` directly.
> 
> 
>>> ===>   docproj-2.0_14 depends on file: /usr/local/sbin/pkg - not found
>>> ===>  License BSD2CLAUSE accepted by the user
>>> ===> Fetching all distfiles required by pkg-1.14.2 for building
>>> ===>  Extracting for pkg-1.14.2
>>> ===>  License BSD2CLAUSE accepted by the user
>>> ===> Fetching all distfiles required by pkg-1.14.2 for building
>>> => SHA256 Checksum mismatch for freebsd-pkg-1.14.2_GH0.tar.gz.
>>> ===>  Refetch for 1 more times files:  freebsd-pkg-1.14.2_GH0.tar.gz
>>> ===>  License BSD2CLAUSE accepted by the user
>>> => freebsd-pkg-1.14.2_GH0.tar.gz doesn't seem to exist in /tmp/distfiles/.
>>> => Attempting to fetch
>>> https://codeload.github.com/freebsd/pkg/tar.gz/1.14.2?dummy=/freebsd-pkg-1.14.2_GH0.tar.gz
>>> freebsd-pkg-1.14.2_GH0.tar.gz Bad system call (core dumped)
>> /usr/src/release/release.sh defines DISTDIR=/tmp/distfiles when it
>> installs the textproc/docproj port or a port from the ${EMBEDDEDPORTS}.
>>
>> As for why fetch(1) fails with bad system call under chrooted
>> environment -- I don't know.  I failed on a port fetching only if I
>> hadn't provided all necessary distfiles.  You have checksum error
>> message which is causing refetching of the ports-mgmt/pkg port.
>> Therefore, I believe
>> ${CHROOTDIR}/tmp/distfiles/freebsd-pkg-1.14.2_GH0.tar.gz exists on your
>> file system (remained from a previous fetch try?)...  May be you should
>> try fetch(1) from the chrooted environment manually, to get any content?
> 
> This "Bad System Call" stops me from proceeding. I did place by hand
> the required package in the right place, then it built ok, then I got
> that "Bad System Call" again on install :-(
> 
> How can I get the debug symbols in /scratch binaries?
> 
> So far I can just show:
> [New LWP 100764]
> Core was generated by `/usr/bin/fetch -Fpr -S 3405355
> http://distcache.FreeBSD.org/ports-distfiles/fre

Re: /usr/src/release/release.sh -> ports -> fetch pkg -> Bad system call (core dumped)

[Ruslan Garipov]

On 4/5/2020 6:52 PM, Tomasz CEDRO wrote:
> Hello Ruslav and thank you for your feedback! :-)
> 
> On Sun, Apr 5, 2020 at 3:07 PM Ruslan Garipov wrote:
>> On 4/4/2020 7:50 PM, Tomasz CEDRO wrote:
>>> 1. Is it a good build / testing environment? Maybe there is a simpler
>>> / better way to cross compile binaries and test on another machine?
>>> Both are using 12.1-RELEASE AMD64 installations so far. All /usr/local
>>> should work both with 12.1-RELEASE and 12-STABLE right?
>> Both machines have the same architecture, therefore it is not a cross
>> build, I believe.  For my direct builds (both build and consumer
>> machines are x86-64) I use the procedure described in the handbook
>> (``23.6. Tracking for Multiple Machines''[1]).
> 
> I know that method, thank you :-) But I also want to try out the
> binary release, which seems a bit more flexible to have just
> everything in one place, may be used to install on an external machine
> without NFS access, etc :-)
> 
> It would be also nice to know the time cost of those two methods, so I
> want to verify :-)
> 
> 
>>> 3. During /usr/src/release/release.sh I get following error as pasted
>>> below. Does release.sh update /usr/ports just as it snaps from svn or
>>> it will use the /usr/porst that are just there and I need to provide
>>> /usr/ports in a state that will be bindled into a /scratch release?
>> A quote from release(7) man page:
>>
>> release.sh checks out the src/, ports/, and doc/ trees to CHROOTDIR...
>>
>> Therefore, release(7) "ignores" /usr/ports and uses
>> ${CHROOTDIR}/usr/ports.  My build machine doesn't have access to the
>> Internet, therefore, I have to define the PORTS_UPDATE_SKIP variable and
>> provide ports tree into the ${CHROOTDIR}/usr/ports before
>> I will call /usr/src/release/release.sh.
> 
> Okay, so the build uses totally separate CHROOT in /scratch?
Yes.

> I wonder
> if that "Bad System Call" is caused by my Host tools or the CHROOT
> tools?
By the chrooted environment within the ${CHROOTDIR} I believe.
Otherwise you would get the same error on "host".

> 
> It looks like the /scratch has its own compiled in tools not a copy
> from my host?
Yes, release(7) builds and installs clean userland into the ${CHROOTDIR}
(DESTDIR=${CHROOTDIR}), and doesn't copy it from the "host".

> 
> # diff -u /usr/bin/fetch /scratch/usr/bin/fetch
> Binary files /usr/bin/fetch and /scratch/usr/bin/fetch differ
> 
> 
>>> ===>   docproj-2.0_14 depends on file: /usr/local/sbin/pkg - not found
>>> ===>  License BSD2CLAUSE accepted by the user
>>> ===> Fetching all distfiles required by pkg-1.14.2 for building
>>> ===>  Extracting for pkg-1.14.2
>>> ===>  License BSD2CLAUSE accepted by the user
>>> ===> Fetching all distfiles required by pkg-1.14.2 for building
>>> => SHA256 Checksum mismatch for freebsd-pkg-1.14.2_GH0.tar.gz.
>>> ===>  Refetch for 1 more times files:  freebsd-pkg-1.14.2_GH0.tar.gz
>>> ===>  License BSD2CLAUSE accepted by the user
>>> => freebsd-pkg-1.14.2_GH0.tar.gz doesn't seem to exist in /tmp/distfiles/.
>>> => Attempting to fetch
>>> https://codeload.github.com/freebsd/pkg/tar.gz/1.14.2?dummy=/freebsd-pkg-1.14.2_GH0.tar.gz
>>> freebsd-pkg-1.14.2_GH0.tar.gz Bad system call (core dumped)
>> /usr/src/release/release.sh defines DISTDIR=/tmp/distfiles when it
>> installs the textproc/docproj port or a port from the ${EMBEDDEDPORTS}.
>>
>> As for why fetch(1) fails with bad system call under chrooted
>> environment -- I don't know.  I failed on a port fetching only if I
>> hadn't provided all necessary distfiles.  You have checksum error
>> message which is causing refetching of the ports-mgmt/pkg port.
>> Therefore, I believe
>> ${CHROOTDIR}/tmp/distfiles/freebsd-pkg-1.14.2_GH0.tar.gz exists on your
>> file system (remained from a previous fetch try?)...  May be you should
>> try fetch(1) from the chrooted environment manually, to get any content?
> 
> This "Bad System Call" stops me from proceeding. I did place by hand
> the required package in the right place, then it built ok, then I got
> that "Bad System Call" again on install :-(
> 
> How can I get the debug symbols in /scratch binaries?
You need to provide custom src.conf or/and make.conf to release(7).

I, actually, provide make.conf, src.conf and kernel config (not for the
debug symbols; just for tuning the target release).

> 
> So far I can just show:
> [New LWP 100764]
> Core was generated by `/usr/bin/fetch -Fpr -S 3405

Re: /usr/src/release/release.sh -> ports -> fetch pkg -> Bad system call (core dumped)

[Tomasz CEDRO]

Hello Ruslav and thank you for your feedback! :-)

On Sun, Apr 5, 2020 at 3:07 PM Ruslan Garipov wrote:
> On 4/4/2020 7:50 PM, Tomasz CEDRO wrote:
> > 1. Is it a good build / testing environment? Maybe there is a simpler
> > / better way to cross compile binaries and test on another machine?
> > Both are using 12.1-RELEASE AMD64 installations so far. All /usr/local
> > should work both with 12.1-RELEASE and 12-STABLE right?
> Both machines have the same architecture, therefore it is not a cross
> build, I believe.  For my direct builds (both build and consumer
> machines are x86-64) I use the procedure described in the handbook
> (``23.6. Tracking for Multiple Machines''[1]).

I know that method, thank you :-) But I also want to try out the
binary release, which seems a bit more flexible to have just
everything in one place, may be used to install on an external machine
without NFS access, etc :-)

It would be also nice to know the time cost of those two methods, so I
want to verify :-)


> > 3. During /usr/src/release/release.sh I get following error as pasted
> > below. Does release.sh update /usr/ports just as it snaps from svn or
> > it will use the /usr/porst that are just there and I need to provide
> > /usr/ports in a state that will be bindled into a /scratch release?
> A quote from release(7) man page:
>
> release.sh checks out the src/, ports/, and doc/ trees to CHROOTDIR...
>
> Therefore, release(7) "ignores" /usr/ports and uses
> ${CHROOTDIR}/usr/ports.  My build machine doesn't have access to the
> Internet, therefore, I have to define the PORTS_UPDATE_SKIP variable and
> provide ports tree into the ${CHROOTDIR}/usr/ports before
> I will call /usr/src/release/release.sh.

Okay, so the build uses totally separate CHROOT in /scratch? I wonder
if that "Bad System Call" is caused by my Host tools or the CHROOT
tools?

It looks like the /scratch has its own compiled in tools not a copy
from my host?

# diff -u /usr/bin/fetch /scratch/usr/bin/fetch
Binary files /usr/bin/fetch and /scratch/usr/bin/fetch differ


> > ===>   docproj-2.0_14 depends on file: /usr/local/sbin/pkg - not found
> > ===>  License BSD2CLAUSE accepted by the user
> > ===> Fetching all distfiles required by pkg-1.14.2 for building
> > ===>  Extracting for pkg-1.14.2
> > ===>  License BSD2CLAUSE accepted by the user
> > ===> Fetching all distfiles required by pkg-1.14.2 for building
> > => SHA256 Checksum mismatch for freebsd-pkg-1.14.2_GH0.tar.gz.
> > ===>  Refetch for 1 more times files:  freebsd-pkg-1.14.2_GH0.tar.gz
> > ===>  License BSD2CLAUSE accepted by the user
> > => freebsd-pkg-1.14.2_GH0.tar.gz doesn't seem to exist in /tmp/distfiles/.
> > => Attempting to fetch
> > https://codeload.github.com/freebsd/pkg/tar.gz/1.14.2?dummy=/freebsd-pkg-1.14.2_GH0.tar.gz
> > freebsd-pkg-1.14.2_GH0.tar.gz Bad system call (core dumped)
> /usr/src/release/release.sh defines DISTDIR=/tmp/distfiles when it
> installs the textproc/docproj port or a port from the ${EMBEDDEDPORTS}.
>
> As for why fetch(1) fails with bad system call under chrooted
> environment -- I don't know.  I failed on a port fetching only if I
> hadn't provided all necessary distfiles.  You have checksum error
> message which is causing refetching of the ports-mgmt/pkg port.
> Therefore, I believe
> ${CHROOTDIR}/tmp/distfiles/freebsd-pkg-1.14.2_GH0.tar.gz exists on your
> file system (remained from a previous fetch try?)...  May be you should
> try fetch(1) from the chrooted environment manually, to get any content?

This "Bad System Call" stops me from proceeding. I did place by hand
the required package in the right place, then it built ok, then I got
that "Bad System Call" again on install :-(

How can I get the debug symbols in /scratch binaries?

So far I can just show:
[New LWP 100764]
Core was generated by `/usr/bin/fetch -Fpr -S 3405355
http://distcache.FreeBSD.org/ports-distfiles/free'.
Program terminated with signal SIGSYS, Bad system call.
#0  0x0008003c1bca in ?? ()
(gdb) bt
#0  0x0008003c1bca in ?? ()
#1  0x00080031d144 in ?? ()
#2  0x00080031d260 in ?? ()
#3  0x0008 in ?? ()
#4  0xb650b69b3fd03fb8 in ?? ()
#5  0x7fffdd40 in ?? ()
#6  0x7fffe64c in ?? ()
#7  0x000800e1d000 in ?? ()
#8  0x002091e0 in ?? ()
#9  0x7fffdc80 in ?? ()
#10 0x7fffdc40 in ?? ()
#11 0x00080031d2f9 in ?? ()
#12 0x000800e1d000 in ?? ()
#13 0x7fffdd40 in ?? ()
#14 0x in ?? ()


Thank you! :-)
Tomek

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
___
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: /usr/src/release/release.sh -> ports -> fetch pkg -> Bad system call (core dumped)

[Ruslan Garipov]

On 4/4/2020 7:50 PM, Tomasz CEDRO wrote:
> Hello world :-)
> 
> I would like to build a 12-STABLE (/usr/src contains
> svn.freebsd.org/base/stable/12) locally on strong machine (24CPU 127GB
> RAM 12-1-RELEASE AMD64), then test changes on my local machine
> (panasonic toughbook i5 laptop 12.1-RELEASE AMD64). This will be used
> for testing kernel patches and driver development/fixes.
> 
> The goal is to have separate zroot/ROOT/stable to select and act as
> the FreeBSD base. So far I have zroot/ROOT/default to use FreeBSD
> 12.1-RELEASE. I would like to switch between those to on boot to have
> one base system stable for working and another base system for testing
> on real environment.
> 
> I noticed that simple copy of /boot/kernel does not work on my target
> machine. Thus I am trying to create a whole release, put a separate
> system base, then on boot select different zfs container base to boot
> from. I just love ZFS for that! I may even use snapshots to log and
> rollback changes.
> 
> Questions:
> 
> 1. Is it a good build / testing environment? Maybe there is a simpler
> / better way to cross compile binaries and test on another machine?
> Both are using 12.1-RELEASE AMD64 installations so far. All /usr/local
> should work both with 12.1-RELEASE and 12-STABLE right?
Both machines have the same architecture, therefore it is not a cross
build, I believe.  For my direct builds (both build and consumer
machines are x86-64) I use the procedure described in the handbook
(``23.6. Tracking for Multiple Machines''[1]).

> 
> 2. When that works, I would like to cross-compile for ARM in a similar
> manner, then attach pyOCD + GDB to debug ARM target. I guess that
> should work too as above?
> 
> 3. During /usr/src/release/release.sh I get following error as pasted
> below. Does release.sh update /usr/ports just as it snaps from svn or
> it will use the /usr/porst that are just there and I need to provide
> /usr/ports in a state that will be bindled into a /scratch release?
A quote from release(7) man page:

release.sh checks out the src/, ports/, and doc/ trees to CHROOTDIR...

Therefore, release(7) "ignores" /usr/ports and uses
${CHROOTDIR}/usr/ports.  My build machine doesn't have access to the
Internet, therefore, I have to define the PORTS_UPDATE_SKIP variable and
provide ports tree into the ${CHROOTDIR}/usr/ports before
I will call /usr/src/release/release.sh.

> 
> ===>   docproj-2.0_14 depends on file: /usr/local/sbin/pkg - not found
> ===>  License BSD2CLAUSE accepted by the user
> ===> Fetching all distfiles required by pkg-1.14.2 for building
> ===>  Extracting for pkg-1.14.2
> ===>  License BSD2CLAUSE accepted by the user
> ===> Fetching all distfiles required by pkg-1.14.2 for building
> => SHA256 Checksum mismatch for freebsd-pkg-1.14.2_GH0.tar.gz.
> ===>  Refetch for 1 more times files:  freebsd-pkg-1.14.2_GH0.tar.gz
> ===>  License BSD2CLAUSE accepted by the user
> => freebsd-pkg-1.14.2_GH0.tar.gz doesn't seem to exist in /tmp/distfiles/.
> => Attempting to fetch
> https://codeload.github.com/freebsd/pkg/tar.gz/1.14.2?dummy=/freebsd-pkg-1.14.2_GH0.tar.gz
> freebsd-pkg-1.14.2_GH0.tar.gz Bad system call (core dumped)
/usr/src/release/release.sh defines DISTDIR=/tmp/distfiles when it
installs the textproc/docproj port or a port from the ${EMBEDDEDPORTS}.

As for why fetch(1) fails with bad system call under chrooted
environment -- I don't know.  I failed on a port fetching only if I
hadn't provided all necessary distfiles.  You have checksum error
message which is causing refetching of the ports-mgmt/pkg port.
Therefore, I believe
${CHROOTDIR}/tmp/distfiles/freebsd-pkg-1.14.2_GH0.tar.gz exists on your
file system (remained from a previous fetch try?)...  May be you should
try fetch(1) from the chrooted environment manually, to get any content?

> => Attempting to fetch
> http://distcache.FreeBSD.org/ports-distfiles/freebsd-pkg-1.14.2_GH0.tar.gz
> freebsd-pkg-1.14.2_GH0.tar.gz Bad system call (core dumped)
> => Couldn't fetch it - please try to retrieve this
> => port manually into /tmp/distfiles/ and try again.
> *** Error code 1
> 
> Stop.
> 
> Any hints and comments are welcome :-)
> Tomek
> 
[1]
https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/small-lan.html
___
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"

/usr/src/release/release.sh -> ports -> fetch pkg -> Bad system call (core dumped)

[Tomasz CEDRO]

Hello world :-)

I would like to build a 12-STABLE (/usr/src contains
svn.freebsd.org/base/stable/12) locally on strong machine (24CPU 127GB
RAM 12-1-RELEASE AMD64), then test changes on my local machine
(panasonic toughbook i5 laptop 12.1-RELEASE AMD64). This will be used
for testing kernel patches and driver development/fixes.

The goal is to have separate zroot/ROOT/stable to select and act as
the FreeBSD base. So far I have zroot/ROOT/default to use FreeBSD
12.1-RELEASE. I would like to switch between those to on boot to have
one base system stable for working and another base system for testing
on real environment.

I noticed that simple copy of /boot/kernel does not work on my target
machine. Thus I am trying to create a whole release, put a separate
system base, then on boot select different zfs container base to boot
from. I just love ZFS for that! I may even use snapshots to log and
rollback changes.

Questions:

1. Is it a good build / testing environment? Maybe there is a simpler
/ better way to cross compile binaries and test on another machine?
Both are using 12.1-RELEASE AMD64 installations so far. All /usr/local
should work both with 12.1-RELEASE and 12-STABLE right?

2. When that works, I would like to cross-compile for ARM in a similar
manner, then attach pyOCD + GDB to debug ARM target. I guess that
should work too as above?

3. During /usr/src/release/release.sh I get following error as pasted
below. Does release.sh update /usr/ports just as it snaps from svn or
it will use the /usr/porst that are just there and I need to provide
/usr/ports in a state that will be bindled into a /scratch release?

===>   docproj-2.0_14 depends on file: /usr/local/sbin/pkg - not found
===>  License BSD2CLAUSE accepted by the user
===> Fetching all distfiles required by pkg-1.14.2 for building
===>  Extracting for pkg-1.14.2
===>  License BSD2CLAUSE accepted by the user
===> Fetching all distfiles required by pkg-1.14.2 for building
=> SHA256 Checksum mismatch for freebsd-pkg-1.14.2_GH0.tar.gz.
===>  Refetch for 1 more times files:  freebsd-pkg-1.14.2_GH0.tar.gz
===>  License BSD2CLAUSE accepted by the user
=> freebsd-pkg-1.14.2_GH0.tar.gz doesn't seem to exist in /tmp/distfiles/.
=> Attempting to fetch
https://codeload.github.com/freebsd/pkg/tar.gz/1.14.2?dummy=/freebsd-pkg-1.14.2_GH0.tar.gz
freebsd-pkg-1.14.2_GH0.tar.gz Bad system call (core dumped)
=> Attempting to fetch
http://distcache.FreeBSD.org/ports-distfiles/freebsd-pkg-1.14.2_GH0.tar.gz
freebsd-pkg-1.14.2_GH0.tar.gz Bad system call (core dumped)
=> Couldn't fetch it - please try to retrieve this
=> port manually into /tmp/distfiles/ and try again.
*** Error code 1

Stop.

Any hints and comments are welcome :-)
Tomek

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
___
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"

12.1-RELEASE-p1 kernel crash

[Marek Salwerowicz]

Hi all,

I run a following server:

- Supermicro 6047R-E1R36L
- 96 GB RAM
- 1x INTEL CPU E5-2640 v2 @ 2.00GHz
- FreeBSD 10.3-RELEASE-p11

Drive for OS:
- HW RAID1: 2x KINGSTON SV300S37A120G

zpool1:
- 9x WD RED 4TB ; 9x HGST HUS726040ALA610 @ raidz2
- log: mirrored Intel 730 SSD
- cache: single Intel 730 SSD

zpool2:

- 6x HGST HUH721010ALN604 @raidz2
- 6x HGST HUH721010ALN604 @raidz2


The servers works as NFS filer for VMWare ESXi servers. It's been 
working flawlessly for several years.


On Mid-December 2019 I performed upgrade from 10.3-RELEASE to 
12.1-RELEASE-p1. After 60 days of operating, the system rebooted with 
core dump:


Unread portion of the kernel message buffer:


Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 02
fault virtual address    = 0x410
fault code        = supervisor read data, page not present
instruction pointer    = 0x20:0x80bda098
stack pointer        = 0x28:0xfe0102085e00
frame pointer        = 0x28:0xfe0102085eb0
code segment        = base 0x0, limit 0xf, type 0x1b
            = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags    = interrupt enabled, resume, IOPL = 0
current process        = 1067 (nfsd: service)
trap number        = 12
panic: page fault
cpuid = 2
time = 1581660610
KDB: stack backtrace:
#0 0x80c1d297 at kdb_backtrace+0x67
#1 0x80bd05cd at vpanic+0x19d
#2 0x80bd0423 at panic+0x43
#3 0x810a7dcc at trap_fatal+0x39c
#4 0x810a7e19 at trap_pfault+0x49
#5 0x810a740f at trap+0x29f
#6 0x81081a0c at calltrap+0x8
#7 0x828f79fb at zio_change_priority+0x12b
#8 0x82841dc5 at arc_read+0xf5
#9 0x8284f5c8 at dbuf_read+0x728
#10 0x8285ac23 at dmu_buf_hold_array_by_dnode+0x1f3
#11 0x8285c757 at dmu_read_uio_dnode+0x37
#12 0x8285c88b at dmu_read_uio_dbuf+0x3b
#13 0x82926772 at zfs_freebsd_read+0x2c2
#14 0x8122a1b6 at VOP_READ_APV+0x76
#15 0x80b014e3 at nfsvno_read+0x373
#16 0x80af6366 at nfsrvd_read+0x5c6
#17 0x80adcee8 at nfsrvd_dorpc+0x658
Uptime: 60d11h16m56s
Dumping 11451 out of 98232 
MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%


0x80bd039b in doadump (textdump=) at 
/usr/src/sys/kern/kern_shutdown.c:365

365        if (dumping)
(kgdb) list *0x80bda098
0x80bda098 is in _sx_xlock_hard (/usr/src/sys/sys/systm.h:262).
257        struct thread_lite *td;
258
259        td = (struct thread_lite *)curthread;
260        KASSERT(td->td_critnest != 0,
261            ("critical_exit: td_critnest == 0"));
262        __compiler_membar();
263        td->td_critnest--;
264        __compiler_membar();
265        if (__predict_false(td->td_owepreempt))
266            critical_exit_preempt();
(kgdb) backtrace
#0  0x80bd039b in doadump (textdump=) at 
/usr/src/sys/kern/kern_shutdown.c:365
#1  0x80bd03c5 in doadump (textdump=) at 
/usr/src/sys/kern/kern_shutdown.c:371
#2  0x80bd01c8 in kern_reboot (howto=260) at 
/usr/src/sys/kern/kern_shutdown.c:450
#3  0x80bd0629 in vpanic (fmt=, ap=out>) at /usr/src/sys/kern/kern_shutdown.c:873
#4  0x80bd0423 in panic (fmt=) at 
/usr/src/sys/kern/kern_shutdown.c:803
#5  0x810a7dcc in trap_fatal (frame=0xfe0102085d40, 
eva=1040) at /usr/src/sys/amd64/amd64/trap.c:943
#6  0x810a7e19 in trap_pfault (frame=0xfe0102085d40, 
usermode=0) at /usr/src/sys/amd64/amd64/trap.c:767
#7  0x810a740f in trap (frame=0xfe0102085d40) at 
/usr/src/sys/amd64/amd64/trap.c:443
#8  0x81081a0c in alltraps_pushregs_no_rax () at 
/usr/src/sys/amd64/amd64/exception.S:273

#9  0x in ?? ()


The same situation happened 2 weeks later.

I have coredump saved from 14th of February.


I have temporarily disabled  it from operations and test RAM using 
Memtest 4.8.7, however after 12-13 hours of tests running no RAM issues 
were reported so far.



Is there anything more I can try to debug using kdbg and how to find 
root cause?



Best regards,
Marek


--
Marek Salwerowicz
MISAL-SYSTEM

___
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-12.1-RELEASE-amd64.vmdk.xz on VMware vSphere?

[Stefan Lambrev]

Hi,

Is there any guide on how to use the vmdk file provided on release on
vSphere?
The first thing that I noticed is an issue reported a few months ago -
https://forums.freebsd.org/threads/installing-on-esxi-using-official-vmdk-files.72945/

Changing the type (Virtual Device Node) of the disk from SCSI to IDE solves
the initial issue, but then growfs fails (also the vSphere complains about
the disk image and resizing fails. I workaround this by creating a
FBSD(12.1amd64) VM on Workstation Player (free version) and then replacing
the disk with the image. Resizing and growfs (on first boot) worked as
expected. Then I used the created vmdk file and uploaded it to be used for
my VM.
It's not very "clean" process, I need to download additional software and I
wonder if someone has a better approach or those files are strictly only
for VM Workstation? Also it's not very good for automatization...
___
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: ng_ipacct VIMAGE option on 12.1-RELEASE

[Pavel Timofeev]

вт, 21 янв. 2020 г. в 15:29, Eugene Kazarinov :
>
> Hi.
> Please change in pkg base default option on FreeBSD-12.1 to
> VIMAGE enabled
> because each time I do `pkg upgrade` it tries to reinstall ng_ipacct with
> VIMAGE DISabled.
> 
> Installed packages to be REINSTALLED:
> ng_ipacct-20180401 (options changed)
> 
>
> After that I must do
> pkg deinstall ng_ipacct-20180401
> cd /usr/ports/net-mgmt/ng_ipacct
> make install clean
>
> And I cant dont reinstall ng_ipacct than pkg upgrades all other packages.
>
> Thank you.
> ___
> 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"

Hi
You could `pkg lock ng_ipacct` as a workaround
___
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"

ng_ipacct VIMAGE option on 12.1-RELEASE

[Eugene Kazarinov]

Hi.
Please change in pkg base default option on FreeBSD-12.1 to
VIMAGE enabled
because each time I do `pkg upgrade` it tries to reinstall ng_ipacct with
VIMAGE DISabled.

Installed packages to be REINSTALLED:
ng_ipacct-20180401 (options changed)


After that I must do
pkg deinstall ng_ipacct-20180401
cd /usr/ports/net-mgmt/ng_ipacct
make install clean

And I cant dont reinstall ng_ipacct than pkg upgrades all other packages.

Thank you.
___
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: Making a release of stable/12 with multiple kernels

[Trond Endrestøl]

On Sat, 11 Jan 2020 12:51+0100, Trond Endrestøl wrote:

> Currently, I'm running:
> 
> /usr/bin/make -C /usr/src -D NO_CLEAN -j 8 buildworld buildkernel
> /usr/bin/make -C /usr/src/release KERNEL="PE1950 DL360G5 GENERIC PER200 
> PER320 XENGUEST ZFS" MAKE_CONF=/etc/make.conf NODOC=1 NOPORTS=1 NOSRC=1 
> SRC_CONF=/etc/src.conf release

It turns out specifying KERNEL, MAKE_CONF, and SRC_CONF belongs to 
release.sh. My bad.

I was missing was -D NO_INSTALLEXTRAKERNELS, just what we also need to 
specify when running make packages.

I.e.:

/usr/bin/make -C /usr/src/release -D NO_INSTALLEXTRAKERNELS NODOC=1 NOPORTS=1 
NOSRC=1 release

Maybe GENERIC should be at the head of KERNCONF when making a release. 
Some .CURDIR magic in /etc/make.conf might help with that.

I'm sorry for the noise.

-- 
Trond.
___
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"

Making a release of stable/12 with multiple kernels

[Trond Endrestøl]

Hi,

I'm trying to make a release of stable/12 and I was hoping to include 
all my custom kernels in the generated disc1.iso and memstick.img.

Currently, I'm running:

/usr/bin/make -C /usr/src -D NO_CLEAN -j 8 buildworld buildkernel
/usr/bin/make -C /usr/src/release KERNEL="PE1950 DL360G5 GENERIC PER200 PER320 
XENGUEST ZFS" MAKE_CONF=/etc/make.conf NODOC=1 NOPORTS=1 NOSRC=1 
SRC_CONF=/etc/src.conf release

The latter command only picks up the first kernel. All kernels are 
present and accounted for.

The list is based on KERNCONF from /etc/make.conf. PE1950 is the 
kernel for my builder and thus listed first.

Should I be using release.sh instead? I prefer using the existing 
source tree, and skip the doc and ports trees.

-- 
Trond.
___
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: Cisco 12G SAS RAID support (FreeBSD 12.1-RELEASE) ?

[Chris Ross]

On Sat, Nov 09, 2019 at 04:51:38PM -0500, Chris Ross wrote:
> > > Can you provide some guidance of what I need to do to get the mrsas
> > > driver to identify it when booting the install ISO?
> > 
> > See the "PRIORITY" section of
> > 
> > https://www.freebsd.org/cgi/man.cgi?query=mrsas=4
> > 
> > You can also set that tunable via the loader
> 
> Hmm.  Okay.  I know I was messing with that parameter on one of these
> machines, I though I'd tried it on this one.  But, maybe that was the
> older box with the HBA in it.

Alright, my bad.  Apologies to all.  So, it turns out that this controller
is not recognized in 12.0, but is recognized by later stable-12 builds.
I have another problem that prevented 12.1 from booting at all, and I tried
investigating both at the same time.  This caused me to confuse things.
My error.

Thanks to all, and this seems to be working in stable-12 in the neighborhood
of Oct 2019, perhaps earlier.

 - Chris
___
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: Cisco 12G SAS RAID support (FreeBSD 12.1-RELEASE) ?

[Chris Ross]

On Sat, Nov 09, 2019 at 04:48:10PM +, Gary Palmer wrote:
> > Hi Doug!  Thanks.  Okay, I infer from that that the mpr driver is for
> > HBAs that aren't raid?  Grepping through the sources for 3516 found me
> > only mpr.  Looking more carefully, at mrsas while knowing specifically
> > what I'm looking for, I find the PCI device ID (0x0014) as "AVAGO Ventura
> > SAS Controller".  And, that code (mrsas) is about the same in stable-12 as
> > is it in -current.
> > 
> > Can you provide some guidance of what I need to do to get the mrsas
> > driver to identify it when booting the install ISO?
> 
> See the "PRIORITY" section of
> 
> https://www.freebsd.org/cgi/man.cgi?query=mrsas=4
> 
> You can also set that tunable via the loader

Hmm.  Okay.  I know I was messing with that parameter on one of these machines,
I though I'd tried it on this one.  But, maybe that was the older box with
the HBA in it.

While I try that, I have a question.  I understood that tunable to be a way
to get the mfi(4) driver to allow the mrsas(4) driver to be used for
devices they both would recognize.  But, in this case, it's clear that the
mfi(4) driver has now knowledge of this device.  Is that tunable being
set necessary to have the mrsas(4) driver even find the devices it knows
how to support that mfi(4) doesn't?   If so, that's a very unfortunate 
situation.  Because there will be a significant set of controllers, like
the one I have in this system, that totally fail to present themselves
when installing from the install media.  Maybe this is a political issue,
and I should stop thinking about it, but.  Let me know if I'm understanding
the technical side, that there are cards mfi(4) has no support for, but
this tunable prevents mrsas(4) from attaching them?

   - Chris
___
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: Cisco 12G SAS RAID support (FreeBSD 12.1-RELEASE) ?

[Gary Palmer]

On Sat, Nov 09, 2019 at 11:38:54AM -0500, Chris Ross wrote:
> On Fri, Nov 08, 2019 at 02:28:17PM -0800, Doug Ambrisko wrote:
> > On Tue, Nov 05, 2019 at 09:44:36PM +0100, Miroslav Lachman wrote:
> > | Chris Ross wrote on 11/05/2019 21:19:
> > | > On Tue, Nov 05, 2019 at 08:20:15PM +0100, Miroslav Lachman wrote:
> > | >> Chris Ross wrote on 11/05/2019 19:34:
> > | >>> Hello.  I have a Cisco UCS C220-M5 with a RAID controller.  It calls 
> > itself
> > | >>> "Cisco 12G Modular Raid Controller with 2GB cache", PPID UCSC-RAID-M5.
> > | >>> Looking at the CIMC, it shows the PCI vendor/device ids 1000:0014, 
> > which
> > | >>> looks to be an LSI MegaRAID Tri-Mode SAS3516.  It looks like this 
> > should
> > | >>> be supported by the mpr(4) driver, but it doesn't seem to recognize it
> > | >>> at boot time.
> > | 
> > | mpr_load="YES" goes to /etc/loader.conf
> > | 
> > | If you need to load mpr manually in boot prompt I am not sure if it 
> > | should be:
> > | load mpr
> > | or
> > | load mpr.ko
> > | of full path
> > | load /boot/kernel/mpr.ko
> > 
> > This should be a mrsas card and not an HBA!  mrsas supports all current
> > UCS RAID cards ... and the next unreleased UCS system :-)  You might need
> > the one in -current for that.  I'm not sure what is in 12.1.
> 
> Hi Doug!  Thanks.  Okay, I infer from that that the mpr driver is for
> HBAs that aren't raid?  Grepping through the sources for 3516 found me
> only mpr.  Looking more carefully, at mrsas while knowing specifically
> what I'm looking for, I find the PCI device ID (0x0014) as "AVAGO Ventura
> SAS Controller".  And, that code (mrsas) is about the same in stable-12 as
> is it in -current.
> 
> Can you provide some guidance of what I need to do to get the mrsas
> driver to identify it when booting the install ISO?

See the "PRIORITY" section of

https://www.freebsd.org/cgi/man.cgi?query=mrsas=4

You can also set that tunable via the loader

Regards,

Gary
___
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: Cisco 12G SAS RAID support (FreeBSD 12.1-RELEASE) ?

[Chris Ross]

On Fri, Nov 08, 2019 at 02:28:17PM -0800, Doug Ambrisko wrote:
> On Tue, Nov 05, 2019 at 09:44:36PM +0100, Miroslav Lachman wrote:
> | Chris Ross wrote on 11/05/2019 21:19:
> | > On Tue, Nov 05, 2019 at 08:20:15PM +0100, Miroslav Lachman wrote:
> | >> Chris Ross wrote on 11/05/2019 19:34:
> | >>> Hello.  I have a Cisco UCS C220-M5 with a RAID controller.  It calls 
> itself
> | >>> "Cisco 12G Modular Raid Controller with 2GB cache", PPID UCSC-RAID-M5.
> | >>> Looking at the CIMC, it shows the PCI vendor/device ids 1000:0014, which
> | >>> looks to be an LSI MegaRAID Tri-Mode SAS3516.  It looks like this should
> | >>> be supported by the mpr(4) driver, but it doesn't seem to recognize it
> | >>> at boot time.
> | 
> | mpr_load="YES" goes to /etc/loader.conf
> | 
> | If you need to load mpr manually in boot prompt I am not sure if it 
> | should be:
> | load mpr
> | or
> | load mpr.ko
> | of full path
> | load /boot/kernel/mpr.ko
> 
> This should be a mrsas card and not an HBA!  mrsas supports all current
> UCS RAID cards ... and the next unreleased UCS system :-)  You might need
> the one in -current for that.  I'm not sure what is in 12.1.

Hi Doug!  Thanks.  Okay, I infer from that that the mpr driver is for
HBAs that aren't raid?  Grepping through the sources for 3516 found me
only mpr.  Looking more carefully, at mrsas while knowing specifically
what I'm looking for, I find the PCI device ID (0x0014) as "AVAGO Ventura
SAS Controller".  And, that code (mrsas) is about the same in stable-12 as
is it in -current.

Can you provide some guidance of what I need to do to get the mrsas
driver to identify it when booting the install ISO?

  - Chris

___
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: Cisco 12G SAS RAID support (FreeBSD 12.1-RELEASE) ?

[Doug Ambrisko]

On Tue, Nov 05, 2019 at 09:44:36PM +0100, Miroslav Lachman wrote:
| Chris Ross wrote on 11/05/2019 21:19:
| > On Tue, Nov 05, 2019 at 08:20:15PM +0100, Miroslav Lachman wrote:
| >> Chris Ross wrote on 11/05/2019 19:34:
| >>> Hello.  I have a Cisco UCS C220-M5 with a RAID controller.  It calls 
itself
| >>> "Cisco 12G Modular Raid Controller with 2GB cache", PPID UCSC-RAID-M5.
| >>> Looking at the CIMC, it shows the PCI vendor/device ids 1000:0014, which
| >>> looks to be an LSI MegaRAID Tri-Mode SAS3516.  It looks like this should
| >>> be supported by the mpr(4) driver, but it doesn't seem to recognize it
| >>> at boot time.
| >>
| >> Do you have mpr_load="YES" in loader.conf?
| >> Or for ISO booting you can manually load kernel modules at boot prompt.
| > 
| > I dropped to boot prompt in ISO boot, and entered 'mpr_load="YES"'.
| > 
| > I tried "load", but wasn't able to devine how to load the mpr module with
| > that.  Is that needed, or should 'mpr_load="YES"' have accomplished the
| > desired result?
| 
| mpr_load="YES" goes to /etc/loader.conf
| 
| If you need to load mpr manually in boot prompt I am not sure if it 
| should be:
| load mpr
| or
| load mpr.ko
| of full path
| load /boot/kernel/mpr.ko

This should be a mrsas card and not an HBA!  mrsas supports all current
UCS RAID cards ... and the next unreleased UCS system :-)  You might need
the one in -current for that.  I'm not sure what is in 12.1.

Doug 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"

Re: 12.1-RELEASE schedule update

[Niclas Zeising]

On 2019-11-02 19:31, Glen Barber wrote:

On Sat, Nov 02, 2019 at 12:14:05PM -0600, Warner Losh wrote:

On Sat, Nov 2, 2019 at 10:20 AM Glen Barber  wrote:


On Sat, Nov 02, 2019 at 02:12:50PM +, Sergey A. Osokin wrote:

On Fri, Nov 01, 2019 at 02:52:50PM +, Glen Barber wrote:

On Fri, Nov 01, 2019 at 01:44:18PM +, Sergey A. Osokin wrote:

At the moment we have graphics/drm-fbsd12.0-kmod port for 12.0.
I hope in most cases it's enough for RELENG_12 branch, however
just to avoid a potential confusion I see the following options
we can do:

- create a new port for 12.1 only
- rename the existing port to drm-fbsd12-kmod
- rename the existing port to drm-fbsd12.1-kmod (in case of 12.0 EoL)


What about using the meta-port and keying off of OSVERSION?

(Personally

I have no real preference either way, nor with any of the solutions you
propose above.)


Actually we have one, graphics/drm-kmod, and it depends on the following

one:


.elif ${OSVERSION} >= 1200058 && ${OSVERSION} < 130
RUN_DEPENDS=${KMODDIR}/drm.ko:graphics/drm-fbsd12.0-kmod
...

So, in case we don't expect an API/ABI changes in 12.x branch we can
just rename it to drm-fbsd12-kmod, or create a specific version of
the port for 12.1 - drm-fbsd12.1-kmod and update the meta-port as well.



We should never expect this type of ABI/KBI breakage along a stable
branch.  (That is our definition of "stable", technically, but sometimes
there are unexpected breakages that occasionally go undetected.)



The KPIs that drm depends on are quite specific and weird and aren't part
of the set we guarantee (and we can't do what drm needs to do with only the
'safe' ones). It's not much different than virtual box which also has this
issue frequently because it too falls into that category.



Agreed.  (FWIW, I specifically made sure the virtualbox-ose-additions
did not cause system crashes for 12.1.)


Also, since this is repeatable thing for every upcoming release

we can add this point to the check list and release scheduling.


Yes, good idea.  Just let us know how you want to proceed, and we can
add a note to the documentation.


I mean I believe we should that (create a new port, update the meta-port,
etc.) in advance, in the beginning of the first phase of release cycle.



This seems like a reasonable approach.



How do we get packages from the new port into the release so that users
don't install the 12.0 port by mistake?



It just needs to be merged to the 2019Q4 ports branch.  For the package
available on the dvd, it is unfortunately too late, but only the
graphics/drm-legacy-kmod and graphics/drm-stable-kmod packages are on
the dvd by default anyway.  In other words, the meta-port is not
included, but once a commit is merged to the 2019Q4 branch and the
upstream binary packages are rebuilt, they will be available by default.


Please note that just creating a separate package for FreeBSD 12.1 (in 
this case) does not solve the issue.  drm-fbsd12.0-kmod builds and works 
fine on FreeBSD 12.1, the issue is that the version built on 12.0 does 
not work on 12.1.
Since packages for 12.1 are built on 12.0, just having a separate 
package would not work in any case.

Regards
--
Niclas Zeising
FreeBSD Graphics Team
___
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: High Send-Q values in netstat after upgrading to 12.1-RELEASE: system is unusable

[Mike Karels]

> On Tuesday, November 05 at 22:44:10 CET, Jose G. Juanino wrote:
> > Hi all,
> > 
> > today I have upgraded to 12.1-RELEASE from 12.0-RELEASE-p10 via
> > freebsd-update. The host is a VMware guest with vmx net interface. The
> > system runs with 12.0-RELEASE perfectly, with no issue, reliably for months.
> > 
> > I have boot environments enabled (thanks god) and therefore I am able to
> > switch between both 12.0 and 12.1 versions.
> > 
> > Just after boot the new 12.1 release, I noticed that my apache did not
> > serve pages with the previous speed, but rather the opposite: any web
> > operation from clients hangs.
> > 
> > After a single inspection in the FreeBSD 12.1 server, I see that Send-Q
> > in netstat is the root cause of the issue. While in 12.0 Send-Q is
> > almost always zero or close to zero in every socket, in 12.1 I get the
> > following (snipped output):
> >
> > [  ]
> >

> Hi again, after doing a further research, I have noticed that in 12.0
> version dev.vmx.0.txq0.hstats.tso_packets is always increasing
> (especially when doing large transfers), but in 12.1 is statically equal
> to zero, never increases.

> As workaround, I have disabled TCP segment offloading by setting the
> net.inet.tcp.tso=0 sysctl in 12.1 version and the host again performs
> almost as well as before in 12.0.

Have you tried disabling jumbo rather than TSO?  If jumbo is enabled
on this system, but not on the client (or next hop), all the segments
sent from the server that are over 1500 bytes will be lost, and data
will pile up in the send queue waiting for acknowledgement.

> I hope this helps others suffering the same issue.

> Regards


> -- 
> Jose G. Juanino

Mike
___
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: High Send-Q values in netstat after upgrading to 12.1-RELEASE: system is unusable

[Jose G. Juanino]

On Tuesday, November 05 at 22:44:10 CET, Jose G. Juanino wrote:
> Hi all,
> 
> today I have upgraded to 12.1-RELEASE from 12.0-RELEASE-p10 via
> freebsd-update. The host is a VMware guest with vmx net interface. The
> system runs with 12.0-RELEASE perfectly, with no issue, reliably for months.
> 
> I have boot environments enabled (thanks god) and therefore I am able to
> switch between both 12.0 and 12.1 versions.
> 
> Just after boot the new 12.1 release, I noticed that my apache did not
> serve pages with the previous speed, but rather the opposite: any web
> operation from clients hangs.
> 
> After a single inspection in the FreeBSD 12.1 server, I see that Send-Q
> in netstat is the root cause of the issue. While in 12.0 Send-Q is
> almost always zero or close to zero in every socket, in 12.1 I get the
> following (snipped output):
>
> [  ]
>

Hi again, after doing a further research, I have noticed that in 12.0
version dev.vmx.0.txq0.hstats.tso_packets is always increasing
(especially when doing large transfers), but in 12.1 is statically equal
to zero, never increases.

As workaround, I have disabled TCP segment offloading by setting the
net.inet.tcp.tso=0 sysctl in 12.1 version and the host again performs
almost as well as before in 12.0.

I hope this helps others suffering the same issue.

Regards


-- 
Jose G. Juanino
___
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: Cisco 12G SAS RAID support (FreeBSD 12.1-RELEASE) ?

[Chris Ross]

On Wed, Nov 06, 2019 at 08:44:35AM +1100, Dewayne Geraghty wrote:
> Chris,
> After you've booted the kernel, the correct way to load a module that isn't
> already in the kernel, is to:
> kldload mpr
> To check if mpr is loaded, try
> kldstat -v|grep mpr

Thanks for this.  I was able to boot and verify that pci/mpr is already
loaded, and trying "kldload mpr" reports that it's already loaded from the
kernel.  So, device just not recognized.

> However, if you've already placed
> mpr_load="YES" in your /etc/loader.conf and rebooted your device, then you
> probably need to move into a diagnostic phase.

Yeah.  I think I see what PCI id is missing in the driver, after digging
around in the sources.  I was just hoping it was a process/human error.
I'll get another machine running a build, and see if I can stub it in.

Thanks all.

 - Chris

___
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"