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

Matthias Apitz wrote on Date: Wed, 16 Aug 2023 04:31:38 UTC : > 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) > Au

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

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 C

Re: Defaulting serial communication to 115200 bps for FreeBSD 14

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

Re: Can't assign address to igc

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 addres

Re: Can't assign address to igc

[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

Re: Speed improvements in ZFS

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

Defaulting serial communication to 115200 bps for FreeBSD 14

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

Re: Speed improvements in ZFS

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-2

Re: Speed improvements in ZFS

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.

Re: Strange network issues with -current

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

Re: ZFS deadlock in 14

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="$

Re: ZFS deadlock in 14

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 wh

Re: ZFS deadlock in 14

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? > Goi

Re: ZFS deadlock in 14

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

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 s

Re: ZFS deadlock in 14

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, snapsho

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

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

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

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

Re: Speed improvements in ZFS

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 ja

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

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 erro

Re: ps(1) bugs and problems

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

Re: Speed improvements in ZFS

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. …

Re: Strange network issues with -current

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 f

Speed improvements in ZFS

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 d

Strange network issues with -current

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 an

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

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 > libss

Re: Potential show-stopper in em driver?

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 impre

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

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.