www/chromium will not build on a host w/ 8 CPU and 16G mem

[Matthias Apitz]

I have built ~2200 ports successful on my build server, which is a
Dell R210 with 8x 3.30GHz CPU and 15.8 GB memory:

Aug 11 19:03:21 jet kernel: CPU: Intel(R) Xeon(R) CPU E3-1230 V2 @ 3.30GHz 
(3292.74-MHz K8-class CPU)
Aug 11 19:03:21 jet kernel: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
Aug 11 19:03:21 jet kernel: avail memory = 16582250496 (15814 MB)

I have set swap to 4GB + 10GB + 10GB:

# swapctl -lh
Device:Bytes  Used:
/dev/da0p3  4.0G   1.5G
/dev/md9 10G   1.5G
/dev/md1010G   1.5G

and poudriere does use ZFS.

Building the last outstanding port www/chromium in single job mode
fails reproducible with a kernel message:

Aug 16 06:14:04 jet kernel: pid 48725 (ninja), jid 3, uid 65534, was killed:
a thread waited too long to allocate a page

What could I do in the port's  options or kernel values?

matthias

-- 
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

Re: Defaulting serial communication to 115200 bps for FreeBSD 14

[Cy Schubert]

Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  https://FreeBSD.org
NTP:   Web:  https://nwtime.org

e^(i*pi)+1=0

   message dated "Tue, 15 Aug 2023 17:18:37 -0400."
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii

In message 
, Ed Maste writes:
> FreeBSD currently uses 9600 bps as the default for serial
> communication -- in the boot loader, kernel serial console, /etc/ttys,
> and so on. This was consistent with most equipment in the 90s, when
> these defaults were established. Today 115200 bps seems to be much
> more common, and I'm proposing that we make it the default for FreeBSD
> 14.0.
>
> I have a review open: https://reviews.freebsd.org/D36295. There are a
> few minor nits in the review to be addressed still but assuming
> there's general agreement I'll iterate on those and commit this in a
> few logical chunks.
>

There should probably be an UPDATING entry for those who use boot0 to 
revert back to 9600 in that case.

Re: Can't assign address to igc

[Chuck Tuffli]

Bah, actually adding freebsd-net this time

On Tue, Aug 15, 2023 at 7:44 PM Chuck Tuffli  wrote:
>
> [Adding freebsd-net@]
>
> On Tue, Aug 1, 2023 at 10:46 AM Chuck Tuffli  wrote:
> >
> > Running a recent-ish version (n264266-8f8da1bcc799) on an Intel NUC
> > (RNUC11PABi5), assigning an IPv4 address to igc0 doesn't work. There
> > is no error message, and this has been working in the past. Looking
> > through dmesg only shows:
> >
> > igc0: link state changed to UP
> > igc0: link state changed to DOWN
> > igc0: link state changed to UP
> >
> > The address is set in rc.conf:
> > ifconfig_igc0="inet 192.168.5.10 netmask 255.255.255.0"
> >
> > And manually setting it via
> > # ifconfig igc0 inet 192.168.5.10/24 up
> > does not work either. Any suggestions?
>
> I spent a little time debugging this but still need some help
> understanding what might be wrong.
>
> Instrumenting dump_sa() in the AF_INET case, the .sin_addr contains
> the value of the IP address I'm adding (printf shows 0x0a05a8c0 or big
> endian 192 168 6 10). Switching the log level in
> sys/netlink/route/iface.c to LOG_DEBUG3 shows messages:
> [nl_iface] dump_iface_addr: dumping ifa 0xf8000db0cd80 type
> inet(2) for interface igc0
> Does this mean the address information was written to the net link
> buffer? If so, what might make ifconfig not display that address?
>
> One other tidbit is, eventually ifconfig reports the address and
> things like sshd start working. Typically this takes < 100 iterations
> to do this.

Re: Can't assign address to igc

[Chuck Tuffli]

[Adding freebsd-net@]

On Tue, Aug 1, 2023 at 10:46 AM Chuck Tuffli  wrote:
>
> Running a recent-ish version (n264266-8f8da1bcc799) on an Intel NUC
> (RNUC11PABi5), assigning an IPv4 address to igc0 doesn't work. There
> is no error message, and this has been working in the past. Looking
> through dmesg only shows:
>
> igc0: link state changed to UP
> igc0: link state changed to DOWN
> igc0: link state changed to UP
>
> The address is set in rc.conf:
> ifconfig_igc0="inet 192.168.5.10 netmask 255.255.255.0"
>
> And manually setting it via
> # ifconfig igc0 inet 192.168.5.10/24 up
> does not work either. Any suggestions?

I spent a little time debugging this but still need some help
understanding what might be wrong.

Instrumenting dump_sa() in the AF_INET case, the .sin_addr contains
the value of the IP address I'm adding (printf shows 0x0a05a8c0 or big
endian 192 168 6 10). Switching the log level in
sys/netlink/route/iface.c to LOG_DEBUG3 shows messages:
[nl_iface] dump_iface_addr: dumping ifa 0xf8000db0cd80 type
inet(2) for interface igc0
Does this mean the address information was written to the net link
buffer? If so, what might make ifconfig not display that address?

One other tidbit is, eventually ifconfig reports the address and
things like sshd start working. Typically this takes < 100 iterations
to do this.

Re: Speed improvements in ZFS

[Mateusz Guzik]

On 8/15/23, Alexander Leidinger  wrote:
> Am 2023-08-15 14:41, schrieb Mateusz Guzik:
>
>> With this in mind can you provide: sysctl kern.maxvnodes
>> vfs.wantfreevnodes vfs.freevnodes vfs.vnodes_created vfs.numvnodes
>> vfs.recycles_free vfs.recycles
>
> After a reboot:
> kern.maxvnodes: 10485760
> vfs.wantfreevnodes: 2621440
> vfs.freevnodes: 24696
> vfs.vnodes_created: 1658162
> vfs.numvnodes: 173937
> vfs.recycles_free: 0
> vfs.recycles: 0
>
>> Meanwhile if there is tons of recycles, you can damage control by
>> bumping kern.maxvnodes.
>
> Looks like there are not much free directly after the reboot. I will
> check the values tomorrow after the periodic run again and maybe
> increase by 10 or 100 so see if it makes a difference.
>
>> If this is not the problem you can use dtrace to figure it out.
>
> dtrace-count on vnlru_read_freevnodes() and vnlru_free_locked()? Or
> something else?
>

I mean checking where find is spending time instead of speculating.

There is no productized way to do it so to speak, but the following
crapper should be good enough:
#pragma D option dynvarsize=32m

profile:::profile-997
/execname == "find"/
{
@oncpu[stack(), "oncpu"] = count();
}

/*
 * The p_flag & 0x4 test filters out kernel threads.
 */

sched:::off-cpu
/execname == "find"/
{
self->ts = timestamp;
}

sched:::on-cpu
/self->ts/
{
@offcpu[stack(30), "offcpu"] = sum(timestamp - self->ts);
self->ts = 0;
}

dtrace:::END
{
normalize(@offcpu, 100);
printa("%k\n%s\n%@d\n\n", @offcpu);
printa("%k\n%s\n%@d\n\n", @oncpu);
}

just leave it running as: dtrace -s script.d -o output

kill it after periodic finishes. it blindly assumes there will be no
other processes named "find" messing around.


> Bye,
> Alexander.
>
> --
> http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
> http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF
>


-- 
Mateusz Guzik 

Defaulting serial communication to 115200 bps for FreeBSD 14

[Ed Maste]

FreeBSD currently uses 9600 bps as the default for serial
communication -- in the boot loader, kernel serial console, /etc/ttys,
and so on. This was consistent with most equipment in the 90s, when
these defaults were established. Today 115200 bps seems to be much
more common, and I'm proposing that we make it the default for FreeBSD
14.0.

I have a review open: https://reviews.freebsd.org/D36295. There are a
few minor nits in the review to be addressed still but assuming
there's general agreement I'll iterate on those and commit this in a
few logical chunks.

Re: Speed improvements in ZFS

[joe mcguckin]

When I watch the activity leds of the disks on one of our ZFS servers, I notice 
there will be a burst of activity for 3 or 4 seconds, then no activity for a 
couple of seconds, then it repeats.
Is that normal?

Thanks,

joe


Joe McGuckin
ViaNet Communications

j...@via.net
650-207-0372 cell
650-213-1302 office
650-969-2124 fax



> On Aug 15, 2023, at 12:33 PM, Alexander Leidinger  
> wrote:
> 
> Am 2023-08-15 14:41, schrieb Mateusz Guzik:
> 
>> With this in mind can you provide: sysctl kern.maxvnodes
>> vfs.wantfreevnodes vfs.freevnodes vfs.vnodes_created vfs.numvnodes
>> vfs.recycles_free vfs.recycles
> 
> After a reboot:
> kern.maxvnodes: 10485760
> vfs.wantfreevnodes: 2621440
> vfs.freevnodes: 24696
> vfs.vnodes_created: 1658162
> vfs.numvnodes: 173937
> vfs.recycles_free: 0
> vfs.recycles: 0
> 
>> Meanwhile if there is tons of recycles, you can damage control by
>> bumping kern.maxvnodes.
> 
> Looks like there are not much free directly after the reboot. I will check 
> the values tomorrow after the periodic run again and maybe increase by 10 or 
> 100 so see if it makes a difference.
> 
>> If this is not the problem you can use dtrace to figure it out.
> 
> dtrace-count on vnlru_read_freevnodes() and vnlru_free_locked()? Or something 
> else?
> 
> Bye,
> Alexander.
> 
> -- 
> http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
> http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF

Re: Speed improvements in ZFS

[Alexander Leidinger]

Am 2023-08-15 14:41, schrieb Mateusz Guzik:


With this in mind can you provide: sysctl kern.maxvnodes
vfs.wantfreevnodes vfs.freevnodes vfs.vnodes_created vfs.numvnodes
vfs.recycles_free vfs.recycles


After a reboot:
kern.maxvnodes: 10485760
vfs.wantfreevnodes: 2621440
vfs.freevnodes: 24696
vfs.vnodes_created: 1658162
vfs.numvnodes: 173937
vfs.recycles_free: 0
vfs.recycles: 0


Meanwhile if there is tons of recycles, you can damage control by
bumping kern.maxvnodes.


Looks like there are not much free directly after the reboot. I will 
check the values tomorrow after the periodic run again and maybe 
increase by 10 or 100 so see if it makes a difference.



If this is not the problem you can use dtrace to figure it out.


dtrace-count on vnlru_read_freevnodes() and vnlru_free_locked()? Or 
something else?


Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF

Re: Strange network issues with -current

[Alexander Leidinger]

Am 2023-08-15 14:24, schrieb Alexander Leidinger:

Am 2023-08-15 13:48, schrieb Alexander Leidinger:

since a while I have some strange network issues in some parts of a 
particular system.


I just stumbled upon the mail which discusses issues with commit 
e3ba0d6adde3, and when I look into this I see changes related to the 
use of SO_REUSEPORT flags, and all my nginx systems use the reuseport 
directive in their config. I'm compiling right now with his change 
reverted. Once tested I will report back.


Unfortunately it wasn't that.

Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF

Re: ZFS deadlock in 14

[Dag-Erling Smørgrav]

The attached script successfully deadlocks 9228ac3a69c4.

DES
-- 
Dag-Erling Smørgrav - d...@freebsd.org

#!/bin/sh

: ${n:=$(nproc)}
: ${pool:=zroot}
basefs="${pool}/zfsdl"

set -eu

zfs destroy -r "${basefs}" >/dev/null 2>&1 || true
zfs create -o com.sun:auto-snapshot=false "${basefs}"
basedir="$(zfs get -H -o value mountpoint "${basefs}")"

echo "preparing tarball..." >&2
tarball="${basedir}/zfsdl.tar"
mkdir "${basedir}/src"
(cd /usr/src ; find * -type d) | (cd "${basedir}/src" ; xargs mkdir -p)
(cd /usr/src ; find * -type f) | (cd "${basedir}/src" ; xargs touch)
tar cf "${tarball}" -C "${basedir}" src

zfs_deadlock() {
local fs=$1 dir
zfs create "${fs}"
dir="$(zfs get -H -o value mountpoint "${fs}")"
zfs snapshot "${fs}@empty"
while ! [ -f "${basedir}/stop" ] ; do
echo "fill ${fs}..." >&2
tar xf "${tarball}" -C "${dir}"
echo "rollback ${fs}..." >&2
zfs rollback -rR "${fs}@empty"
done
}

for i in $(seq -w "${n}") ; do
zfs_deadlock "${basefs}/${i}" &
sleep 1
done

wait

echo "stop" >&2

zfs destroy -r "${basefs}"

Re: ZFS deadlock in 14

[Dag-Erling Smørgrav]

Mateusz Guzik  writes:
> Going through the list may or may not reveal other threads doing
> something in the area and it very well may be they are deadlocked,
> which then results in other processes hanging on them.
>
> Just like in your case the process reported as hung is a random victim
> and whatever the real culprit is deeper.

We already know the real culprit, see upthread.

DES
-- 
Dag-Erling Smørgrav - d...@freebsd.org

Re: ZFS deadlock in 14

[Mateusz Guzik]

On 8/15/23, Dag-Erling Smørgrav  wrote:
> Mateusz Guzik  writes:
>> Given that the custom reproducer failed I think the most prudent
>> course of action is to reproduce again with poudriere, but this time
>> arrange to have all stacktraces dumped.
>
> Why?  What more information do you need?
>

Going through the list may or may not reveal other threads doing
something in the area and it very well may be they are deadlocked,
which then results in other processes hanging on them.

Just like in your case the process reported as hung is a random victim
and whatever the real culprit is deeper.

-- 
Mateusz Guzik 

Re: ZFS deadlock in 14

[Dag-Erling Smørgrav]

Mateusz Guzik  writes:
> Given that the custom reproducer failed I think the most prudent
> course of action is to reproduce again with poudriere, but this time
> arrange to have all stacktraces dumped.

Why?  What more information do you need?

DES
-- 
Dag-Erling Smørgrav - d...@freebsd.org

Re: ZFS deadlock in 14

[Mateusz Guzik]

On 8/15/23, Dag-Erling Smørgrav  wrote:
> Dag-Erling Smørgrav  writes:
>> I managed to geat a deadlock with 4e8d558c9d1c.  Its predecessor
>> 5ca7f02946 appears to be working.  I'm going to try to come up with a
>> more efficient way to reproduce the deadlock than running poudriere.
>
> I wrote a script that creates multiple filesystems, snapshots them,
> populates them and rolls them back continuously but so far I have not
> succeeded in triggering the deadlock without poudriere.  I guess my
> script doesn't consume enough vnodes.
>
> Also, 9228ac3a69c4 (9 August, last commit before the contrib/googletest
> breakage) still deadlocks.
>

Given that the custom reproducer failed I think the most prudent
course of action is to reproduce again with poudriere, but this time
arrange to have all stacktraces dumped.

this should do it:
sbin/ddb/ddb.conf:script kdb.enter.panic=textdump set; capture on; run
lockinfo; show pcpu; bt; ps; alltrace; capture off; textdump dump;
reset

it is a slightly finicky beast so I would trigger a panic by hand
first to validate it works as expected.

-- 
Mateusz Guzik 

Re: ZFS deadlock in 14

[Dag-Erling Smørgrav]

Dag-Erling Smørgrav  writes:
> I managed to geat a deadlock with 4e8d558c9d1c.  Its predecessor
> 5ca7f02946 appears to be working.  I'm going to try to come up with a
> more efficient way to reproduce the deadlock than running poudriere.

I wrote a script that creates multiple filesystems, snapshots them,
populates them and rolls them back continuously but so far I have not
succeeded in triggering the deadlock without poudriere.  I guess my
script doesn't consume enough vnodes.

Also, 9228ac3a69c4 (9 August, last commit before the contrib/googletest
breakage) still deadlocks.

DES
-- 
Dag-Erling Smørgrav - d...@freebsd.org

Re: www/firefox does not compile in 14-CURRENT w/ poudriere

[Matthias Apitz]

El día martes, agosto 15, 2023 a las 09:39:56p. m. +0900, Tomoaki AOKI escribió:

> On Tue, 15 Aug 2023 08:35:01 +0200
> Matthias Apitz  wrote:
> 
> > 
> > The port www/firefox stops to build in congigure phase with:
> > 
> > DEBUG: Executing: `/usr/bin/clang -std=gnu99 --target=wasm32-wasi 
> > /tmp/conftest._vo3qtm2.c -c`
> > DEBUG: The command returned non-zero exit status 1.
> > DEBUG: Its error output was:
> > DEBUG: | error: unable to create target: 'No available targets are 
> > compatible with triple "wasm32-unknown-wasi"'
> > DEBUG: | 1 error generated.
> > ERROR: Failed compiling a simple C source with the wasm C compiler
> > 
> > Which compiler should be used? I set CC=clang via the make.conf.
> 
> Maybe this hurts.
> www/firefox depends on devel/wasi-libcxx, devel/wasi-libc and
> devel/wasi-compiler-rt13. These are only for llvm/clang13 for now.
> 
> And clang on main is at 16, but if you don't override the default of
> www/firefox, it should depend on devel/llvm13 and use it, if base
> llv/clang is NOT 13.

Yes, I deleted CC=clang... from the poudriere's make.conf and it
picked-up llvm13 and compiled fine. Thanks anyway for having replied.

matthias

-- 
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

Re: www/firefox does not compile in 14-CURRENT w/ poudriere

[Tomoaki AOKI]

On Tue, 15 Aug 2023 21:39:56 +0900
Tomoaki AOKI  wrote:

> On Tue, 15 Aug 2023 08:35:01 +0200
> Matthias Apitz  wrote:
> 
> > 
> > The port www/firefox stops to build in congigure phase with:
> > 
> > DEBUG: Executing: `/usr/bin/clang -std=gnu99 --target=wasm32-wasi 
> > /tmp/conftest._vo3qtm2.c -c`
> > DEBUG: The command returned non-zero exit status 1.
> > DEBUG: Its error output was:
> > DEBUG: | error: unable to create target: 'No available targets are 
> > compatible with triple "wasm32-unknown-wasi"'
> > DEBUG: | 1 error generated.
> > ERROR: Failed compiling a simple C source with the wasm C compiler
> > 
> > Which compiler should be used? I set CC=clang via the make.conf.
> 
> Maybe this hurts.
> www/firefox depends on devel/wasi-libcxx, devel/wasi-libc and
> devel/wasi-compiler-rt13. These are only for llvm/clang13 for now.
> 
> And clang on main is at 16, but if you don't override the default of
> www/firefox, it should depend on devel/llvm13 and use it, if base
> llv/clang is NOT 13.

Forgot to mention.
If you want to force CC=clang for ports other than ww/firefox, maybe
below would help.

.if !${.CURDIR:M/usr/ports/www/firefox*}
CC= clang
.endif


> > Thanks
> > matthias
> > 
> > 
> > -- 
> > Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
> > Public GnuPG key: http://www.unixarea.de/key.pub
> 
> 
> -- 
> Tomoaki AOKI


-- 
Tomoaki AOKI

Re: Speed improvements in ZFS

[Mateusz Guzik]

On 8/15/23, Alexander Leidinger  wrote:
> Hi,
>
> just a report that I noticed a very high speed improvement in ZFS in
> -current. Since a looong time (at least since last year), for a
> jail-host of mine with about >20 jails on it which each runs periodic
> daily, the periodic daily runs of the jails take from about 3 am to 5pm
> or longer. I don't remember when this started, and I thought at that
> time that the problem may be data related. It's the long runs of "find"
> in one of the periodic daily jobs which takes that long, and the number
> of jails together with null-mounted basesystem inside the jail and a
> null-mounted package repository inside each jail the number of files and
> congruent access to the spining rust with first SSD and now NVME based
> cache may have reached some tipping point. I have all the periodic daily
> mails around, so theoretically I may be able to find when this started,
> but as can be seen in another mail to this mailinglist, the system which
> has all the periodic mails has some issues which have higher priority
> for me to track down...
>
> Since I updated to a src from 2023-07-20, this is not the case anymore.
> The data is the same (maybe even a bit more, as I have added 2 more
> jails since then and the periodic daily runs which run more or less in
> parallel, are not taking considerably longer). The speed increase with
> the July-build are in the area of 3-4 hours for 23 parallel periodic
> daily runs. So instead of finishing the periodic runs around 5pm, they
> finish already around 1pm/2pm.
>
> So whatever was done inside ZFS or VFS or nullfs between 2023-06-19 and
> 2023-07-20 has given a huge speed improvement. From my memory I would
> say there is still room for improvement, as I think it may be the case
> that the periodic daily runs ended in the morning instead of the
> afteroon, but my memory may be flaky in this regard...
>
> Great work to whoever was involved.
>

several hours to run periodic is still unusably slow.

have you tried figuring out where is the time spent?

I don't know what caused the change here, but do know of one major
bottleneck which you are almost guaranteed to run into if you inspect
all files everywhere -- namely bumping over a vnode limit.

In vn_alloc_hard you can find:
msleep(_sig, _list_mtx, PVFS, "vlruwk", hz);
if (atomic_load_long() + 1 > desiredvnodes &&
vnlru_read_freevnodes() > 1)
vnlru_free_locked(1);

that is, the allocating thread will sleep up to 1 second if there are
no vnodes up for grabs and then go ahead and allocate one anyway.
Going over the numvnodes is partially rate-limited, but in a manner
which is not very usable.

The entire is mostly borked and in desperate need of a rewrite.

With this in mind can you provide: sysctl kern.maxvnodes
vfs.wantfreevnodes vfs.freevnodes vfs.vnodes_created vfs.numvnodes
vfs.recycles_free vfs.recycles

Meanwhile if there is tons of recycles, you can damage control by
bumping kern.maxvnodes.

If this is not the problem you can use dtrace to figure it out.

-- 
Mateusz Guzik 

Re: www/firefox does not compile in 14-CURRENT w/ poudriere

[Tomoaki AOKI]

On Tue, 15 Aug 2023 08:35:01 +0200
Matthias Apitz  wrote:

> 
> The port www/firefox stops to build in congigure phase with:
> 
> DEBUG: Executing: `/usr/bin/clang -std=gnu99 --target=wasm32-wasi 
> /tmp/conftest._vo3qtm2.c -c`
> DEBUG: The command returned non-zero exit status 1.
> DEBUG: Its error output was:
> DEBUG: | error: unable to create target: 'No available targets are compatible 
> with triple "wasm32-unknown-wasi"'
> DEBUG: | 1 error generated.
> ERROR: Failed compiling a simple C source with the wasm C compiler
> 
> Which compiler should be used? I set CC=clang via the make.conf.

Maybe this hurts.
www/firefox depends on devel/wasi-libcxx, devel/wasi-libc and
devel/wasi-compiler-rt13. These are only for llvm/clang13 for now.

And clang on main is at 16, but if you don't override the default of
www/firefox, it should depend on devel/llvm13 and use it, if base
llv/clang is NOT 13.


> Thanks
>   matthias
> 
> 
> -- 
> Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
> Public GnuPG key: http://www.unixarea.de/key.pub


-- 
Tomoaki AOKI

Re: ps(1) bugs and problems

[Jamie Landeg-Jones]

"Piotr P. Stefaniak"  wrote:

> On 2023-08-11 12:32:02, Jamie Landeg-Jones wrote:
> >How about reverting '-d', and adding "-D" for descending, and "-A" for 
> >ascending?
>
> I don't like that, because it would take three option-letters in total
> to implement the same function in different variants.

Yeah, I can see that.

> The old -d and the new -D'$^' would be the best in that -d would go back
> to what it was and -D would provide the much needed feature in two
> variants (possibly more in the future, if needed) while only taking one
> option-letter. The only problem is that it looks ugly.

I see why you chose "$" and "^", but wouldn't it look more friendly if
you instead used "up" and "down" or "A" and "D" or "forwards" and "backwards",
for example?

> For the record, just -d'$^' is impossible, because it would break
> existing command invocations.

Yeah, I can see that.

Cheers, Jamie

Re: Speed improvements in ZFS

[Graham Perrin]

On 15/08/2023 13:05, Alexander Leidinger wrote:

… periodic runs …


Here, I get a sense that these benefit greatly from L2ARC.

… So whatever was done inside ZFS or VFS or nullfs between 2023-06-19 
and 2023-07-20 has given a huge speed improvement. …


 not within the time 
frame, the most recent commit was 2023-06-16.


 
the two most recent commits might be of interest. Related: 
, 
. 

Re: Strange network issues with -current

[Alexander Leidinger]

Am 2023-08-15 13:48, schrieb Alexander Leidinger:

since a while I have some strange network issues in some parts of a 
particular system.


I just stumbled upon the mail which discusses issues with commit 
e3ba0d6adde3, and when I look into this I see changes related to the use 
of SO_REUSEPORT flags, and all my nginx systems use the reuseport 
directive in their config. I'm compiling right now with his change 
reverted. Once tested I will report back.


Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF

Speed improvements in ZFS

[Alexander Leidinger]

Hi,

just a report that I noticed a very high speed improvement in ZFS in 
-current. Since a looong time (at least since last year), for a 
jail-host of mine with about >20 jails on it which each runs periodic 
daily, the periodic daily runs of the jails take from about 3 am to 5pm 
or longer. I don't remember when this started, and I thought at that 
time that the problem may be data related. It's the long runs of "find" 
in one of the periodic daily jobs which takes that long, and the number 
of jails together with null-mounted basesystem inside the jail and a 
null-mounted package repository inside each jail the number of files and 
congruent access to the spining rust with first SSD and now NVME based 
cache may have reached some tipping point. I have all the periodic daily 
mails around, so theoretically I may be able to find when this started, 
but as can be seen in another mail to this mailinglist, the system which 
has all the periodic mails has some issues which have higher priority 
for me to track down...


Since I updated to a src from 2023-07-20, this is not the case anymore. 
The data is the same (maybe even a bit more, as I have added 2 more 
jails since then and the periodic daily runs which run more or less in 
parallel, are not taking considerably longer). The speed increase with 
the July-build are in the area of 3-4 hours for 23 parallel periodic 
daily runs. So instead of finishing the periodic runs around 5pm, they 
finish already around 1pm/2pm.


So whatever was done inside ZFS or VFS or nullfs between 2023-06-19 and 
2023-07-20 has given a huge speed improvement. From my memory I would 
say there is still room for improvement, as I think it may be the case 
that the periodic daily runs ended in the morning instead of the 
afteroon, but my memory may be flaky in this regard...


Great work to whoever was involved.

Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF

Strange network issues with -current

[Alexander Leidinger]

Hi,

since a while I have some strange network issues in some parts of a 
particular system.


A build with src from 2023-07-26 was still working ok. An update to 
2023-08-07 broke some parts in a strange way. I tried again with src 
from 2023-08-11 didn't fix things.


What I see is... strange and complex.

I have a jail host with about 23 jails. All the jails are sitting on a 
bridge, and have IPv6 and IPV4 addresses. One jail is a DNS server for a 
domain which contains all the DNS entries for all the jails on the 
system (and more). Other jails have mysql (FS socket for mysql 
nullfs-mounted into other jails for connecting to mysql via the FS 
socket instead of the network), dovecot IMAP server, postfix SMTP 
server, a nginx based reverse proxy and 2 different kinds of webmail 
solutions (old php74 based on the way out on favour for a php81 based 
one), a wiki and other things.


With the old working basesystem I can login into the old webmail system 
and read mails. With the newer non-working basesystem I still can login, 
but the auth-credentials are not stored in the backend-session and as 
such no mail is listed at all, as this requires subsequent connections 
from php to dovecot. This webmail system is going via the reverse proxy 
to the webmail-jail which has another nginx configured to connect to the 
php-fpm backend.
With the new webmail system I can login, read mails, and even are 
writing this email from. The first login to it fails. The second 
succeeds. It is not behind the reverse proxy (as it is not fully ready 
yet for access from the outside (DSL with NAT on the DSL-box to the 
reverse proxy)), but a single nginx with php-fpm backend (instead of 2 
nginx + php-fpm as in the old webmail).


The wiki behind the reverse proxy is sometimes working, and sometimes 
not. Sometimes it is providing everything, sometimes parts of the site 
is missing (e.g. pictures / icons). Sometimes there is simply a blank 
page, sometimes it gives an error message from the wiki about an 
unforseen bug...


The error messages in the nginx reverse proxy log for all the strange 
failure cases is "accept4() failed (53: Software caused connection 
abort)". Sometimes I get "upstream timed out". When it times out in the 
reverse proxy instead of getting the accept4-errors, I see the same 
accept4-error message in the nginx inside the wiki or webmail jail 
instead.


I tried to recompile all the components of the wiki and reverse proxy 
and php81 based webmail, to no avail. The issue persists.


Does this ring a bell to someone? Maybe some network or socket or VM 
based changes in this timeframe which smell like they could be related 
and maybe good candidates for a backup-test? Any ideas how to drill down 
with debugging to have a more simple test-case than the complex setup of 
if_bridge, epair, jails, wiki, php, nginx, ...?


Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF

Re: security/openvpn does not compile in 14-CURRENT w/ poudriere

[Matthias Apitz]

El día martes, agosto 15, 2023 a las 08:16:38a. m. +0200, Matthias Apitz 
escribió:

> 
> security/openvpn fails to build with an error message in the log:
> 
> ...
> libc.so.7
> libcrypto.so.11
> libcrypto.so.30
> libdl.so.1
> liblz4.so.1
> liblzo2.so.2
> libnv.so.1
> libpkcs11-helper.so.1
> libssl.so.11
> libthr.so.3
> /usr/ports/security/openvpn FAILED: either of libssl libcrypto libraries 
> linked multiple times
> *** Error code 1
> 
> The full log is at http://www.unixarea.de/openvpn-2.6.5.log
> 
> The job uses via make.conf the SSL from the base:
> 
> ---Begin OPTIONS List---
> ===> The following configuration options are available for openvpn-2.6.5:
>  ASYNC_PUSH=off: Enable async-push support
>  DCO=on: Build with Data Channel Offload (ovpn(4)) support
>  DOCS=on: Build and/or install documentation
>  EASYRSA=on: Install security/easy-rsa RSA helper package
>  EXAMPLES=on: Build and/or install examples
>  LZ4=on: LZ4 compression support
>  LZO=on: LZO compression (incompatible with LibreSSL)
>  PKCS11=on: Use security/pkcs11-helper, needs same SSL lib!
>  SMALL=off: Build a smaller executable with fewer features
>  TEST=on: Build and/or run tests
>  UNITTESTS=off: Enable unit tests
>  X509ALTUSERNAME=off: Enable --x509-username-field
> ===> Use 'make config' to modify these settings
> ---End OPTIONS List---
> 
> --MAKE_ENV--
> OPENSSLBASE=/usr OPENSSLDIR=/etc/ssl OPENSSLINC=/usr/include 
> OPENSSLLIB=/usr/lib ...
> 
> There is a similar, but closed PR: 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254323
> 

I've unset PKCS11 in the port's option:

# cat /usr/local/etc/poudriere.d/140-CURRENT-options/security_openvpn/options
# This file is auto-generated by 'make config'.
# Options for openvpn-2.6.5
_OPTIONS_READ=openvpn-2.6.5
_FILE_COMPLETE_OPTIONS_LIST=ASYNC_PUSH DCO DOCS EASYRSA EXAMPLES LZ4 LZO PKCS11 
SMALL TEST UNITTESTS X509ALTUSERNAME
OPTIONS_FILE_UNSET+=ASYNC_PUSH
OPTIONS_FILE_SET+=DCO
OPTIONS_FILE_SET+=DOCS
OPTIONS_FILE_SET+=EASYRSA
OPTIONS_FILE_SET+=EXAMPLES
OPTIONS_FILE_SET+=LZ4
OPTIONS_FILE_SET+=LZO
OPTIONS_FILE_UNSET+=PKCS11
^^
OPTIONS_FILE_UNSET+=SMALL
OPTIONS_FILE_SET+=TEST
OPTIONS_FILE_UNSET+=UNITTESTS
OPTIONS_FILE_UNSET+=X509ALTUSERNAME

With this it builds fine.

matthias

-- 
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

Re: Potential show-stopper in em driver?

[Greg 'groggy' Lehey]

On Monday, 14 August 2023 at 17:34:12 -0700, Kevin Bowling wrote:
> On Mon, Aug 14, 2023 at 4:45 PM Greg 'groggy' Lehey  wrote:
>> Thanks.  Let me know when you have something and I'll test it.
>
> I went ahead and reverted: 797e480cba8834e584062092c098e60956d28180

Is it that bad?  I had the impression that where it worked, it was an
advantage.  Couldn't you just leave it there disabled, with the option
of enabling it along with a warning that it hasn't been tested on all
hardware?

Greg
--
Sent from my desktop computer.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA.php


signature.asc
Description: PGP signature

Re: security/openvpn does not compile in 14-CURRENT w/ poudriere

[Yasuhiro Kimura]

From: Matthias Apitz 
Subject: security/openvpn does not compile in 14-CURRENT w/ poudriere
Date: Tue, 15 Aug 2023 08:16:38 +0200

> 
> security/openvpn fails to build with an error message in the log:
> 
> ...
> libc.so.7
> libcrypto.so.11
> libcrypto.so.30
> libdl.so.1
> liblz4.so.1
> liblzo2.so.2
> libnv.so.1
> libpkcs11-helper.so.1
> libssl.so.11
> libthr.so.3
> /usr/ports/security/openvpn FAILED: either of libssl libcrypto libraries 
> linked multiple times
> *** Error code 1
> 
> The full log is at http://www.unixarea.de/openvpn-2.6.5.log
> 
> The job uses via make.conf the SSL from the base:
> 
> ---Begin OPTIONS List---
> ===> The following configuration options are available for openvpn-2.6.5:
>  ASYNC_PUSH=off: Enable async-push support
>  DCO=on: Build with Data Channel Offload (ovpn(4)) support
>  DOCS=on: Build and/or install documentation
>  EASYRSA=on: Install security/easy-rsa RSA helper package
>  EXAMPLES=on: Build and/or install examples
>  LZ4=on: LZ4 compression support
>  LZO=on: LZO compression (incompatible with LibreSSL)
>  PKCS11=on: Use security/pkcs11-helper, needs same SSL lib!
>  SMALL=off: Build a smaller executable with fewer features
>  TEST=on: Build and/or run tests
>  UNITTESTS=off: Enable unit tests
>  X509ALTUSERNAME=off: Enable --x509-username-field
> ===> Use 'make config' to modify these settings
> ---End OPTIONS List---
> 
> --MAKE_ENV--
> OPENSSLBASE=/usr OPENSSLDIR=/etc/ssl OPENSSLINC=/usr/include 
> OPENSSLLIB=/usr/lib ...
> 
> There is a similar, but closed PR: 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254323
> 
> What can I do?
> 
>   matthias

I tried build of security/openvpn with following conditions.

* Host: 14.0-ALPHA1 amd64 main-n264690-54cfeb84846 GENERIC
* Poudriere: 3.3.7
* Jail: same as host
* Ports tree: d5418d0957ad (main branch)
* Default options setting including all dependencies

And it finished successfully.

Full build log:
https://people.freebsd.org/~yasu/poudriere/data/logs/bulk/curamd64-default/2023-08-15_15h42m59s/logs/openvpn-2.6.5.log

HTH.

---
Yasuhiro Kimura

www/firefox does not compile in 14-CURRENT w/ poudriere

[Matthias Apitz]

The port www/firefox stops to build in congigure phase with:

DEBUG: Executing: `/usr/bin/clang -std=gnu99 --target=wasm32-wasi 
/tmp/conftest._vo3qtm2.c -c`
DEBUG: The command returned non-zero exit status 1.
DEBUG: Its error output was:
DEBUG: | error: unable to create target: 'No available targets are compatible 
with triple "wasm32-unknown-wasi"'
DEBUG: | 1 error generated.
ERROR: Failed compiling a simple C source with the wasm C compiler

Which compiler should be used? I set CC=clang via the make.conf.

Thanks
matthias


-- 
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

security/openvpn does not compile in 14-CURRENT w/ poudriere

[Matthias Apitz]

security/openvpn fails to build with an error message in the log:

...
libc.so.7
libcrypto.so.11
libcrypto.so.30
libdl.so.1
liblz4.so.1
liblzo2.so.2
libnv.so.1
libpkcs11-helper.so.1
libssl.so.11
libthr.so.3
/usr/ports/security/openvpn FAILED: either of libssl libcrypto libraries linked 
multiple times
*** Error code 1

The full log is at http://www.unixarea.de/openvpn-2.6.5.log

The job uses via make.conf the SSL from the base:

---Begin OPTIONS List---
===> The following configuration options are available for openvpn-2.6.5:
 ASYNC_PUSH=off: Enable async-push support
 DCO=on: Build with Data Channel Offload (ovpn(4)) support
 DOCS=on: Build and/or install documentation
 EASYRSA=on: Install security/easy-rsa RSA helper package
 EXAMPLES=on: Build and/or install examples
 LZ4=on: LZ4 compression support
 LZO=on: LZO compression (incompatible with LibreSSL)
 PKCS11=on: Use security/pkcs11-helper, needs same SSL lib!
 SMALL=off: Build a smaller executable with fewer features
 TEST=on: Build and/or run tests
 UNITTESTS=off: Enable unit tests
 X509ALTUSERNAME=off: Enable --x509-username-field
===> Use 'make config' to modify these settings
---End OPTIONS List---

--MAKE_ENV--
OPENSSLBASE=/usr OPENSSLDIR=/etc/ssl OPENSSLINC=/usr/include 
OPENSSLLIB=/usr/lib ...

There is a similar, but closed PR: 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254323

What can I do?

matthias



-- 
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub