Re: Is anyone using libzfs_core on 15-CURRENT?

[Shawn Webb]

On Wed, Jun 19, 2024 at 06:34:24PM +0100, David Chisnall wrote:
> Hi all,
> 
> I have some code using libzfs_core that works fine on 13, but seems not to on 
> 15-CURRENT.  The lzc_snapshot function is failing with exactly the same nv 
> list argument.  It is failing with errno 2 (ENOENT) from the ZFS ioctl (and 
> not returning an nvlist of errors).
> 
> My understanding is that the zfs command-line tool wraps libzfs_core and so 
> it must be working somehow.  Has anything changed in between 13 and 14 that 
> would be expected to cause incompatibilities?  The fact that we don’t install 
> usable headers for these libraries makes it quite difficult to be sure that I 
> haven’t done anything wrong, but stepping through the libzfs_core bits in a 
> debugger, everything looks correct up to the ioctl call.

I have a little wrapper around libzfs{,_core}:
https://git.hardenedbsd.org/shawn.webb/liblattzfs

It kinda sucks, but fills a need. We imported that into HardenedBSD
base.

We don't link against libzfs_core, but we do reference a header:
https://git.hardenedbsd.org/shawn.webb/liblattzfs/-/blob/main/src/liblattzfs.c?ref_type=heads#L40

liblattzfs mainly serves to get the status of a pool. We use it in
another utility, hbsdmon:
https://git.hardenedbsd.org/hardenedbsd/hbsdmon

hbsdmon is a simple HardenedBSD system monitoring tool. It can monitor
a ZFS pool, sending a Pushover message if the pool is unhealthy:
https://git.hardenedbsd.org/hardenedbsd/hbsdmon/-/blob/master/usr.bin/hbsdmon/zfs.c?ref_type=heads

So to answer your question of whether there are any libzfs_core
consumers: yes, but only the C headers. My use case seems quite
different than yours, so the information presented in this email might
not be applicable.

Thanks,

-- 
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50
https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc


signature.asc
Description: PGP signature

Is anyone using libzfs_core on 15-CURRENT?

[David Chisnall]

Hi all,

I have some code using libzfs_core that works fine on 13, but seems not to on 
15-CURRENT.  The lzc_snapshot function is failing with exactly the same nv list 
argument.  It is failing with errno 2 (ENOENT) from the ZFS ioctl (and not 
returning an nvlist of errors).

My understanding is that the zfs command-line tool wraps libzfs_core and so it 
must be working somehow.  Has anything changed in between 13 and 14 that would 
be expected to cause incompatibilities?  The fact that we don’t install usable 
headers for these libraries makes it quite difficult to be sure that I haven’t 
done anything wrong, but stepping through the libzfs_core bits in a debugger, 
everything looks correct up to the ioctl call.

David

maintainer take for security/globalprotect-openconnect

[Matthias Apitz]

I filed an issue: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279853
to take over maintainer for security/globalprotect-openconnect

Thanks

matthias

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

Re: ncurses /usr vs. /usr/local vs. undefined symbols

[Bjoern A. Zeeb]

On Tue, 18 Jun 2024, Moin Rahman wrote:


On Jun 18, 2024, at 5:41 PM, Bjoern A. Zeeb  
wrote:

Hi,

I have no idea where to start but I know if I uninstall the ncruses port
the problem goes away.

I am trying to build a few packages on main/arm64 (from the last 24h)
and this is like the 5th port I run into this problem now:

ld: error: undefined symbol: newterm

referenced by clamdtop.c
 clamdtop/CMakeFiles/clamdtop.dir/clamdtop.c.o:(main)


ld: error: undefined symbol: start_color

referenced by clamdtop.c
 clamdtop/CMakeFiles/clamdtop.dir/clamdtop.c.o:(main)


ld: error: undefined symbol: nonl

referenced by clamdtop.c
 clamdtop/CMakeFiles/clamdtop.dir/clamdtop.c.o:(main)


ld: error: undefined symbol: noecho

referenced by clamdtop.c
 clamdtop/CMakeFiles/clamdtop.dir/clamdtop.c.o:(main)


.


# ldconfig -r | grep curses
   62:-lncursesw.9 => /lib/libncursesw.so.9
   289:-lncurses.6 => /usr/local/lib/libncurses.so.6


Something tells me something has changed but I don't even know where to
start digging.  I didn't see this the last time I did in March.
Is this a src or a ports problem, ncurses or even linker?

/bz

--
Bjoern A. Zeeb r15:7


Hi,

I did update ncurses sometimes in April or May. Can you confirm whether
if this is happening after that?


Last update git log tells me:

commit 6b02dcbe6709c95d01d3b83056fe2dcddc34f543
Author: Muhammad Moinur Rahman 
AuthorDate: Mon Apr 29 22:08:38 2024 +0200
Commit: Muhammad Moinur Rahman 
CommitDate: Mon Apr 29 23:55:02 2024 +0200

devel/ncurses: Update version 6.4=>6.5

- Remove ftp MASTER_SITES

Changelog: https://invisible-island.net/ncurses/NEWS.html#index-t20240427



My last build was around March 31.  Back then it did not build the ncurses 
package at all.

And I can confirm I still do have:

-r--r--r--  1 root wheel 49 Jun 17 19:09 /usr/lib/libncursesw.so

that Mk/Uses/ncurses.mk checks for.


Maybe a dependency changes and pull in the port now forcefully which makes this 
visible?

And the winner is:

commit 5a77b3ff4c0e9fed2b3dab55023735008cff1e73
Author: Koichiro Iwao 
AuthorDate: Sat May 25 03:15:51 2024 +0900
Commit: Koichiro Iwao 
CommitDate: Fri Jun 14 17:31:54 2024 +0900

sysutils/tmux: Fix crash when text selection using mouse

I re-ported a patch originally ported to 3.2a by Tobias Brick, a
Microsoft employee to 3.3a. The patch depends on ncurses 6.4-20230423 or
later so I bind this port to ncurses:port.

See commit message of the patch for detail [1]

[1] 
https://github.com/microsoft/azurelinux/blob/a1f78f2/SPECS/tmux/manual-patch-to-fix-crash-due-to-change-to-ncurses.patch

PR: 279276
Approved by:maintainer timeout
Obtained from:  https://github.com/microsoft/azurelinux/issues/6598
Obtained from:  https://github.com/microsoft/azurelinux/pull/6766


But also reveals a problem elesewhere in the system... likely ncurses.mk logic?

--
Bjoern A. Zeeb r15:7

Re: ncurses /usr vs. /usr/local vs. undefined symbols

[Moin Rahman]

> On Jun 18, 2024, at 6:13 PM, Moin Rahman  wrote:
> 
> 
> 
>> On Jun 18, 2024, at 5:41 PM, Bjoern A. Zeeb  
>> wrote:
>> 
>> Hi,
>> 
>> I have no idea where to start but I know if I uninstall the ncruses port
>> the problem goes away.
>> 
>> I am trying to build a few packages on main/arm64 (from the last 24h)
>> and this is like the 5th port I run into this problem now:
>> 
>> ld: error: undefined symbol: newterm
> referenced by clamdtop.c
> clamdtop/CMakeFiles/clamdtop.dir/clamdtop.c.o:(main)
>> 
>> ld: error: undefined symbol: start_color
> referenced by clamdtop.c
> clamdtop/CMakeFiles/clamdtop.dir/clamdtop.c.o:(main)
>> 
>> ld: error: undefined symbol: nonl
> referenced by clamdtop.c
> clamdtop/CMakeFiles/clamdtop.dir/clamdtop.c.o:(main)
>> 
>> ld: error: undefined symbol: noecho
> referenced by clamdtop.c
> clamdtop/CMakeFiles/clamdtop.dir/clamdtop.c.o:(main)
>> 
>> .
>> 
>> 
>> # ldconfig -r | grep curses
>>   62:-lncursesw.9 => /lib/libncursesw.so.9
>>   289:-lncurses.6 => /usr/local/lib/libncurses.so.6
>> 
>> 
>> Something tells me something has changed but I don't even know where to
>> start digging.  I didn't see this the last time I did in March.
>> Is this a src or a ports problem, ncurses or even linker?
>> 
>> /bz
>> 
>> --
>> Bjoern A. Zeeb r15:7
> 
> Hi,
> 
> I did update ncurses sometimes in April or May. Can you confirm whether
> if this is happening after that?
> 
> Kind regards,
> Moin

My Goldfish memory just recollected that there is a long outstanding
issue regarding this. And it's mostly for libraries which exist in
both worlds. The linkers and libraries do not play well when the
build system mainly picks up the library from the ports and headers
from src or vice versa. It just goes wonky. Let me know the ports
which are affected and also if this is the case in head or quarterly.
I will have a look if something can be done.

Kind regards,
Moin


signature.asc
Description: Message signed with OpenPGP

Re: ncurses /usr vs. /usr/local vs. undefined symbols

[Moin Rahman]

> On Jun 18, 2024, at 5:41 PM, Bjoern A. Zeeb  
> wrote:
> 
> Hi,
> 
> I have no idea where to start but I know if I uninstall the ncruses port
> the problem goes away.
> 
> I am trying to build a few packages on main/arm64 (from the last 24h)
> and this is like the 5th port I run into this problem now:
> 
> ld: error: undefined symbol: newterm
 referenced by clamdtop.c
  clamdtop/CMakeFiles/clamdtop.dir/clamdtop.c.o:(main)
> 
> ld: error: undefined symbol: start_color
 referenced by clamdtop.c
  clamdtop/CMakeFiles/clamdtop.dir/clamdtop.c.o:(main)
> 
> ld: error: undefined symbol: nonl
 referenced by clamdtop.c
  clamdtop/CMakeFiles/clamdtop.dir/clamdtop.c.o:(main)
> 
> ld: error: undefined symbol: noecho
 referenced by clamdtop.c
  clamdtop/CMakeFiles/clamdtop.dir/clamdtop.c.o:(main)
> 
> .
> 
> 
> # ldconfig -r | grep curses
>62:-lncursesw.9 => /lib/libncursesw.so.9
>289:-lncurses.6 => /usr/local/lib/libncurses.so.6
> 
> 
> Something tells me something has changed but I don't even know where to
> start digging.  I didn't see this the last time I did in March.
> Is this a src or a ports problem, ncurses or even linker?
> 
> /bz
> 
> --
> Bjoern A. Zeeb r15:7

Hi,

I did update ncurses sometimes in April or May. Can you confirm whether
if this is happening after that?

Kind regards,
Moin


signature.asc
Description: Message signed with OpenPGP

ncurses /usr vs. /usr/local vs. undefined symbols

[Bjoern A. Zeeb]

Hi,

I have no idea where to start but I know if I uninstall the ncruses port
the problem goes away.

I am trying to build a few packages on main/arm64 (from the last 24h)
and this is like the 5th port I run into this problem now:

ld: error: undefined symbol: newterm

referenced by clamdtop.c
  clamdtop/CMakeFiles/clamdtop.dir/clamdtop.c.o:(main)


ld: error: undefined symbol: start_color

referenced by clamdtop.c
  clamdtop/CMakeFiles/clamdtop.dir/clamdtop.c.o:(main)


ld: error: undefined symbol: nonl

referenced by clamdtop.c
  clamdtop/CMakeFiles/clamdtop.dir/clamdtop.c.o:(main)


ld: error: undefined symbol: noecho

referenced by clamdtop.c
  clamdtop/CMakeFiles/clamdtop.dir/clamdtop.c.o:(main)





# ldconfig -r | grep curses
62:-lncursesw.9 => /lib/libncursesw.so.9
289:-lncurses.6 => /usr/local/lib/libncurses.so.6


Something tells me something has changed but I don't even know where to
start digging.  I didn't see this the last time I did in March.
Is this a src or a ports problem, ncurses or even linker?

/bz

--
Bjoern A. Zeeb r15:7

Re: Heads-up: ifconfig address without a mask/width to become an error

[Ed Maste]

On Mon, 17 Jun 2024 at 11:16, Michael Gmelin  wrote:
>
> Hi Ed,
>
> In case there is no EN, what is the process to add information about
> issues like this to the release notes? Something like "known issues",
> which those of us who read the release notes can stumble over and check?

Great question - we don't have a consistent process for an
announcement like this that does not come with a patch. It would make
sense to me to issue an Erratum Notice without a patch, although I
don't believe we've done that before. At a minimum we could update the
release notes for 14.0 and 14.1 on the website to make note of this.

Re: Heads-up: ifconfig address without a mask/width to become an error

[Michael Gmelin]

> On 17. Jun 2024, at 20:34, Shawn Webb  wrote:
> 
> On Mon, Jun 17, 2024 at 10:54:29AM -0400, Ed Maste wrote:
>> It is currently possible to specify an IPv4 address without a
>> netmask/width to ifconfig or in rc.conf, e.g.:
>> 
>>ifconfig_igb0="192.168.0.2"
>> 
>> phk recently discovered[1] that ifconfig chose a poor netmask/width
>> when none was specified. This was not an intentional change in
>> defaults but rather a bug that has now been fixed by grembo@, in
>> commit 8a9f0fa42b1c and merged to stable/14 in 048ad7a9ef9f. The fix
>> will be in FreeBSD 14.2. I am unsure if there will be an EN update for
>> 14.0/14.1. The bug does not exist in FreeBSD 13.x.
>> 
>> Specifying an IPv4 address without a mask/width has been deprecated
>> since the deprecation of classful addressing. As of FreeBSD 13.1
>> ifconfig has emitted a warning when no mask/width is specified, and
>> the intent was to make it an error after a sufficient amount of time
>> passed.
>> 
>> I've opened a Phabricator review[2] for ifconfig to change the warning
>> into an error. I included a link to the review in phk's thread, and
>> asked for input on timing for landing the change. As there seems to be
>> consensus to include this change in FreeBSD 15.0 I plan to commit it
>> soon and am sending this note to increase the visibility of the
>> upcoming change.
>> 
>> This will be prominently noted in the 15.0 release notes, and should
>> be mentioned in release notes for upcoming 13.x and 14.x releases.
> 
> Hey Ed,
> 
> I hope I don't sound pathetically verbose here, but I just wanted to
> make sure to remove any sense of ambiguity.
> 
> Would the "netmask " option still work? For example:
> 
> # ifconfig em0 inet 192.168.0.1 netmask 255.255.255.0
> 
> I suspect the answer is "yes".
> 


Yes, this affects only configs without any netmask.

So

192.168.0.1/24 => ok
192.168.0.1 netmask 255.255.255.0 => ok
192.168.0.1 => deprecated now, error then

Best



> Thanks,
> 
> -- 
> Shawn Webb
> Cofounder / Security Engineer
> HardenedBSD
> 
> Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50
> https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc

Re: Heads-up: ifconfig address without a mask/width to become an error

[Shawn Webb]

On Mon, Jun 17, 2024 at 10:54:29AM -0400, Ed Maste wrote:
> It is currently possible to specify an IPv4 address without a
> netmask/width to ifconfig or in rc.conf, e.g.:
> 
> ifconfig_igb0="192.168.0.2"
> 
> phk recently discovered[1] that ifconfig chose a poor netmask/width
> when none was specified. This was not an intentional change in
> defaults but rather a bug that has now been fixed by grembo@, in
> commit 8a9f0fa42b1c and merged to stable/14 in 048ad7a9ef9f. The fix
> will be in FreeBSD 14.2. I am unsure if there will be an EN update for
> 14.0/14.1. The bug does not exist in FreeBSD 13.x.
> 
> Specifying an IPv4 address without a mask/width has been deprecated
> since the deprecation of classful addressing. As of FreeBSD 13.1
> ifconfig has emitted a warning when no mask/width is specified, and
> the intent was to make it an error after a sufficient amount of time
> passed.
> 
> I've opened a Phabricator review[2] for ifconfig to change the warning
> into an error. I included a link to the review in phk's thread, and
> asked for input on timing for landing the change. As there seems to be
> consensus to include this change in FreeBSD 15.0 I plan to commit it
> soon and am sending this note to increase the visibility of the
> upcoming change.
> 
> This will be prominently noted in the 15.0 release notes, and should
> be mentioned in release notes for upcoming 13.x and 14.x releases.

Hey Ed,

I hope I don't sound pathetically verbose here, but I just wanted to
make sure to remove any sense of ambiguity.

Would the "netmask " option still work? For example:

# ifconfig em0 inet 192.168.0.1 netmask 255.255.255.0

I suspect the answer is "yes".

Thanks,

-- 
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50
https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc


signature.asc
Description: PGP signature

Re: Heads-up: ifconfig address without a mask/width to become an error

[Michael Gmelin]

On Mon, 17 Jun 2024 10:54:29 -0400
Ed Maste  wrote:

> It is currently possible to specify an IPv4 address without a
> netmask/width to ifconfig or in rc.conf, e.g.:
> 
> ifconfig_igb0="192.168.0.2"
> 
> phk recently discovered[1] that ifconfig chose a poor netmask/width
> when none was specified. This was not an intentional change in
> defaults but rather a bug that has now been fixed by grembo@, in
> commit 8a9f0fa42b1c and merged to stable/14 in 048ad7a9ef9f. The fix
> will be in FreeBSD 14.2. I am unsure if there will be an EN update for
> 14.0/14.1. The bug does not exist in FreeBSD 13.x.
> 
> Specifying an IPv4 address without a mask/width has been deprecated
> since the deprecation of classful addressing. As of FreeBSD 13.1
> ifconfig has emitted a warning when no mask/width is specified, and
> the intent was to make it an error after a sufficient amount of time
> passed.
> 
> I've opened a Phabricator review[2] for ifconfig to change the warning
> into an error. I included a link to the review in phk's thread, and
> asked for input on timing for landing the change. As there seems to be
> consensus to include this change in FreeBSD 15.0 I plan to commit it
> soon and am sending this note to increase the visibility of the
> upcoming change.
> 
> This will be prominently noted in the 15.0 release notes, and should
> be mentioned in release notes for upcoming 13.x and 14.x releases.
> 
> [1]
> https://lists.freebsd.org/archives/freebsd-current/2024-June/006047.html
> [2] https://reviews.freebsd.org/D45585
> 

Hi Ed,

In case there is no EN, what is the process to add information about
issues like this to the release notes? Something like "known issues",
which those of us who read the release notes can stumble over and check?

This would be useful in general, as it seems like doing ENs is a lot of
overhead. Also, if that process would be fast, users would be warned
early - especially in a case like this, where the workaround/long term
fix is actually fairly trivial (add a netmask to your ifconfig_xxx
line).

Best
Michael

-- 
Michael Gmelin

Heads-up: ifconfig address without a mask/width to become an error

[Ed Maste]

It is currently possible to specify an IPv4 address without a
netmask/width to ifconfig or in rc.conf, e.g.:

ifconfig_igb0="192.168.0.2"

phk recently discovered[1] that ifconfig chose a poor netmask/width
when none was specified. This was not an intentional change in
defaults but rather a bug that has now been fixed by grembo@, in
commit 8a9f0fa42b1c and merged to stable/14 in 048ad7a9ef9f. The fix
will be in FreeBSD 14.2. I am unsure if there will be an EN update for
14.0/14.1. The bug does not exist in FreeBSD 13.x.

Specifying an IPv4 address without a mask/width has been deprecated
since the deprecation of classful addressing. As of FreeBSD 13.1
ifconfig has emitted a warning when no mask/width is specified, and
the intent was to make it an error after a sufficient amount of time
passed.

I've opened a Phabricator review[2] for ifconfig to change the warning
into an error. I included a link to the review in phk's thread, and
asked for input on timing for landing the change. As there seems to be
consensus to include this change in FreeBSD 15.0 I plan to commit it
soon and am sending this note to increase the visibility of the
upcoming change.

This will be prominently noted in the 15.0 release notes, and should
be mentioned in release notes for upcoming 13.x and 14.x releases.

[1] https://lists.freebsd.org/archives/freebsd-current/2024-June/006047.html
[2] https://reviews.freebsd.org/D45585

Heads up: Changes in VM image URLs

[Colin Percival]

Hi everyone,

We currently publish a number of VM images on download.freebsd.org:

* Generic VM images, with URLs like
https://download.freebsd.org/snapshots/VM-IMAGES/15.0-CURRENT/amd64/20240613/FreeBSD-15.0-CURRENT-amd64-ufs-20240613-bb53f071e85a-270741.qcow2.xz
https://download.freebsd.org/snapshots/VM-IMAGES/15.0-CURRENT/amd64/20240613/FreeBSD-15.0-CURRENT-amd64-20240613-bb53f071e85a-270741.qcow2.xz
https://download.freebsd.org/snapshots/VM-IMAGES/15.0-CURRENT/amd64/Latest/FreeBSD-15.0-CURRENT-amd64-ufs.qcow2.xz
https://download.freebsd.org/snapshots/VM-IMAGES/15.0-CURRENT/amd64/Latest/FreeBSD-15.0-CURRENT-amd64.qcow2.xz

* BASIC-CI images, with URLs like
https://download.freebsd.org/snapshots/CI-IMAGES/15.0-CURRENT/amd64/20240613/FreeBSD-15.0-CURRENT-amd64-BASIC-CI-20240613-bb53f071e85a-270741.raw.xz
and
https://download.freebsd.org/snapshots/CI-IMAGES/15.0-CURRENT/amd64/Latest/FreeBSD-15.0-CURRENT-amd64-BASIC-CI.raw.xz

* BASIC-CLOUDINIT images, with URLs like:
https://download.freebsd.org/snapshots/VM-IMAGES/15.0-CURRENT/amd64/20240613/FreeBSD-15.0-CURRENT-amd64-BASIC-CLOUDINIT-20240613-bb53f071e85a-270741.ufs.qcow2.xz
and
https://download.freebsd.org/snapshots/VM-IMAGES/15.0-CURRENT/amd64/Latest/FreeBSD-15.0-CURRENT-amd64-BASIC-CLOUDINIT.ufs.qcow2.xz

A few changes will be happening soon (probably this week for 15.x and next
week for 14.x):

* The BASIC-CLOUDINIT and BASIC-CI images, which are currently only published
for amd64, will also be published for aarch64.

* The BASIC-CI images, which currently have names like
FreeBSD-15.0-CURRENT-amd64-BASIC-CI.raw.xz
will also be published with names like
FreeBSD-15.0-CURRENT-amd64-BASIC-CI.ufs.raw.xz
(note that we currently only build UFS images for BASIC-CI; if anyone wants
ZFS images for BASIC-CI I can add them easily enough).

And another change will be happening some time in the next few months:

* The non-filesystem-labelled images, which are identical to the UFS images
and exist for backwards compatibility with scripts which were written before
we added support for non-UFS images, will cease to be published on 15.x (but
remain on older branches).

In short: If you have code which fetches any of those images, you'll want to
use the new URLs which specify the filesystem type explicitly.

--
Colin Percival
FreeBSD Release Engineering Lead & EC2 platform maintainer
Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid

Re: git: 8d3c3b52423f - main - mpi3mr: Track IO per target counter during queue poll with local variable

[FreeBSD User]

Am Thu, 6 Jun 2024 10:39:33 GMT
Sumit Saxena  schrieb:

> The branch main has been updated by ssaxena:
> 
> URL: 
> https://cgit.FreeBSD.org/src/commit/?id=8d3c3b52423f9740da424aa6dd73a20e694a9e08
> 
> commit 8d3c3b52423f9740da424aa6dd73a20e694a9e08
> Author: Chandrakanth patil 
> AuthorDate: 2024-06-06 10:28:38 +
> Commit: Sumit Saxena 
> CommitDate: 2024-06-06 10:39:16 +
> 
> mpi3mr: Track IO per target counter during queue poll with local variable
> 
> Reviewed by:imp
> Approved by:imp
> Differential revision:  https://reviews.freebsd.org/D44494
> ---
>  sys/dev/mpi3mr/mpi3mr_cam.c | 22 --
>  1 file changed, 12 insertions(+), 10 deletions(-)
> 
> diff --git a/sys/dev/mpi3mr/mpi3mr_cam.c b/sys/dev/mpi3mr/mpi3mr_cam.c
> index e3958ed8daf2..e00d61073d96 100644
> --- a/sys/dev/mpi3mr/mpi3mr_cam.c
> +++ b/sys/dev/mpi3mr/mpi3mr_cam.c
> @@ -1839,6 +1839,7 @@ int mpi3mr_remove_device_from_os(struct mpi3mr_softc 
> *sc, U16 handle)
>  {
>   int retval = 0;
>   struct mpi3mr_target *target;
> + unsigned int target_outstanding;
>  
>   mpi3mr_dprint(sc, MPI3MR_EVENT,
>   "Removing Device (dev_handle: %d)\n", handle);
> @@ -1856,16 +1857,17 @@ int mpi3mr_remove_device_from_os(struct mpi3mr_softc 
> *sc, U16 handle)
>  
>   target->flags |= MPI3MRSAS_TARGET_INREMOVAL;
>  
> - if (mpi3mr_atomic_read(>outstanding)) {
> - mpi3mr_dprint(sc, MPI3MR_ERROR, "there are [%2d] outstanding 
> IOs on target:
> %d"
> -   "Poll reply queue once\n",
> mpi3mr_atomic_read(>outstanding),
> -   target->per_id);
> - mpi3mr_poll_pend_io_completions(sc);
> - if (mpi3mr_atomic_read(>outstanding))
> - mpi3mr_dprint(sc, MPI3MR_ERROR, "[%2d] outstanding IOs 
> present on
> target: %d"
> -   "despite poll\n",
> mpi3mr_atomic_read(>outstanding),
> -   target->per_id);
> - }
> + target_outstanding = mpi3mr_atomic_read(>outstanding);
> + if (target_outstanding) {
> + mpi3mr_dprint(sc, MPI3MR_ERROR, "there are [%2d] outstanding 
> IOs on target:
> %d "
> +   "Poll reply queue once\n", target_outstanding,
> target->per_id);
> + mpi3mr_poll_pend_io_completions(sc);
> + target_outstanding = mpi3mr_atomic_read(>outstanding);
> + if (target_outstanding)
> + target_outstanding = 
> mpi3mr_atomic_read(>outstanding);
> + mpi3mr_dprint(sc, MPI3MR_ERROR, "[%2d] outstanding IOs 
> present on
> target: %d "
> +   "despite poll\n", target_outstanding, 
> target->per_id);
> + }
>  
>   if (target->exposed_to_os && !sc->reset_in_progress) {
>   mpi3mr_rescan_target(sc, target);
> 
On recent CURRENT (FreeBSD 15.0-CURRENT #6 main-n270784-d1e652bf04b: Sun Jun 16 
18:19:49 CEST
2024 amd64) "make installkernel" fails with:

[...]
--- realinstall_subdir_mpi3mr ---
install -T release -o root -g wheel -m 444   mpi3mr.ko /boot/kernel/
install -T dbg -o root -g wheel -m 444   mpi3mr.ko.debug 
/usr/lib/debug/boot/kernel/
install: /usr/lib/debug/boot/kernel/INS@QhWCmf: No such file or directory
*** [_kmodinstall] Error code 71

make[4]: stopped in /usr/src/sys/modules/mpi3mr
make[4]: 1 error
[...]

The problem occurs when diabling makeoptions DEBUG=... in kernel configuration 
and including:

# Debugging support.  Always need this:
#optionsKDB # Enable kernel debugger support.
#optionsKDB_TRACE   # Print a stack trace for a panic.
# For full debugger support use (turn off in stable branch):
include "std.nodebug"


On another host with the same CURRENT and mostly same configs, the problem does 
not
occur! The differenc between both is: tha failing host hasn't been updated for 
tha last 20
days, the other one has been updated almost every day.

On the failing host, "make cleanworld" has been issued before building 
world/kernel.

/etc/src.conf is also the same on both checked hosts. GENERIC compiles flawless.



-- 
O. Hartmann

[2 WEEKS LEFT REMINDER] Call for 2024Q2 status reports

[Lorenzo Salvadore]

Dear FreeBSD Community,

The deadline for the next FreeBSD Status Report update is
June, 30th 2024 for work done since the last round of quarterly reports:
April 2024 - June 2024.
I would like to remind you that reports are published on a quarterly
basis and are usually collected during the last month of each quarter,
You are also welcome to submit them even earlier if you want, and the
earlier you submit them, the more time we have for reviewing.

Status report submissions do not need to be very long. They may be
about anything happening in the FreeBSD project and community, and
they provide a great way to inform FreeBSD users and developers about
work that is underway or has been completed. Report submissions are
not limited to committers; anyone doing anything interesting and
FreeBSD related can -- and should -- write one!

The following methods are available to submit your reports:

* submit a review on Phabricator and add the group "status" to the
  reviewers list. You should put your reports in the directory
  doc/website/content/en/status/report-2024-04-2024-06/
  (create it if it is missing);

* submit a pull request at .
  You should put your reports in the directory
  doc/website/content/en/status/report-2024-04-2024-06/
  (create it if it is missing);

* send an email to status-submissi...@freebsd.org including your report.

An AsciiDoc template is available at
.

We look forward to seeing your 2024Q2 reports!

Thanks,

Lorenzo Salvadore (on behalf of status@)

Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out

[Rodney W. Grimes]

> On Fri, Jun 14, 2024 at 06:42:09AM GMT, Rodney W. Grimes wrote:
> > > "Poul-Henning Kamp"  writes:
> > > 
> > > > Defaulting to a /8 netmask for 192.168.x.y does not make *any* sense 
> > > > ever.
> > > 
> > > Well, not in the last 30 years or so, anyway.
> > 
> > No, never ever did /8 make since on 192.*.*.*, that has always been
> > class C address space.
> 
> I think what Poul-Henning meant is that 31 years ago, in 1993, classless
> inter-domain routing (CIDR) was introduced by the IETF, and it rendered
> "class"es of ip addresses obsoletes.
> 
> So, class C address spaces has been dead for 31 years :-)

NO!  That is an incorrect interpretation of what CIDR does, CIDR did
NOT remove the Class A/B/C applied to address space, it simply added
functionality (supernetting and subnetting) of the A/B/C space that
allows you to do things DIFFERENT than the default /8 /16 and /24
bit prefix length that classfull addresses implied.

> -- 
> Mathieu Arnold
-- 
Rod Grimes rgri...@freebsd.org

Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out

[Mathieu Arnold]

On Fri, Jun 14, 2024 at 06:42:09AM GMT, Rodney W. Grimes wrote:
> > "Poul-Henning Kamp"  writes:
> > 
> > > Defaulting to a /8 netmask for 192.168.x.y does not make *any* sense ever.
> > 
> > Well, not in the last 30 years or so, anyway.
> 
> No, never ever did /8 make since on 192.*.*.*, that has always been
> class C address space.

I think what Poul-Henning meant is that 31 years ago, in 1993, classless
inter-domain routing (CIDR) was introduced by the IETF, and it rendered
"class"es of ip addresses obsoletes.

So, class C address spaces has been dead for 31 years :-)

-- 
Mathieu Arnold


signature.asc
Description: PGP signature

Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out

[Rodney W. Grimes]

> "Poul-Henning Kamp"  writes:
> 
> > Defaulting to a /8 netmask for 192.168.x.y does not make *any* sense ever.
> 
> Well, not in the last 30 years or so, anyway.

No, never ever did /8 make since on 192.*.*.*, that has always been
class C address space.

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

Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out

[Lowell Gilbert]

"Poul-Henning Kamp"  writes:

> Defaulting to a /8 netmask for 192.168.x.y does not make *any* sense ever.

Well, not in the last 30 years or so, anyway.

Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out

[Ed Maste]

On Wed, 12 Jun 2024 at 14:08, Ed Maste  wrote:
>
> As for the path forward, what do folks think about changing the
> warning into an error in main in the near future (prior to 15.0)? That
> would provide about four years of releases that emit the warning,
> hopefully enough time for users to notice and update their
> configuration.

I opened a review in https://reviews.freebsd.org/D45585 to turn it
into an error. I've intentionally made it a minimal change to avoid
conflicts on future MFCs; it could be cleaned up and simplified once
older branches pass EOL.

Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out

[Chris]

On 2024-06-12 00:47, Poul-Henning Kamp wrote:

I had a machine with this line in /etc/rc.conf:

ifconfig_bla0="192.168.87.11"

I found out the hard way, that this defaults to /8 now.

The main symptom was that DNS was /really/ busted, which makes sense
when none of the DNS servers in the 192/8 "swamp" can be reached.

Since we all know that it is always DNS(SEC), I spent a lot of time
having fun with that, before I noticed the /8 netmask on the interface.

I agree that the class A/B/C netmask assumptions should have died long ago.

But from a foot-shooting point of view, it makes no sense to default
192.168/16 to a /8 netmask.

If we're going to default to /8, at the very least ifconfig should
spitting out a very noisy warning and wait 5 seconds before proceeding,
when the netmask is not explicitly specified.

But I also think we can do better than /8.

One option is to go for "limit the damage in RFC1918" and default
them according to their size: reach:

10/8
172.16/12
192.168/16

That will prevent the DNS weirdness I had to figure out, and probably
still DWIM in most cases.

Another option is to default all three to /24, which in my experience
is how people deploy RFC1918.

A third option is to default any missing netmask to /24 instead of /8,
which would be what I would personally have done in the first place.

I couldn't agree more. CPEs, WiFi AP's and most other network(ing) equipment
that most users encounter, generally default to a /24 (255.255.255.0).
IMHO this would result in the least amount of POLA. :)



Poul-Henning

--Chris

Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out

[Ed Maste]

On Wed, 12 Jun 2024 at 12:16, Michael Gmelin  wrote:
>
> So this is simply a bug.
>
> I opened a code review request to fix this:
> https://reviews.freebsd.org/D45570

Thank you. An EN for 14.0 and 14.1 (as suggested in your review) is
certainly warranted.

As for the path forward, what do folks think about changing the
warning into an error in main in the near future (prior to 15.0)? That
would provide about four years of releases that emit the warning,
hopefully enough time for users to notice and update their
configuration.

Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out

[Michael Gmelin]

On Wed, 12 Jun 2024 15:35:58 +
"Poul-Henning Kamp"  wrote:

> 
> Michael Gmelin writes:
> 
> > @phk From which version did you upgrade?  
> 
> To be totally honest: I'm not entirely sure.  Probably 13.x
> 

@Bjoern I checked again, I'm pretty sure the problem was introduced in
https://cgit.freebsd.org/src/commit/?id=4bf44dd73bc0a (this was part of
adding netlink into the code). The preparation work by the late Mike
Karels was consistent, as one can see in 13.x.

So basically the behavior on 13.x is:
- ifconfig bla0 10.1.1.1 => 10.1.1.1/8
- ifconfig bla0 192.168.1.1 => 192.168.1.1/24

This is in line with one would expect. On 14.x it's the opposite.

The code in 4bf44dd73bc0a68b73f7ee50d52adf5d7cda3eb8 introduced a
function to emulate the previous behavior. This function uses
IN_CLASSX_NSHIFT as bitmask - therefore 10.1.1.1 uses /24 and
192.168.1.1 uses /8. To fix the code, one has to actually use the
bitmask, which is (32 - IN_CLASSX_NSHIFT).

So this is simply a bug.

I opened a code review request to fix this:
https://reviews.freebsd.org/D45570

Best
Michael

-- 
Michael Gmelin

Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out

[Poul-Henning Kamp]

Michael Gmelin writes:

> @phk From which version did you upgrade?

To be totally honest: I'm not entirely sure.  Probably 13.x

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

Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out

[Michael Gmelin]

On Wed, 12 Jun 2024 15:11:14 + (UTC)
"Bjoern A. Zeeb"  wrote:

> On Wed, 12 Jun 2024, Bjoern A. Zeeb wrote:
> 
> > On Wed, 12 Jun 2024, Michael Gmelin wrote:
> >  
> >> 
> >> 
> >> On Wed, 12 Jun 2024 14:36:35 +
> >> "Poul-Henning Kamp"  wrote:
> >>   
> >>> 
> >>> Bjoern A. Zeeb writes:
> >>>   
> > I had a machine with this line in /etc/rc.conf:
> >
> > ifconfig_bla0="192.168.87.11"
> > 
> > I found out the hard way, that this defaults to /8 now.  
>  
>  Did you track it down to a specific change?  I.e. is this
>  ifconfig/netlink or the old kernel change from like two years(?)
>  ago?
>  
>  Do you have a time window when this broke as that'll help people
>  to bisect?  
> >>> 
> >>> I have no idea, sorry, I just freebsd-updated this one box...
> >>>   
> >> 
> >> I just tried on 14.0-p6, same there:
> >>
> >>  # ifconfig vtnet0 192.168.87.11
> >>  ifconfig: WARNING: setting interface address without mask is
> >>  deprecated, default mask may not be correct.
> >> 
> >> Interestingly, `ifconfig vtnet0 10.0.0.1` uses "/24" whereas
> >> 192.168.87.11 uses "/8".
> >> 
> >> This dates back to:
> >> https://cgit.freebsd.org/src/commit/?id=4bf44dd73bc0a  
> >
> > No it pre-dates that chnage.
> >
> > It goes back to d8237b95552807e937fc389c7e2237679ef0c984 and related
> > changes.  
> 
> Sorry I hit send too early
> 
> And I think it came out of
> 
> commit 2f35e7d9fa03f27543f347cd6277af5bfc6a7e95
> commit 20d59403961d531467cfab22163f49c131cc8b55
> 

Hm, the deprecation warning was introduced in 2021 and was already part
of 13.1 it seems:
https://cgit.freebsd.org/src/commit/?id=4dbba5ab609c9

Going through these various commits, default behavior changed. Just
tried on 13.2, where 10.x.x.x gave me /8 and 192.168.x.x gave me /24.

@phk From which version did you upgrade?

Best

-- 
Michael Gmelin

Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out

[Bjoern A. Zeeb]

On Wed, 12 Jun 2024, Bjoern A. Zeeb wrote:


On Wed, 12 Jun 2024, Michael Gmelin wrote:




On Wed, 12 Jun 2024 14:36:35 +
"Poul-Henning Kamp"  wrote:



Bjoern A. Zeeb writes:


I had a machine with this line in /etc/rc.conf:

ifconfig_bla0="192.168.87.11"

I found out the hard way, that this defaults to /8 now.


Did you track it down to a specific change?  I.e. is this
ifconfig/netlink or the old kernel change from like two years(?)
ago?

Do you have a time window when this broke as that'll help people to
bisect?


I have no idea, sorry, I just freebsd-updated this one box...



I just tried on 14.0-p6, same there:

 # ifconfig vtnet0 192.168.87.11
 ifconfig: WARNING: setting interface address without mask is
 deprecated, default mask may not be correct.

Interestingly, `ifconfig vtnet0 10.0.0.1` uses "/24" whereas
192.168.87.11 uses "/8".

This dates back to:
https://cgit.freebsd.org/src/commit/?id=4bf44dd73bc0a


No it pre-dates that chnage.

It goes back to d8237b95552807e937fc389c7e2237679ef0c984 and related
changes.


Sorry I hit send too early

And I think it came out of

commit 2f35e7d9fa03f27543f347cd6277af5bfc6a7e95
commit 20d59403961d531467cfab22163f49c131cc8b55

--
Bjoern A. Zeeb r15:7

Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out

[Bjoern A. Zeeb]

On Wed, 12 Jun 2024, Michael Gmelin wrote:




On Wed, 12 Jun 2024 14:36:35 +
"Poul-Henning Kamp"  wrote:



Bjoern A. Zeeb writes:


I had a machine with this line in /etc/rc.conf:

ifconfig_bla0="192.168.87.11"

I found out the hard way, that this defaults to /8 now.


Did you track it down to a specific change?  I.e. is this
ifconfig/netlink or the old kernel change from like two years(?)
ago?

Do you have a time window when this broke as that'll help people to
bisect?


I have no idea, sorry, I just freebsd-updated this one box...



I just tried on 14.0-p6, same there:

 # ifconfig vtnet0 192.168.87.11
 ifconfig: WARNING: setting interface address without mask is
 deprecated, default mask may not be correct.

Interestingly, `ifconfig vtnet0 10.0.0.1` uses "/24" whereas
192.168.87.11 uses "/8".

This dates back to:
https://cgit.freebsd.org/src/commit/?id=4bf44dd73bc0a


No it pre-dates that chnage.

It goes back to d8237b95552807e937fc389c7e2237679ef0c984 and related
changes.

--
Bjoern A. Zeeb r15:7

Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out

[Michael Gmelin]

On Wed, 12 Jun 2024 14:36:35 +
"Poul-Henning Kamp"  wrote:

> 
> Bjoern A. Zeeb writes:
> 
> > > I had a machine with this line in /etc/rc.conf:
> > >
> > >   ifconfig_bla0="192.168.87.11"
> > >
> > > I found out the hard way, that this defaults to /8 now.  
> >
> > Did you track it down to a specific change?  I.e. is this
> > ifconfig/netlink or the old kernel change from like two years(?)
> > ago?
> >
> > Do you have a time window when this broke as that'll help people to
> > bisect?  
> 
> I have no idea, sorry, I just freebsd-updated this one box...
> 

I just tried on 14.0-p6, same there:

  # ifconfig vtnet0 192.168.87.11
  ifconfig: WARNING: setting interface address without mask is
  deprecated, default mask may not be correct.

Interestingly, `ifconfig vtnet0 10.0.0.1` uses "/24" whereas
192.168.87.11 uses "/8".

This dates back to:
https://cgit.freebsd.org/src/commit/?id=4bf44dd73bc0a

-m

-- 
Michael Gmelin

Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out

[Poul-Henning Kamp]

Rodney W. Grimes writes:

> *Stomps off my soap box, hands phk a bandaid for the bite mark (always,
> always specify critical values even if they are the default), and
> retreats to the background*

/me hands Rod a glass of lemonade: "It's OK, you're welcome on my lawn :-)"

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

Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out

[Rodney W. Grimes]

> 
> Michael Gmelin writes:
> 
> > You can do an interface route hack
> 
> I think you misunderstand the situation.
> 
> We are talking about people who have /etc/rc.conf files which relied
> on how default netmasks have worked for nearly three decades,
> 
> Now that we have changed that default, many of them will see a
> single line rapidly scroll off their console, and a set of very
> bewilding symptoms of DNS not working correctly.
> 
> The solution is not for them to apply some weird, complex and
> unnecessary interface configuration.
> 
> The solution is for us to not break their configuration in the first
> place, or at least make it much more obvious to them, where the problem
> is to be found.
> 
> Defaulting to a /8 netmask for 192.168.x.y does not make *any* sense ever.

Why have I been bitching for 20 years about how the project just
changes "defaults" that effect how a system behavies without
any change by the user.  In my book these are just plainly WRONG
and well, have and continue to bite someone in the ass.

No one else seems to complain unless it bites THEM in the ass,
well there is ALWAYS and THEM so the project should be far
more considerate than they have been, IMHO, about bitting
asses, as those asses are connected to the hands that feed
this project by growth.

It is not that hard to intruduce NEW behavior yet retain the OLD behavior
with lots of warning that it is exepcted to change or go away in
the future.

*Stomps off my soap box, hands phk a bandaid for the bite mark (always,
always specify critical values even if they are the default), and
retreats to the background*

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

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

Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out

[Poul-Henning Kamp]

Bjoern A. Zeeb writes:

> > I had a machine with this line in /etc/rc.conf:
> >
> > ifconfig_bla0="192.168.87.11"
> >
> > I found out the hard way, that this defaults to /8 now.
>
> Did you track it down to a specific change?  I.e. is this
> ifconfig/netlink or the old kernel change from like two years(?) ago?
>
> Do you have a time window when this broke as that'll help people to
> bisect?

I have no idea, sorry, I just freebsd-updated this one box...

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

Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out

[Bjoern A. Zeeb]

On Wed, 12 Jun 2024, Poul-Henning Kamp wrote:


I had a machine with this line in /etc/rc.conf:

ifconfig_bla0="192.168.87.11"

I found out the hard way, that this defaults to /8 now.


Did you track it down to a specific change?  I.e. is this
ifconfig/netlink or the old kernel change from like two years(?) ago?

Do you have a time window when this broke as that'll help people to
bisect?

--
Bjoern A. Zeeb r15:7

Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out

[Bob Bishop]

Hi,

> On 12 Jun 2024, at 12:28, Poul-Henning Kamp  wrote:
> 
> Defaulting to a /8 netmask for 192.168.x.y does not make *any* sense ever.

+1

--
Bob Bishop
r...@gid.co.uk

Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out

[Ronald Klop]

Van: Poul-Henning Kamp 
Datum: woensdag, 12 juni 2024 12:39
Aan: Ronald Klop 
CC: curr...@freebsd.org
Onderwerp: Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure 
out


Ronald Klop writes:

> What do you thing about defaulting to /32 on a missing netmask?
> An interface with 1 IP address without any information about the network. All 
traffic can go to the gateway.

I dont think that will work ?

The gateway will not be inside any of the attached networks, so you have no 
route to it ?

Poul-Henning

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






Ai. Of course. Typed quicker than I was thinking. :-)

Well. Then it is maybe best to just error out on boot with a misconfigured 
network. Or revert back to the pre-14.1 behavior because of POLA.
I'll leave it up to you and will make sure I configure my interfaces with a 
netmask.

Regards,
Ronald.

Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out

[Michael Gmelin]

On Wed, 12 Jun 2024 11:28:38 +
"Poul-Henning Kamp"  wrote:

> 
> Michael Gmelin writes:
> 
> > You can do an interface route hack  
> 
> I think you misunderstand the situation.

I completely understand the situation and I can feel your pain, I just
wanted to throw in how to reach the default gateway when using a /32
mask. Hence me ending with "in the context of deciding on default
behavior when no mask is given this is probably not very helpful".
Maybe no news for those following this thread, so sorry if the noise
annoyed you.

> 
> We are talking about people who have /etc/rc.conf files which relied
> on how default netmasks have worked for nearly three decades,
> 
> Now that we have changed that default, many of them will see a
> single line rapidly scroll off their console, and a set of very
> bewilding symptoms of DNS not working correctly.

We had similar breaking changes with the route command[0] (personally I
really would like to support the same syntax for ip/netmasks that is
accepted by pf.conf, but that's off-topic).

If I remember correctly, there was also a breaking change in the syntax
on how to create vlandev's recently.

> 
> The solution is not for them to apply some weird, complex and
> unnecessary interface configuration.

Agreed.

> 
> The solution is for us to not break their configuration in the first
> place, or at least make it much more obvious to them, where the
> problem is to be found.

Agreed as well.

> 
> Defaulting to a /8 netmask for 192.168.x.y does not make *any* sense
> ever.

Agreed - for RFC1918 addresses at least applying the natural default
netmasks (/8, /10, and /16) would feel more logical.

The question is if adding all this magic actually makes sense, or if it
wouldn't be better to just not accept an IP without netmask anymore
(like suggested, make it emit a warning or even make it an error).
Ideally, this should have been a warning/deprecation notice a while ago.

Going back to previous behavior is probably not an option at this point.

One way forward could be to support validating interface settings in
rc.conf by using the a "check" or "configtest" subcommand - this is
already used by many rc scripts (e.g., `service pf check`, `service
nginx configtest`).

So there could be `service netif check`, which can be run manually as
well as automatically as part of freebsd-update/pkgbase (ideally on a
updated config files, but **before** the installation is actually done).

It could also run automatically during boot and display an error +
sleep 5 in case it finds any issues to warn the admin.

Adding such `check` subcommands could actually benefit many rc scripts
(e.g., `service mountlate check`). Being able to call check on all rc
scripts supporting it with one command could also help admins to
identify problems early and therefore give more confidence when reboot
testing configuration changes.

Best
Michael

[0]https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276092

-- 
Michael Gmelin

Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out

[Poul-Henning Kamp]

Michael Gmelin writes:

> You can do an interface route hack

I think you misunderstand the situation.

We are talking about people who have /etc/rc.conf files which relied
on how default netmasks have worked for nearly three decades,

Now that we have changed that default, many of them will see a
single line rapidly scroll off their console, and a set of very
bewilding symptoms of DNS not working correctly.

The solution is not for them to apply some weird, complex and
unnecessary interface configuration.

The solution is for us to not break their configuration in the first
place, or at least make it much more obvious to them, where the problem
is to be found.

Defaulting to a /8 netmask for 192.168.x.y does not make *any* sense ever.

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

Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out

[Michael Gmelin]

On Wed, 12 Jun 2024 10:39:36 +
"Poul-Henning Kamp"  wrote:

> Ronald Klop writes:
> 
> > What do you thing about defaulting to /32 on a missing netmask?
> > An interface with 1 IP address without any information about the
> > network All traffic can go to the gateway.  
> 
> I dont think that will work ?
> 
> The gateway will not be inside any of the attached networks, so you
> have no route to it ?
> 

You can do an interface route hack

  sysrc static_routes="gateway default"
  sysrc route_gateway="-host 1.2.3.4 -interface bla0"
  sysrc route_default="default 1.2.3.4"

This is actually quite useful in some setups, but in the context of
deciding on default behavior when no mask is given this is probably not
very helpful.

Cheers

-- 
Michael Gmelin

Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out

[Poul-Henning Kamp]

Ronald Klop writes:

> What do you thing about defaulting to /32 on a missing netmask?
> An interface with 1 IP address without any information about the network All 
> traffic can go to the gateway.

I dont think that will work ?

The gateway will not be inside any of the attached networks, so you have no 
route to it ?

Poul-Henning

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

Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out

[Ronald Klop]

Van: Poul-Henning Kamp 
Datum: woensdag, 12 juni 2024 09:47
Aan: curr...@freebsd.org
Onderwerp: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out


I had a machine with this line in /etc/rc.conf:

ifconfig_bla0="192.168.87.11"

I found out the hard way, that this defaults to /8 now.

The main symptom was that DNS was /really/ busted, which makes sense
when none of the DNS servers in the 192/8 "swamp" can be reached.

Since we all know that it is always DNS(SEC), I spent a lot of time
having fun with that, before I noticed the /8 netmask on the interface.

I agree that the class A/B/C netmask assumptions should have died long ago.

But from a foot-shooting point of view, it makes no sense to default
192.168/16 to a /8 netmask.

If we're going to default to /8, at the very least ifconfig should
spitting out a very noisy warning and wait 5 seconds before proceeding,
when the netmask is not explicitly specified.

But I also think we can do better than /8.

One option is to go for "limit the damage in RFC1918" and default
them according to their size: reach:

10/8
172.16/12
192.168/16

That will prevent the DNS weirdness I had to figure out, and probably
still DWIM in most cases.

Another option is to default all three to /24, which in my experience
is how people deploy RFC1918.

A third option is to default any missing netmask to /24 instead of /8,
which would be what I would personally have done in the first place.

Poul-Henning

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







What do you thing about defaulting to /32 on a missing netmask?
An interface with 1 IP address without any information about the network. All 
traffic can go to the gateway.

Regards,
Ronald.

14.1-R rc.conf/ifconfig netmask issue was really hard to figure out

[Poul-Henning Kamp]

I had a machine with this line in /etc/rc.conf:

ifconfig_bla0="192.168.87.11"

I found out the hard way, that this defaults to /8 now.

The main symptom was that DNS was /really/ busted, which makes sense
when none of the DNS servers in the 192/8 "swamp" can be reached.

Since we all know that it is always DNS(SEC), I spent a lot of time
having fun with that, before I noticed the /8 netmask on the interface.

I agree that the class A/B/C netmask assumptions should have died long ago.

But from a foot-shooting point of view, it makes no sense to default
192.168/16 to a /8 netmask.

If we're going to default to /8, at the very least ifconfig should
spitting out a very noisy warning and wait 5 seconds before proceeding,
when the netmask is not explicitly specified.

But I also think we can do better than /8.

One option is to go for "limit the damage in RFC1918" and default
them according to their size: reach:

10/8
172.16/12
192.168/16

That will prevent the DNS weirdness I had to figure out, and probably
still DWIM in most cases.

Another option is to default all three to /24, which in my experience
is how people deploy RFC1918.

A third option is to default any missing netmask to /24 instead of /8,
which would be what I would personally have done in the first place.

Poul-Henning

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

Re: Deprecating smbfs(5) and removing it before FreeBSD 14

[Tomoaki AOKI]

On Tue, 4 Jun 2024 14:52:25 -0700
John Hixson  wrote:

> On Mon, Jun 27, 2022 at 03:27:54PM +0200, Miroslav Lachman wrote:
> > On 16/06/2022 15:56, Rick Macklem wrote:
> > > Miroslav Lachman <000.f...@quip.cz> wrote:
> > > > On 24/01/2022 16:13, Rick Macklem wrote:
> > > > 
> > > [...]
> > > > 
> > > > > So, I think Mark and Yuri are correct and looking at up to date
> > > > > Illumos sources is the next step.
> > > > > (As I mentioned, porting the Apple sources is beyond what I am
> > > > >willing to attempt.)
> > > > > 
> > > > > rick
> > > > 
> > > > Hello Rick,
> > > > I would like to ask you I there is some progress with porting newer
> > > > SMBFS / CIFS version to FreeBSD? Did you find Illumos sources as a
> > > > possibility where to start porting?
> > > Yes. I have the stuff off Illumos-gate, which I think is pretty up-to-date
> > > and I agree that it should be easier than the Apple stuff to port into
> > > FreeBSD.  I don't think it is "straightforward" as someone involved
> > > with Illumos said, due to the big differences in VFS/locking, but...
> > > 
> > > Having said the above, I have not done much yet. I've been cleaning up
> > > NFS stuff, although I am nearly done with that now.
> > > I do plan on starting to work on it soon, but have no idea if/when I
> > > will have something that might be useful for others.
> > 
> > I'm glad to hear that.
> > 
> > > > We have more and more problems with current state of mount_smbfs. I
> > > > would be really glad if "somebody" can do the heroic work of
> > > > implementing SMBv2 in FreeBSD.
> > > > Maybe it's time to start some fundraising for sponsoring this work?
> > > Well, funding isn't an issue for me (I'm just a retired guy who does this
> > > stuff as a hobby). However, if there is someone else who is capable of
> > > doing it if they are funded, I have no problem with that.
> > > I could either help them, or simply stick with working on NFS and leave
> > > SMBv23 to them.
> > > 
> > > Sorry, but I cannot report real progress on this as yet, rick
> > 
> > No need to sorry. I really appreciate your endless work on NFS and that you
> > still have kind of interest to try porting SMBv2/3.
> > Unfortunately I don't know anybody else trying to do this tremendous work.
> > 
> 
> I am working on a from scratch implementation of smbfs. I do not have
> any kind of time estimate since it is in my spare time. I chose this
> route after spending considerable time looking at Apple and Solaris
> implementations and wanting something without all of the legacy 1.0
> crap. I do have a very minimal working FUSE version at this point, but
> there is much to do, and even more to abide by the various
> specifications.
> 
> I just thought I'd share in case anyone is interested.
> 
> - John

Hi! Thanks for popping in. As others already commented, this is a long
awaited feature.

As I've already raised a white flag to port darwin implementation,
maybe I cannot help on coding, but I'd be happy to test once something
to test is available.

# I tried years ago with a bit of hope that the darwin code could be almost
# a drop-in replacement, but it was clearly beyond me. Too many macros to
# look for actual codes to see what for, functions etc which were incompatible
# with FreeBSD SMB1 implementation.

-- 
Tomoaki AOKI

Re: 41dfea24eec panics during ata attach on ESXi VM

[John Baldwin]

On 6/5/24 4:35 AM, Yuri Pankov wrote:

After updating to 41dfea24eec (GENERIC-NODEBUG), ESXi VM started to
panic while attaching atapci children.  I was unable to grab original
boot panic data ("keyboard" dead), but was able to boot with
hint.ata.0.disabled=1, hint.ata.1.disabled=1, and `devctl enable ata0`
reproduced the issue:

ata0:  at channel 0 on atapci0


This should be fixed now by commit 56b822a17cde5940909633c50623d463191a7852.
Sorry for the breakage.

--
John Baldwin

Re: Deprecating smbfs(5) and removing it before FreeBSD 14

[Gleb Popov]

On Wed, Jun 5, 2024 at 12:52 AM John Hixson  wrote:
>
> I am working on a from scratch implementation of smbfs. I do not have
> any kind of time estimate since it is in my spare time. I chose this
> route after spending considerable time looking at Apple and Solaris
> implementations and wanting something without all of the legacy 1.0
> crap. I do have a very minimal working FUSE version at this point, but
> there is much to do, and even more to abide by the various
> specifications.
>
> I just thought I'd share in case anyone is interested.
>
> - John

Thanks for sharing.
We're building a FreeBSD based product and SMB2/3 support is very
important to us. Maybe we can combine our efforts on this matter?

I also contacted the FreeBSD Enterprise Working Group about this. The
Greg's reply was

> The verbal offer to donate an up to date fork of this still stands, but the 
> timing remains unclear. I continue asking.

It is still unclear to me if the code is already written by some party
and now the negotiation is going on about licensing it as BSD.

Re: Deprecating smbfs(5) and removing it before FreeBSD 14

[Miroslav Lachman]

On 05/06/2024 01:05, John Hixson wrote:


Thank you for the message. I'm glad someone has the courage to take the
plunge. Smbfs is still very important to me. In a heterogeneous environment
it is still the most common way to share data between systems.
Are you planning the final version as a kernel module, or will the final
version be via FUSE? I have had bad experiences with FUSE in the past with
stability and performance.


The final version will be a kernel module. It  will also be BSD
licensed. I am not an expert at the VFS layer so I want to get the stack
ironed out in FUSE before moving it into kernel space.


This is really good news. I can't help with the code, but once you get 
something I can test, let me know. I'd be happy to help with testing.


Best regards
Miroslav Lachman

Re: Deprecating smbfs(5) and removing it before FreeBSD 14

[Rick Macklem]

On Tue, Jun 4, 2024 at 5:18 PM Alan Somers  wrote:
>
> 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.
>
>
> On Tue, Jun 4, 2024 at 3:52 PM John Hixson  wrote:
> >
> > On Mon, Jun 27, 2022 at 03:27:54PM +0200, Miroslav Lachman wrote:
> > > On 16/06/2022 15:56, Rick Macklem wrote:
> > > > Miroslav Lachman <000.f...@quip.cz> wrote:
> > > > > On 24/01/2022 16:13, Rick Macklem wrote:
> > > > >
> > > > [...]
> > > > >
> > > > > > So, I think Mark and Yuri are correct and looking at up to date
> > > > > > Illumos sources is the next step.
> > > > > > (As I mentioned, porting the Apple sources is beyond what I am
> > > > > >willing to attempt.)
> > > > > >
> > > > > > rick
> > > > >
> > > > > Hello Rick,
> > > > > I would like to ask you I there is some progress with porting newer
> > > > > SMBFS / CIFS version to FreeBSD? Did you find Illumos sources as a
> > > > > possibility where to start porting?
> > > > Yes. I have the stuff off Illumos-gate, which I think is pretty 
> > > > up-to-date
> > > > and I agree that it should be easier than the Apple stuff to port into
> > > > FreeBSD.  I don't think it is "straightforward" as someone involved
> > > > with Illumos said, due to the big differences in VFS/locking, but...
> > > >
> > > > Having said the above, I have not done much yet. I've been cleaning up
> > > > NFS stuff, although I am nearly done with that now.
> > > > I do plan on starting to work on it soon, but have no idea if/when I
> > > > will have something that might be useful for others.
> > >
> > > I'm glad to hear that.
> > >
> > > > > We have more and more problems with current state of mount_smbfs. I
> > > > > would be really glad if "somebody" can do the heroic work of
> > > > > implementing SMBv2 in FreeBSD.
> > > > > Maybe it's time to start some fundraising for sponsoring this work?
> > > > Well, funding isn't an issue for me (I'm just a retired guy who does 
> > > > this
> > > > stuff as a hobby). However, if there is someone else who is capable of
> > > > doing it if they are funded, I have no problem with that.
> > > > I could either help them, or simply stick with working on NFS and leave
> > > > SMBv23 to them.
> > > >
> > > > Sorry, but I cannot report real progress on this as yet, rick
> > >
> > > No need to sorry. I really appreciate your endless work on NFS and that 
> > > you
> > > still have kind of interest to try porting SMBv2/3.
> > > Unfortunately I don't know anybody else trying to do this tremendous work.
> > >
> >
> > I am working on a from scratch implementation of smbfs. I do not have
> > any kind of time estimate since it is in my spare time. I chose this
> > route after spending considerable time looking at Apple and Solaris
> > implementations and wanting something without all of the legacy 1.0
> > crap. I do have a very minimal working FUSE version at this point, but
> > there is much to do, and even more to abide by the various
> > specifications.
> >
> > I just thought I'd share in case anyone is interested.
Best of luck with it. I never got far into porting the Illumos code.

rick

> >
> > - John
>
> I am indeed interested.  smbfs is an important feature to have.  Let
> me know if you need help with the fuse parts.
> -Alan

Re: Deprecating smbfs(5) and removing it before FreeBSD 14

[Alan Somers]

On Tue, Jun 4, 2024 at 3:52 PM John Hixson  wrote:
>
> On Mon, Jun 27, 2022 at 03:27:54PM +0200, Miroslav Lachman wrote:
> > On 16/06/2022 15:56, Rick Macklem wrote:
> > > Miroslav Lachman <000.f...@quip.cz> wrote:
> > > > On 24/01/2022 16:13, Rick Macklem wrote:
> > > >
> > > [...]
> > > >
> > > > > So, I think Mark and Yuri are correct and looking at up to date
> > > > > Illumos sources is the next step.
> > > > > (As I mentioned, porting the Apple sources is beyond what I am
> > > > >willing to attempt.)
> > > > >
> > > > > rick
> > > >
> > > > Hello Rick,
> > > > I would like to ask you I there is some progress with porting newer
> > > > SMBFS / CIFS version to FreeBSD? Did you find Illumos sources as a
> > > > possibility where to start porting?
> > > Yes. I have the stuff off Illumos-gate, which I think is pretty up-to-date
> > > and I agree that it should be easier than the Apple stuff to port into
> > > FreeBSD.  I don't think it is "straightforward" as someone involved
> > > with Illumos said, due to the big differences in VFS/locking, but...
> > >
> > > Having said the above, I have not done much yet. I've been cleaning up
> > > NFS stuff, although I am nearly done with that now.
> > > I do plan on starting to work on it soon, but have no idea if/when I
> > > will have something that might be useful for others.
> >
> > I'm glad to hear that.
> >
> > > > We have more and more problems with current state of mount_smbfs. I
> > > > would be really glad if "somebody" can do the heroic work of
> > > > implementing SMBv2 in FreeBSD.
> > > > Maybe it's time to start some fundraising for sponsoring this work?
> > > Well, funding isn't an issue for me (I'm just a retired guy who does this
> > > stuff as a hobby). However, if there is someone else who is capable of
> > > doing it if they are funded, I have no problem with that.
> > > I could either help them, or simply stick with working on NFS and leave
> > > SMBv23 to them.
> > >
> > > Sorry, but I cannot report real progress on this as yet, rick
> >
> > No need to sorry. I really appreciate your endless work on NFS and that you
> > still have kind of interest to try porting SMBv2/3.
> > Unfortunately I don't know anybody else trying to do this tremendous work.
> >
>
> I am working on a from scratch implementation of smbfs. I do not have
> any kind of time estimate since it is in my spare time. I chose this
> route after spending considerable time looking at Apple and Solaris
> implementations and wanting something without all of the legacy 1.0
> crap. I do have a very minimal working FUSE version at this point, but
> there is much to do, and even more to abide by the various
> specifications.
>
> I just thought I'd share in case anyone is interested.
>
> - John

I am indeed interested.  smbfs is an important feature to have.  Let
me know if you need help with the fuse parts.
-Alan

Re: Deprecating smbfs(5) and removing it before FreeBSD 14

[John Hixson]

> 
> Thank you for the message. I'm glad someone has the courage to take the
> plunge. Smbfs is still very important to me. In a heterogeneous environment
> it is still the most common way to share data between systems.
> Are you planning the final version as a kernel module, or will the final
> version be via FUSE? I have had bad experiences with FUSE in the past with
> stability and performance.

The final version will be a kernel module. It  will also be BSD
licensed. I am not an expert at the VFS layer so I want to get the stack
ironed out in FUSE before moving it into kernel space.

- John


signature.asc
Description: PGP signature

Re: Deprecating smbfs(5) and removing it before FreeBSD 14

[Miroslav Lachman]

On 04/06/2024 23:52, John Hixson wrote:

On Mon, Jun 27, 2022 at 03:27:54PM +0200, Miroslav Lachman wrote:

On 16/06/2022 15:56, Rick Macklem wrote:

Miroslav Lachman <000.f...@quip.cz> wrote:

On 24/01/2022 16:13, Rick Macklem wrote:


[...]



So, I think Mark and Yuri are correct and looking at up to date
Illumos sources is the next step.
(As I mentioned, porting the Apple sources is beyond what I am
willing to attempt.)

rick


Hello Rick,
I would like to ask you I there is some progress with porting newer
SMBFS / CIFS version to FreeBSD? Did you find Illumos sources as a
possibility where to start porting?

Yes. I have the stuff off Illumos-gate, which I think is pretty up-to-date
and I agree that it should be easier than the Apple stuff to port into
FreeBSD.  I don't think it is "straightforward" as someone involved
with Illumos said, due to the big differences in VFS/locking, but...

Having said the above, I have not done much yet. I've been cleaning up
NFS stuff, although I am nearly done with that now.
I do plan on starting to work on it soon, but have no idea if/when I
will have something that might be useful for others.


I'm glad to hear that.


We have more and more problems with current state of mount_smbfs. I
would be really glad if "somebody" can do the heroic work of
implementing SMBv2 in FreeBSD.
Maybe it's time to start some fundraising for sponsoring this work?

Well, funding isn't an issue for me (I'm just a retired guy who does this
stuff as a hobby). However, if there is someone else who is capable of
doing it if they are funded, I have no problem with that.
I could either help them, or simply stick with working on NFS and leave
SMBv23 to them.

Sorry, but I cannot report real progress on this as yet, rick


No need to sorry. I really appreciate your endless work on NFS and that you
still have kind of interest to try porting SMBv2/3.
Unfortunately I don't know anybody else trying to do this tremendous work.



I am working on a from scratch implementation of smbfs. I do not have
any kind of time estimate since it is in my spare time. I chose this
route after spending considerable time looking at Apple and Solaris
implementations and wanting something without all of the legacy 1.0
crap. I do have a very minimal working FUSE version at this point, but
there is much to do, and even more to abide by the various
specifications.

I just thought I'd share in case anyone is interested.


Thank you for the message. I'm glad someone has the courage to take the 
plunge. Smbfs is still very important to me. In a heterogeneous 
environment it is still the most common way to share data between systems.
Are you planning the final version as a kernel module, or will the final 
version be via FUSE? I have had bad experiences with FUSE in the past 
with stability and performance.


Best regards
Miroslav Lachman

Re: Deprecating smbfs(5) and removing it before FreeBSD 14

[John Hixson]

On Mon, Jun 27, 2022 at 03:27:54PM +0200, Miroslav Lachman wrote:
> On 16/06/2022 15:56, Rick Macklem wrote:
> > Miroslav Lachman <000.f...@quip.cz> wrote:
> > > On 24/01/2022 16:13, Rick Macklem wrote:
> > > 
> > [...]
> > > 
> > > > So, I think Mark and Yuri are correct and looking at up to date
> > > > Illumos sources is the next step.
> > > > (As I mentioned, porting the Apple sources is beyond what I am
> > > >willing to attempt.)
> > > > 
> > > > rick
> > > 
> > > Hello Rick,
> > > I would like to ask you I there is some progress with porting newer
> > > SMBFS / CIFS version to FreeBSD? Did you find Illumos sources as a
> > > possibility where to start porting?
> > Yes. I have the stuff off Illumos-gate, which I think is pretty up-to-date
> > and I agree that it should be easier than the Apple stuff to port into
> > FreeBSD.  I don't think it is "straightforward" as someone involved
> > with Illumos said, due to the big differences in VFS/locking, but...
> > 
> > Having said the above, I have not done much yet. I've been cleaning up
> > NFS stuff, although I am nearly done with that now.
> > I do plan on starting to work on it soon, but have no idea if/when I
> > will have something that might be useful for others.
> 
> I'm glad to hear that.
> 
> > > We have more and more problems with current state of mount_smbfs. I
> > > would be really glad if "somebody" can do the heroic work of
> > > implementing SMBv2 in FreeBSD.
> > > Maybe it's time to start some fundraising for sponsoring this work?
> > Well, funding isn't an issue for me (I'm just a retired guy who does this
> > stuff as a hobby). However, if there is someone else who is capable of
> > doing it if they are funded, I have no problem with that.
> > I could either help them, or simply stick with working on NFS and leave
> > SMBv23 to them.
> > 
> > Sorry, but I cannot report real progress on this as yet, rick
> 
> No need to sorry. I really appreciate your endless work on NFS and that you
> still have kind of interest to try porting SMBv2/3.
> Unfortunately I don't know anybody else trying to do this tremendous work.
> 

I am working on a from scratch implementation of smbfs. I do not have
any kind of time estimate since it is in my spare time. I chose this
route after spending considerable time looking at Apple and Solaris
implementations and wanting something without all of the legacy 1.0
crap. I do have a very minimal working FUSE version at this point, but
there is much to do, and even more to abide by the various
specifications.

I just thought I'd share in case anyone is interested.

- John


signature.asc
Description: PGP signature

Re: gcc behavior of init priority of .ctors and .dtors section

[John Baldwin]

On 5/16/24 4:05 PM, Lorenzo Salvadore wrote:

On Thursday, May 16th, 2024 at 20:26, Konstantin Belousov  
wrote:

gcc13 from ports
`# gcc ctors.c && ./a.out init 1 init 2 init 5 init 4 init 3 main fini 3 fini 4 
fini 5 fini 2 fini 1`

The above order is not expected. I think clang's one is correct.

Further hacking with readelf shows that clang produces the right order of
section .rela.ctors but gcc does not.

```
# clang -fno-use-init-array -c ctors.c && readelf -r ctors.o | grep 'Relocation 
section with addend (.rela.ctors)' -A5 > clang.txt
# gcc -c ctors.c && readelf -r ctors.o | grep 'Relocation section with addend 
(.rela.ctors)' -A5 > gcc.txt
# diff clang.txt gcc.txt
3,5c3,5
<  00080001 R_X86_64_64 0060 init_65535_2 + 0
< 0008 00070001 R_X86_64_64 0040 init + 0
< 0010 00060001 R_X86_64_64 0020 init_65535 + 0
---


 00060001 R_X86_64_64 0011 init_65535 + 0
0008 00070001 R_X86_64_64 0022 init + 0
0010 00080001 R_X86_64_64 0033 init_65535_2 + 0
```


The above show clearly gcc produces the wrong order of section `.rela.ctors`.

Is that expected behavior ?

I have not tried Linux version of gcc.


Note that init array vs. init function behavior is encoded by a note added
by crt1.o. I suspect that the problem is that gcc port is built without
--enable-initfini-array configure option.


Indeed, support for .init_array and .fini_array has been added to the GCC ports
but is present in the *-devel ports only for now. I will
soon proceed to enable it for the GCC standard ports too. lang/gcc14 is soon
to be added to the ports tree and will have it since the beginning.

If this is indeed the issue, switching to a -devel GCC port should fix it.


FWIW, the devel/freebsd-gcc* ports have passed this flag to GCC's configure
for a long time (since we made the switch in clang).

--
John Baldwin

Re: bridge: no traffic with vnet (epair) beyond bridge device

[FreeBSD User]

Am Tue, 04 Jun 2024 09:36:38 +0200
Alexander Leidinger  schrieb:

> Am 2024-06-03 21:02, schrieb FreeBSD User:
> > Hello,
> > 
> > I'm running a dual socket NUMA CURRENT host (Fujitsu RX host) running 
> > several jails. Jails are
> > attached to a bridge device (bridge1), the physical device on that 
> > bridge is igb1 (i350 based
> > NIC). The bridge is created via host's rc scripts, adding and/or 
> > deleting epair members of the
> > bridge is performed by the jail.conf script.
> > 
> > I do not know how long the setup worked, but out of the blue, last week 
> > after a longish
> > poudriere run after updating the host to most recent CURRENT (as of 
> > today, latest update
> > kernel and world) and performing "etcupdate" on both the host and all 
> > jails, traffic beyond
> > the bridge is not seen on the network! All jails can communicate with 
> > each other. Traffic from
> > the host itself is routed via igb0 to network and back via igb1 onto 
> > the bridge.
> > 
> > I check all setups for net.link.bridge:
> > 
> > net.link.bridge.ipfw: 0
> > net.link.bridge.log_mac_flap: 1
> > net.link.bridge.allow_llz_overlap: 0
> > net.link.bridge.inherit_mac: 0
> > net.link.bridge.log_stp: 0
> > net.link.bridge.pfil_local_phys: 0
> > net.link.bridge.pfil_member: 0
> > net.link.bridge.ipfw_arp: 0
> > net.link.bridge.pfil_bridge: 0
> > net.link.bridge.pfil_onlyip: 0
> > 
> > I did not change anything (knowingly).
> > 
> > I also have an oldish box running single socket processor, also driven 
> > by the very same
> > CURRENT and similar, but not identical setup. The box is running very 
> > well and the bridge is
> > working as expected.
> > 
> > I was wondering if something in detail has changed in the handling of 
> > jails, epair and
> > bridges. I followed the setup "after the book", nothing suspicious.  
> 
> "after the book" = the IP of the host itself is not on igb1 but on a 
> different interface or on the bridge?
> 
> Is there a firewall active on the box itself? Which one?
> 
> What does wireshark / a traffic dump at the physical interface level 
> tell compared to a traffic dump at the switch interface? Did you replace 
> the cable / SFP / move to a different switch port as a test?
> 
> I suggest to provide the output of ifconfig -a and netstat -rn (feel 
> free to mangle the IPs, as long as the mangling is a consistent 
> replacement and not a cut-off).
> 
> Bye,
> Alexander.
> 

Hello Alexander and everybody brave enough reading my post.

Somehow I managed it to let 

"ifconfig_igb1="up"

disappear - I guess by accident when sneaking through the rc.conf file.

igb1 is the physical device connecting to the network. The bridge is layer 2 
only, no IP, only
the vnet-portions pointing towards the jail do have IPv6 and IPv4. The bridge 
has around 20
members, the last entry is igb1 - I never checked whether it is up ...
Sorry!

Kind regards,

oh

-- 
O. Hartmann


pgpEjETT1Jdg5.pgp
Description: OpenPGP digital signature

Re: [Bug 269133] bnxt(4): BCM57416 - HWRM_CFA_L2_SET_RX_MASK command returned RESOURCE_ALLOC_ERROR error

[Warner Losh]

On Tue, Jun 4, 2024 at 8:17 AM Gerrit Kühn  wrote:

> Am Tue, 28 May 2024 11:19:42 +0200
> schrieb Gerrit Kühn :
>
> > > Not sure if it will break your setup, but this already happened with
> > > 13.2 (I cant recall the exact release).
>
> > I have two machines with onboard NICs (Supermicro H12SSL-CT mainboards)
> > running just fine. One is 13.3, the other is 14.0.
>
> I have updated one system to 14.1 now, and it still works happily
> (transferring lots of data in the background while typing this). So
> whatever causes the issues you have seen with the BCM chipset, not all of
> them appear to be affected. Maybe the firmware is making the difference
> here?
>

I merged the next version of the driver from Broadcom to stable/14, but not
14.1 (it
was too late by the time I got around to this). If there's still issues,
maybe try stable/14?

Warner


> cu
>   Gerrit
>

Re: [Bug 269133] bnxt(4): BCM57416 - HWRM_CFA_L2_SET_RX_MASK command returned RESOURCE_ALLOC_ERROR error

[Gerrit Kühn]

Am Tue, 28 May 2024 11:19:42 +0200
schrieb Gerrit Kühn :

> > Not sure if it will break your setup, but this already happened with 
> > 13.2 (I cant recall the exact release).  

> I have two machines with onboard NICs (Supermicro H12SSL-CT mainboards)
> running just fine. One is 13.3, the other is 14.0.

I have updated one system to 14.1 now, and it still works happily
(transferring lots of data in the background while typing this). So
whatever causes the issues you have seen with the BCM chipset, not all of
them appear to be affected. Maybe the firmware is making the difference
here?


cu
  Gerrit


smime.p7s
Description: S/MIME cryptographic signature

Re: [Bug 269133] bnxt(4): BCM57416 - HWRM_CFA_L2_SET_RX_MASK command returned RESOURCE_ALLOC_ERROR error

[Santiago Martinez]

Hi everyone, just to follow up.

I have found something interesting, at the moment I'm focusing on the 
issue related to the creation and deletion of sub-interfaces that 
trigger ALLOC/MASK errors and bricks the NIC ( not completely as the 
other port keeps working, this card has 2x10G).


I have found the following:

- If a port is down (let's say bnxt1) and sub-interfaces are created ( 
bnxt1.1100) then the port is activated (ifconfig bnxt1 up). this will 
trigger the issues of the filters and the card will not be able to be  
"programmed" again until the next reboot (not sure if there is any way 
to reset it, the devctl reset did not work).


echo "Creating Interfaces and brick the card"

ifconfig bnxt1.1011 create up fib 10 192.168.11.43/24
ifconfig bnxt1.1001 create up fib 11 192.168.12.43/24
ifconfig bnxt1.1002 create up fib 12 192.168.13.43/24
ifconfig bnxt1.1003 create up fib 13 192.168.14.43/24
ifconfig bnxt1.1004 create up fib 14 192.168.15.43/24
ifconfig bnxt1.1005 create up fib 15 192.168.16.43/24
ifconfig bnxt1 up --- ( at this point is bricked) ---

--- then destroy and shutdown bnxt1 ---

- If I do the same, but just make sure that the port is "admin up" 
before creating and deleting the sub-interfaces, everything works like 
charm. No errors are seen.


echo "Creating Interfaces and bricks the card"
ifconfig bnxt1 up
ifconfig bnxt1.1011 create up fib 10 192.168.11.43/24
ifconfig bnxt1.1001 create up fib 11 192.168.12.43/24
ifconfig bnxt1.1002 create up fib 12 192.168.13.43/24
ifconfig bnxt1.1003 create up fib 13 192.168.14.43/24
ifconfig bnxt1.1004 create up fib 14 192.168.15.43/24
ifconfig bnxt1.1005 create up fib 15 192.168.16.43/24
--- then destroy and shutdown bnxt1 ---

This is tested against main from yesterday.

Best regards.

Santi


On 5/28/24 11:30, Gerrit Kühn wrote:

Am Tue, 28 May 2024 11:25:09 +0200
schrieb Santiago Martinez :


*"The latest I have is 214.0.286.18"*
Indeed, the firmware on my box is older, I cannot upgrade it right now,
but it is on my to-do list.

Same here, I guess (pkgver). It says
dev.bnxt.0.ver.fw_ver: 214.4.9.10/pkg 214.0.286.18
on both systems.

Also, I don't think I can upgrade the firmware separately, it comes with
the mainboard's bios (which is the latest available).


cu
   Gerrit

Re: bridge: no traffic with vnet (epair) beyond bridge device

[Alexander Leidinger]

Am 2024-06-03 21:02, schrieb FreeBSD User:

Hello,

I'm running a dual socket NUMA CURRENT host (Fujitsu RX host) running 
several jails. Jails are
attached to a bridge device (bridge1), the physical device on that 
bridge is igb1 (i350 based
NIC). The bridge is created via host's rc scripts, adding and/or 
deleting epair members of the

bridge is performed by the jail.conf script.

I do not know how long the setup worked, but out of the blue, last week 
after a longish
poudriere run after updating the host to most recent CURRENT (as of 
today, latest update
kernel and world) and performing "etcupdate" on both the host and all 
jails, traffic beyond
the bridge is not seen on the network! All jails can communicate with 
each other. Traffic from
the host itself is routed via igb0 to network and back via igb1 onto 
the bridge.


I check all setups for net.link.bridge:

net.link.bridge.ipfw: 0
net.link.bridge.log_mac_flap: 1
net.link.bridge.allow_llz_overlap: 0
net.link.bridge.inherit_mac: 0
net.link.bridge.log_stp: 0
net.link.bridge.pfil_local_phys: 0
net.link.bridge.pfil_member: 0
net.link.bridge.ipfw_arp: 0
net.link.bridge.pfil_bridge: 0
net.link.bridge.pfil_onlyip: 0

I did not change anything (knowingly).

I also have an oldish box running single socket processor, also driven 
by the very same
CURRENT and similar, but not identical setup. The box is running very 
well and the bridge is

working as expected.

I was wondering if something in detail has changed in the handling of 
jails, epair and

bridges. I followed the setup "after the book", nothing suspicious.


"after the book" = the IP of the host itself is not on igb1 but on a 
different interface or on the bridge?


Is there a firewall active on the box itself? Which one?

What does wireshark / a traffic dump at the physical interface level 
tell compared to a traffic dump at the switch interface? Did you replace 
the cable / SFP / move to a different switch port as a test?


I suggest to provide the output of ifconfig -a and netstat -rn (feel 
free to mangle the IPs, as long as the mangling is a consistent 
replacement and not a cut-off).


Bye,
Alexander.

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


signature.asc
Description: OpenPGP digital signature

Re: bridge: no traffic with vnet (epair) beyond bridge device

[Zhenlei Huang]

> On Jun 4, 2024, at 3:02 AM, FreeBSD User  wrote:
> 
> Hello,
> 
> I'm running a dual socket NUMA CURRENT host (Fujitsu RX host) running several 
> jails. Jails are
> attached to a bridge device (bridge1), the physical device on that bridge is 
> igb1 (i350 based
> NIC). The bridge is created via host's rc scripts, adding and/or deleting 
> epair members of the
> bridge is performed by the jail.conf script.
> 
> I do not know how long the setup worked, but out of the blue, last week after 
> a longish
> poudriere run after updating the host to most recent CURRENT (as of today, 
> latest update
> kernel and world) and performing "etcupdate" on both the host and all jails, 
> traffic beyond
> the bridge is not seen on the network! All jails can communicate with each 
> other. Traffic from
> the host itself is routed via igb0 to network and back via igb1 onto the 
> bridge.

Can you elaborate your setup of network. I'm getting confused by the last 
sentence.

Is it ( the network for jails ) a bridged one or routed one ?

> 
> I check all setups for net.link.bridge:
> 
> net.link.bridge.ipfw: 0
> net.link.bridge.log_mac_flap: 1
> net.link.bridge.allow_llz_overlap: 0
> net.link.bridge.inherit_mac: 0
> net.link.bridge.log_stp: 0
> net.link.bridge.pfil_local_phys: 0
> net.link.bridge.pfil_member: 0
> net.link.bridge.ipfw_arp: 0
> net.link.bridge.pfil_bridge: 0
> net.link.bridge.pfil_onlyip: 0
> 
> I did not change anything (knowingly). 
> 
> I also have an oldish box running single socket processor, also driven by the 
> very same
> CURRENT and similar, but not identical setup. The box is running very well 
> and the bridge is
> working as expected.
> 
> I was wondering if something in detail has changed in the handling of jails, 
> epair and
> bridges. I followed the setup "after the book", nothing suspicious.

No functional changes to if_bridge / if_epair / jail since the beginning of 
this year as far as I known.

> 
> Maybe someone has a clue what might break the bridge.
> 
> By the way: ifconfig bridge1 looks as always, igb1 as member and it doesn't 
> make any
> difference whether I force the bridge to inherit igb1's MAC or not.
> 
> We also checked for the switches whether BPDU Guard may have been triggered, 
> but everything
> looks good from the outside - execept the fact the brdiged interface seems 
> inactive (but up)
> from the outside ...
> 
> Kind regards
> 
> oh
> 
> -- 
> O. Hartmann
> 

Best regards,
Zhenlei

bridge: no traffic with vnet (epair) beyond bridge device

[FreeBSD User]

Hello,

I'm running a dual socket NUMA CURRENT host (Fujitsu RX host) running several 
jails. Jails are
attached to a bridge device (bridge1), the physical device on that bridge is 
igb1 (i350 based
NIC). The bridge is created via host's rc scripts, adding and/or deleting epair 
members of the
bridge is performed by the jail.conf script.

I do not know how long the setup worked, but out of the blue, last week after a 
longish
poudriere run after updating the host to most recent CURRENT (as of today, 
latest update
kernel and world) and performing "etcupdate" on both the host and all jails, 
traffic beyond
the bridge is not seen on the network! All jails can communicate with each 
other. Traffic from
the host itself is routed via igb0 to network and back via igb1 onto the bridge.

I check all setups for net.link.bridge:

net.link.bridge.ipfw: 0
net.link.bridge.log_mac_flap: 1
net.link.bridge.allow_llz_overlap: 0
net.link.bridge.inherit_mac: 0
net.link.bridge.log_stp: 0
net.link.bridge.pfil_local_phys: 0
net.link.bridge.pfil_member: 0
net.link.bridge.ipfw_arp: 0
net.link.bridge.pfil_bridge: 0
net.link.bridge.pfil_onlyip: 0

I did not change anything (knowingly). 

I also have an oldish box running single socket processor, also driven by the 
very same
CURRENT and similar, but not identical setup. The box is running very well and 
the bridge is
working as expected.

I was wondering if something in detail has changed in the handling of jails, 
epair and
bridges. I followed the setup "after the book", nothing suspicious.

Maybe someone has a clue what might break the bridge.

By the way: ifconfig bridge1 looks as always, igb1 as member and it doesn't 
make any
difference whether I force the bridge to inherit igb1's MAC or not.

We also checked for the switches whether BPDU Guard may have been triggered, 
but everything
looks good from the outside - execept the fact the brdiged interface seems 
inactive (but up)
from the outside ...

Kind regards

oh

-- 
O. Hartmann

Call for 2024Q2 status reports

[Lorenzo Salvadore]

Dear FreeBSD Community,

The deadline for the next FreeBSD Status Report update is
June, 30th 2024 for work done since the last round of quarterly reports:
April 2024 - June 2024.
I would like to remind you that reports are published on a quarterly
basis and are usually collected during the last month of each quarter,
You are also welcome to submit them even earlier if you want, and the
earlier you submit them, the more time we have for reviewing.

Status report submissions do not need to be very long. They may be
about anything happening in the FreeBSD project and community, and
they provide a great way to inform FreeBSD users and developers about
work that is underway or has been completed. Report submissions are
not limited to committers; anyone doing anything interesting and
FreeBSD related can -- and should -- write one!

The following methods are available to submit your reports:

* submit a review on Phabricator and add the group "status" to the
  reviewers list. You should put your reports in the directory
  doc/website/content/en/status/report-2024-04-2024-06/
  (create it if it is missing);

* submit a pull request at .
  You should put your reports in the directory
  doc/website/content/en/status/report-2024-04-2024-06/
  (create it if it is missing);

* send an email to status-submissi...@freebsd.org including your report.

An AsciiDoc template is available at
.

We look forward to seeing your 2024Q2 reports!

Thanks,

Lorenzo Salvadore (on behalf of status@)

Re: mesa-dri-24.0.8 failing to build on d1bd097d52cb

[Cy Schubert]

I pushed commits to fix this, the wpa_supplicant*, and hostapd* ports last 
night.


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

e^(i*pi)+1=0


In message 
, Nuno Teixeira writes:
>
> (...)
>
> commit 108de784513d87bbe850e7b003a73e26b5b54caa
> Author: Val Packett 
> Date:   Fri May 31 08:45:02 2024 -0600
>
> Redefine CLOCK_BOOTTIME to alias CLOCK_MONOTONIC, not CLOCK_UPTIME
>
> Nuno Teixeira  escreveu (s=C3=A1bado, 1/06/2024 =C3=A0=
> (s) 09:01):
>
> > Hello all,
> >
> > Anyone seeing this error on main?
> >
> > Thanks
> >
> > [ 28% 661/2246] cc -Isrc/intel/common/libintel_common.a.p
> > -Isrc/intel/common -I../src/intel/common -Iinclude -I../include -Isrc
> > -I../src -Isrc/intel -I../src/intel -Isrc/intel/genxml -Isrc/intel/dev
> > -I/usr/local/
> > include -I/usr/local/include/libdrm -fvisibility=3Dhidden
> > -fdiagnostics-color=3Dnever -DNDEBUG -D_FILE_OFFSET_BITS=3D64 -Wall
> > -Winvalid-pch -std=3Dc11 -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
> > -D__STDC_LIMIT_MACROS
> >  '-DPACKAGE_VERSION=3D"24.0.8"' '-DPACKAGE_BUGREPORT=3D"
> > https://gitlab.freedesktop.org/mesa/mesa/-/issues;' -DHAVE_OPENGL=3D1
> > -DHAVE_OPENGL_ES_1=3D1 -DHAVE_OPENGL_ES_2=3D1 -DHAVE_SWRAST -DHAVE_ZINK
> > -DHAVE_R300 -DHAVE_R600
> > -DHAVE_RADEONSI -DHAVE_CROCUS -DHAVE_I915 -DHAVE_IRIS -DHAVE_SVGA
> > -DUSE_VK_COMPILER=3D1 -DVIDEO_CODEC_VC1DEC=3D1 -DVIDEO_CODEC_H264DEC=3D1
> > -DVIDEO_CODEC_H264ENC=3D1 -DVIDEO_CODEC_H265DEC=3D1 -DVIDEO_CODEC_H265ENC=
> =3D1
> > -DVIDEO
> > _CODEC_AV1DEC=3D1 -DVIDEO_CODEC_AV1ENC=3D1 -DVIDEO_CODEC_VP9DEC=3D1
> > -DHAVE_X11_PLATFORM -DHAVE_WAYLAND_PLATFORM -DHAVE_SURFACELESS_PLATFORM
> > -DHAVE_DRM_PLATFORM -DHAVE_XCB_PLATFORM -DENABLE_ST_OMX_BELLAGIO=3D0
> > -DENABLE_ST
> > _OMX_TIZONIA=3D0 -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING
> > -DGLX_USE_DRM -DGLAPI_EXPORT_PROTO_ENTRY_POINTS=3D0 -DALLOW_KCMP
> > -DETIME=3DETIMEDOUT -DENABLE_SHADER_CACHE -DHAVE___BUILTIN_BSWAP32
> > -DHAVE___BUILTIN_BSWA
> > P64 -DHAVE___BUILTIN_CLZ -DHAVE___BUILTIN_CLZLL -DHAVE___BUILTIN_CTZ
> > -DHAVE___BUILTIN_EXPECT -DHAVE___BUILTIN_FFS -DHAVE___BUILTIN_FFSLL
> > -DHAVE___BUILTIN_POPCOUNT -DHAVE___BUILTIN_POPCOUNTLL -DHAVE___BUILTIN_UN=
> RE
> > ACHABLE -DHAVE___BUILTIN_TYPES_COMPATIBLE_P -DHAVE_FUNC_ATTRIBUTE_CONST
> > -DHAVE_FUNC_ATTRIBUTE_FLATTEN -DHAVE_FUNC_ATTRIBUTE_MALLOC
> > -DHAVE_FUNC_ATTRIBUTE_PURE -DHAVE_FUNC_ATTRIBUTE_UNUSED
> > -DHAVE_FUNC_ATTRIBUTE_WAR
> > N_UNUSED_RESULT -DHAVE_FUNC_ATTRIBUTE_WEAK -DHAVE_FUNC_ATTRIBUTE_FORMAT
> > -DHAVE_FUNC_ATTRIBUTE_PACKED -DHAVE_FUNC_ATTRIBUTE_RETURNS_NONNULL
> > -DHAVE_FUNC_ATTRIBUTE_ALIAS -DHAVE_FUNC_ATTRIBUTE_NORETURN -DHAVE_FUNC_AT
> > TRIBUTE_VISIBILITY -DHAVE_UINT128 -DHAVE_REALLOCARRAY -DHAVE_FMEMOPEN
> > -D_GNU_SOURCE -DUSE_SSE41 -DHAVE___BUILTIN_IA32_CLFLUSHOPT
> > -DUSE_GCC_ATOMIC_BUILTINS -DUSE_X86_64_ASM -DHAS_SCHED_H
> > -DHAS_SCHED_GETAFFINITY -D
> > HAVE_SYS_SYSCTL_H -DHAVE_XLOCALE_H -DHAVE_ENDIAN_H -DHAVE_DLFCN_H
> > -DHAVE_SYS_SHM_H -DHAVE_CET_H -DHAVE_PTHREAD_NP_H -DHAVE_STRTOF
> > -DHAVE_MKOSTEMP -DHAVE_MEMFD_CREATE -DHAVE_FLOCK -DHAVE_STRTOK_R
> > -DHAVE_GETRANDOM
> > -DHAVE_QSORT_S -DHAVE_POSIX_FALLOCATE -DHAVE_SECURE_GETENV
> > -DHAVE_GNU_QSORT_R -DHAVE_STRUCT_TIMESPEC -DHAVE_POSIX_MEMALIGN
> > -DHAVE_DIRENT_D_TYPE -DHAVE_STRTOD_L -DHAVE_DLADDR -DHAVE_DL_ITERATE_PHDR
> > -DSUPPORT_INTEL
> > _INTEGRATED_GPUS -DHAVE_ZLIB -DHAVE_ZSTD -DHAVE_COMPRESSION -DHAVE_PTHREA=
> D
> > -DHAVE_LIBDRM '-DMESA_LLVM_VERSION_STRING=3D"15.0.7"' -DLLVM_IS_SHARED=3D=
> 1
> > -DLLVM_AVAILABLE=3D1 -DDRAW_LLVM_AVAILABLE=3D1 -DUSE_LIBELF -DWL_HIDE_
> > DEPRECATED -DHAVE_DRI -DHAVE_DRI2 -DHAVE_DRI3 -DHAVE_DRI3_MODIFIERS
> > -DHAVE_DRISW_KMS -Werror=3Dimplicit-function-declaration
> > -Werror=3Dmissing-prototypes -Werror=3Dreturn-type -Werror=3Dempty-body
> > -Werror=3Dincompatible-po
> > inter-types -Werror=3Dint-conversion -Wimplicit-fallthrough
> > -Wmisleading-indentation -Wno-missing-field-initializers
> > -Wno-format-truncation -fno-math-errno -fno-trapping-math
> > -Qunused-arguments -fno-common -Wno-unk
> > nown-pragmas -Wno-microsoft-enum-value -Wno-unused-function -Werror=3Dfor=
> mat
> > -Wformat-security -ffunction-sections -fdata-sections -Wno-unused-variabl=
> e
> > -Wno-unused-but-set-variable -O2 -pipe -fstack-protector-stron
> > g -fno-strict-aliasing -fPIC -pthread -Wno-override-init
> > -Wno-initializer-overrides -MD -MQ
> > src/intel/common/libintel_common.a.p/xe_intel_gem.c.o -MF
> > src/intel/common/libintel_common.a.p/xe_intel_gem.c.o.d -o src
> > /intel/common/libintel_common.a.p/xe_intel_gem.c.o -c
> > ../src/intel/common/xe/intel_gem.c
> > FAILED: src/intel/common/libintel_common.a.p/xe_intel_gem.c.o
> > cc -Isrc/intel/common/libintel_common.a.p -Isrc/intel/common
> > -I../src/intel/common -Iinclude -I../include -Isrc -I../src -Isrc/intel
> > -I../src/intel -Isrc/intel/genxml -Isrc/intel/dev -I/usr/local/include
> > -I/usr/l
> > 

Re: mesa-dri-24.0.8 failing to build on d1bd097d52cb

[Cy Schubert]

On June 1, 2024 1:35:29 AM PDT, Nuno Teixeira  wrote:
>(...)
>
>commit 108de784513d87bbe850e7b003a73e26b5b54caa
>Author: Val Packett 
>Date:   Fri May 31 08:45:02 2024 -0600
>
>Redefine CLOCK_BOOTTIME to alias CLOCK_MONOTONIC, not CLOCK_UPTIME
>
>Nuno Teixeira  escreveu (sábado, 1/06/2024 à(s) 09:01):
>
>> Hello all,
>>
>> Anyone seeing this error on main?
>>
>> Thanks
>>
>> [ 28% 661/2246] cc -Isrc/intel/common/libintel_common.a.p
>> -Isrc/intel/common -I../src/intel/common -Iinclude -I../include -Isrc
>> -I../src -Isrc/intel -I../src/intel -Isrc/intel/genxml -Isrc/intel/dev
>> -I/usr/local/
>> include -I/usr/local/include/libdrm -fvisibility=hidden
>> -fdiagnostics-color=never -DNDEBUG -D_FILE_OFFSET_BITS=64 -Wall
>> -Winvalid-pch -std=c11 -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
>> -D__STDC_LIMIT_MACROS
>>  '-DPACKAGE_VERSION="24.0.8"' '-DPACKAGE_BUGREPORT="
>> https://gitlab.freedesktop.org/mesa/mesa/-/issues;' -DHAVE_OPENGL=1
>> -DHAVE_OPENGL_ES_1=1 -DHAVE_OPENGL_ES_2=1 -DHAVE_SWRAST -DHAVE_ZINK
>> -DHAVE_R300 -DHAVE_R600
>> -DHAVE_RADEONSI -DHAVE_CROCUS -DHAVE_I915 -DHAVE_IRIS -DHAVE_SVGA
>> -DUSE_VK_COMPILER=1 -DVIDEO_CODEC_VC1DEC=1 -DVIDEO_CODEC_H264DEC=1
>> -DVIDEO_CODEC_H264ENC=1 -DVIDEO_CODEC_H265DEC=1 -DVIDEO_CODEC_H265ENC=1
>> -DVIDEO
>> _CODEC_AV1DEC=1 -DVIDEO_CODEC_AV1ENC=1 -DVIDEO_CODEC_VP9DEC=1
>> -DHAVE_X11_PLATFORM -DHAVE_WAYLAND_PLATFORM -DHAVE_SURFACELESS_PLATFORM
>> -DHAVE_DRM_PLATFORM -DHAVE_XCB_PLATFORM -DENABLE_ST_OMX_BELLAGIO=0
>> -DENABLE_ST
>> _OMX_TIZONIA=0 -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING
>> -DGLX_USE_DRM -DGLAPI_EXPORT_PROTO_ENTRY_POINTS=0 -DALLOW_KCMP
>> -DETIME=ETIMEDOUT -DENABLE_SHADER_CACHE -DHAVE___BUILTIN_BSWAP32
>> -DHAVE___BUILTIN_BSWA
>> P64 -DHAVE___BUILTIN_CLZ -DHAVE___BUILTIN_CLZLL -DHAVE___BUILTIN_CTZ
>> -DHAVE___BUILTIN_EXPECT -DHAVE___BUILTIN_FFS -DHAVE___BUILTIN_FFSLL
>> -DHAVE___BUILTIN_POPCOUNT -DHAVE___BUILTIN_POPCOUNTLL -DHAVE___BUILTIN_UNRE
>> ACHABLE -DHAVE___BUILTIN_TYPES_COMPATIBLE_P -DHAVE_FUNC_ATTRIBUTE_CONST
>> -DHAVE_FUNC_ATTRIBUTE_FLATTEN -DHAVE_FUNC_ATTRIBUTE_MALLOC
>> -DHAVE_FUNC_ATTRIBUTE_PURE -DHAVE_FUNC_ATTRIBUTE_UNUSED
>> -DHAVE_FUNC_ATTRIBUTE_WAR
>> N_UNUSED_RESULT -DHAVE_FUNC_ATTRIBUTE_WEAK -DHAVE_FUNC_ATTRIBUTE_FORMAT
>> -DHAVE_FUNC_ATTRIBUTE_PACKED -DHAVE_FUNC_ATTRIBUTE_RETURNS_NONNULL
>> -DHAVE_FUNC_ATTRIBUTE_ALIAS -DHAVE_FUNC_ATTRIBUTE_NORETURN -DHAVE_FUNC_AT
>> TRIBUTE_VISIBILITY -DHAVE_UINT128 -DHAVE_REALLOCARRAY -DHAVE_FMEMOPEN
>> -D_GNU_SOURCE -DUSE_SSE41 -DHAVE___BUILTIN_IA32_CLFLUSHOPT
>> -DUSE_GCC_ATOMIC_BUILTINS -DUSE_X86_64_ASM -DHAS_SCHED_H
>> -DHAS_SCHED_GETAFFINITY -D
>> HAVE_SYS_SYSCTL_H -DHAVE_XLOCALE_H -DHAVE_ENDIAN_H -DHAVE_DLFCN_H
>> -DHAVE_SYS_SHM_H -DHAVE_CET_H -DHAVE_PTHREAD_NP_H -DHAVE_STRTOF
>> -DHAVE_MKOSTEMP -DHAVE_MEMFD_CREATE -DHAVE_FLOCK -DHAVE_STRTOK_R
>> -DHAVE_GETRANDOM
>> -DHAVE_QSORT_S -DHAVE_POSIX_FALLOCATE -DHAVE_SECURE_GETENV
>> -DHAVE_GNU_QSORT_R -DHAVE_STRUCT_TIMESPEC -DHAVE_POSIX_MEMALIGN
>> -DHAVE_DIRENT_D_TYPE -DHAVE_STRTOD_L -DHAVE_DLADDR -DHAVE_DL_ITERATE_PHDR
>> -DSUPPORT_INTEL
>> _INTEGRATED_GPUS -DHAVE_ZLIB -DHAVE_ZSTD -DHAVE_COMPRESSION -DHAVE_PTHREAD
>> -DHAVE_LIBDRM '-DMESA_LLVM_VERSION_STRING="15.0.7"' -DLLVM_IS_SHARED=1
>> -DLLVM_AVAILABLE=1 -DDRAW_LLVM_AVAILABLE=1 -DUSE_LIBELF -DWL_HIDE_
>> DEPRECATED -DHAVE_DRI -DHAVE_DRI2 -DHAVE_DRI3 -DHAVE_DRI3_MODIFIERS
>> -DHAVE_DRISW_KMS -Werror=implicit-function-declaration
>> -Werror=missing-prototypes -Werror=return-type -Werror=empty-body
>> -Werror=incompatible-po
>> inter-types -Werror=int-conversion -Wimplicit-fallthrough
>> -Wmisleading-indentation -Wno-missing-field-initializers
>> -Wno-format-truncation -fno-math-errno -fno-trapping-math
>> -Qunused-arguments -fno-common -Wno-unk
>> nown-pragmas -Wno-microsoft-enum-value -Wno-unused-function -Werror=format
>> -Wformat-security -ffunction-sections -fdata-sections -Wno-unused-variable
>> -Wno-unused-but-set-variable -O2 -pipe -fstack-protector-stron
>> g -fno-strict-aliasing -fPIC -pthread -Wno-override-init
>> -Wno-initializer-overrides -MD -MQ
>> src/intel/common/libintel_common.a.p/xe_intel_gem.c.o -MF
>> src/intel/common/libintel_common.a.p/xe_intel_gem.c.o.d -o src
>> /intel/common/libintel_common.a.p/xe_intel_gem.c.o -c
>> ../src/intel/common/xe/intel_gem.c
>> FAILED: src/intel/common/libintel_common.a.p/xe_intel_gem.c.o
>> cc -Isrc/intel/common/libintel_common.a.p -Isrc/intel/common
>> -I../src/intel/common -Iinclude -I../include -Isrc -I../src -Isrc/intel
>> -I../src/intel -Isrc/intel/genxml -Isrc/intel/dev -I/usr/local/include
>> -I/usr/l
>> ocal/include/libdrm -fvisibility=hidden -fdiagnostics-color=never -DNDEBUG
>> -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=c11
>> -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
>> '-DPACKAGE_VERS
>> ION="24.0.8"' '-DPACKAGE_BUGREPORT="
>> https://gitlab.freedesktop.org/mesa/mesa/-/issues;' -DHAVE_OPENGL=1
>> -DHAVE_OPENGL_ES_1=1 -DHAVE_OPENGL_ES_2=1 -DHAVE_SWRAST -DHAVE_ZINK
>> -DHAVE_R300 

Re: May 2024 stabilization week

[void]

On Sat, Jun 01, 2024 at 03:13:23PM -0400, Mike Karels wrote:

Sorry, this is a different instance of the problem that pkg had with
its scripts.  This is fallout from removal of security_daily_compat_var.
The 900.tcpwrap script was modified for this in April.  Did you run
etcupdate?


yes - etcupdate -p after make installkernel and etcupdate -B after
make installworld; then make check-old then yes | make delete-old
then yes | make delete-old-libs then reboot.

Might be relevant:

1. arm64.aarch64
2. ufs only & MBR
3. ISTR the canonical way of source upgrading involves a reboot 
   after etcupdate -p to boot into the new kernel and then do the

   installworld. i didn't do that.
--

Re: May 2024 stabilization week

[Mike Karels]

On 1 Jun 2024, at 14:00, void wrote:

> Hi Mike,
>
> On Sat, Jun 01, 2024 at 08:06:53AM -0400, Mike Karels wrote:
>> On 30 May 2024, at 8:31, void wrote:
>>
>>> On Mon, May 27, 2024 at 09:24:14PM -0700, Gleb Smirnoff wrote:
>>>
 Replying to this email thread with your success reports as well
 as reporting any regressions is very much appreciated. Thanks!
>>>
>>> This is new. In the daily security run output (arm64.aarch64):
>>>
>>> /etc/periodic/security/900.tcpwrap: security_daily_compat_var: not found
>>> /etc/periodic/security/900.tcpwrap: security_daily_compat_var: not found
>>>--
>>
>> There is a new version of pkg that corrects this.
>
> Unsure what you mean - how would pkg be involved?
>
> pkg is: pkg-1.21.3 - isn't this the latest?
>
> The issue occured after a source build of cca0ce62f367
> --

Sorry, this is a different instance of the problem that pkg had with
its scripts.  This is fallout from removal of security_daily_compat_var.
The 900.tcpwrap script was modified for this in April.  Did you run
etcupdate?

Mike

Re: May 2024 stabilization week

[void]

Hi Mike,

On Sat, Jun 01, 2024 at 08:06:53AM -0400, Mike Karels wrote:

On 30 May 2024, at 8:31, void wrote:


On Mon, May 27, 2024 at 09:24:14PM -0700, Gleb Smirnoff wrote:


Replying to this email thread with your success reports as well
as reporting any regressions is very much appreciated. Thanks!


This is new. In the daily security run output (arm64.aarch64):

/etc/periodic/security/900.tcpwrap: security_daily_compat_var: not found
/etc/periodic/security/900.tcpwrap: security_daily_compat_var: not found
   --


There is a new version of pkg that corrects this.


Unsure what you mean - how would pkg be involved?

pkg is: pkg-1.21.3 - isn't this the latest?

The issue occured after a source build of cca0ce62f367
--

Re: May 2024 stabilization week

[Service Aktionheizung]

Thank you for the information. The correct e -mail address is

i...@aktionheizung.de

Submit information exclusively to this E -Mail address. Thanks


-

Am 01.06.2024 um 14:06 schrieb Mike Karels:

On 30 May 2024, at 8:31, void wrote:


On Mon, May 27, 2024 at 09:24:14PM -0700, Gleb Smirnoff wrote:


Replying to this email thread with your success reports as well
as reporting any regressions is very much appreciated. Thanks!

This is new. In the daily security run output (arm64.aarch64):

/etc/periodic/security/900.tcpwrap: security_daily_compat_var: not found
/etc/periodic/security/900.tcpwrap: security_daily_compat_var: not found
   --

There is a new version of pkg that corrects this.

Mike

Re: May 2024 stabilization week

[Mike Karels]

On 30 May 2024, at 8:31, void wrote:

> On Mon, May 27, 2024 at 09:24:14PM -0700, Gleb Smirnoff wrote:
>
>> Replying to this email thread with your success reports as well
>> as reporting any regressions is very much appreciated. Thanks!
>
> This is new. In the daily security run output (arm64.aarch64):
>
> /etc/periodic/security/900.tcpwrap: security_daily_compat_var: not found
> /etc/periodic/security/900.tcpwrap: security_daily_compat_var: not found  
>  --

There is a new version of pkg that corrects this.

Mike

Re: mesa-dri-24.0.8 failing to build on d1bd097d52cb

[Nuno Teixeira]

(...)

commit 108de784513d87bbe850e7b003a73e26b5b54caa
Author: Val Packett 
Date:   Fri May 31 08:45:02 2024 -0600

Redefine CLOCK_BOOTTIME to alias CLOCK_MONOTONIC, not CLOCK_UPTIME

Nuno Teixeira  escreveu (sábado, 1/06/2024 à(s) 09:01):

> Hello all,
>
> Anyone seeing this error on main?
>
> Thanks
>
> [ 28% 661/2246] cc -Isrc/intel/common/libintel_common.a.p
> -Isrc/intel/common -I../src/intel/common -Iinclude -I../include -Isrc
> -I../src -Isrc/intel -I../src/intel -Isrc/intel/genxml -Isrc/intel/dev
> -I/usr/local/
> include -I/usr/local/include/libdrm -fvisibility=hidden
> -fdiagnostics-color=never -DNDEBUG -D_FILE_OFFSET_BITS=64 -Wall
> -Winvalid-pch -std=c11 -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
> -D__STDC_LIMIT_MACROS
>  '-DPACKAGE_VERSION="24.0.8"' '-DPACKAGE_BUGREPORT="
> https://gitlab.freedesktop.org/mesa/mesa/-/issues;' -DHAVE_OPENGL=1
> -DHAVE_OPENGL_ES_1=1 -DHAVE_OPENGL_ES_2=1 -DHAVE_SWRAST -DHAVE_ZINK
> -DHAVE_R300 -DHAVE_R600
> -DHAVE_RADEONSI -DHAVE_CROCUS -DHAVE_I915 -DHAVE_IRIS -DHAVE_SVGA
> -DUSE_VK_COMPILER=1 -DVIDEO_CODEC_VC1DEC=1 -DVIDEO_CODEC_H264DEC=1
> -DVIDEO_CODEC_H264ENC=1 -DVIDEO_CODEC_H265DEC=1 -DVIDEO_CODEC_H265ENC=1
> -DVIDEO
> _CODEC_AV1DEC=1 -DVIDEO_CODEC_AV1ENC=1 -DVIDEO_CODEC_VP9DEC=1
> -DHAVE_X11_PLATFORM -DHAVE_WAYLAND_PLATFORM -DHAVE_SURFACELESS_PLATFORM
> -DHAVE_DRM_PLATFORM -DHAVE_XCB_PLATFORM -DENABLE_ST_OMX_BELLAGIO=0
> -DENABLE_ST
> _OMX_TIZONIA=0 -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING
> -DGLX_USE_DRM -DGLAPI_EXPORT_PROTO_ENTRY_POINTS=0 -DALLOW_KCMP
> -DETIME=ETIMEDOUT -DENABLE_SHADER_CACHE -DHAVE___BUILTIN_BSWAP32
> -DHAVE___BUILTIN_BSWA
> P64 -DHAVE___BUILTIN_CLZ -DHAVE___BUILTIN_CLZLL -DHAVE___BUILTIN_CTZ
> -DHAVE___BUILTIN_EXPECT -DHAVE___BUILTIN_FFS -DHAVE___BUILTIN_FFSLL
> -DHAVE___BUILTIN_POPCOUNT -DHAVE___BUILTIN_POPCOUNTLL -DHAVE___BUILTIN_UNRE
> ACHABLE -DHAVE___BUILTIN_TYPES_COMPATIBLE_P -DHAVE_FUNC_ATTRIBUTE_CONST
> -DHAVE_FUNC_ATTRIBUTE_FLATTEN -DHAVE_FUNC_ATTRIBUTE_MALLOC
> -DHAVE_FUNC_ATTRIBUTE_PURE -DHAVE_FUNC_ATTRIBUTE_UNUSED
> -DHAVE_FUNC_ATTRIBUTE_WAR
> N_UNUSED_RESULT -DHAVE_FUNC_ATTRIBUTE_WEAK -DHAVE_FUNC_ATTRIBUTE_FORMAT
> -DHAVE_FUNC_ATTRIBUTE_PACKED -DHAVE_FUNC_ATTRIBUTE_RETURNS_NONNULL
> -DHAVE_FUNC_ATTRIBUTE_ALIAS -DHAVE_FUNC_ATTRIBUTE_NORETURN -DHAVE_FUNC_AT
> TRIBUTE_VISIBILITY -DHAVE_UINT128 -DHAVE_REALLOCARRAY -DHAVE_FMEMOPEN
> -D_GNU_SOURCE -DUSE_SSE41 -DHAVE___BUILTIN_IA32_CLFLUSHOPT
> -DUSE_GCC_ATOMIC_BUILTINS -DUSE_X86_64_ASM -DHAS_SCHED_H
> -DHAS_SCHED_GETAFFINITY -D
> HAVE_SYS_SYSCTL_H -DHAVE_XLOCALE_H -DHAVE_ENDIAN_H -DHAVE_DLFCN_H
> -DHAVE_SYS_SHM_H -DHAVE_CET_H -DHAVE_PTHREAD_NP_H -DHAVE_STRTOF
> -DHAVE_MKOSTEMP -DHAVE_MEMFD_CREATE -DHAVE_FLOCK -DHAVE_STRTOK_R
> -DHAVE_GETRANDOM
> -DHAVE_QSORT_S -DHAVE_POSIX_FALLOCATE -DHAVE_SECURE_GETENV
> -DHAVE_GNU_QSORT_R -DHAVE_STRUCT_TIMESPEC -DHAVE_POSIX_MEMALIGN
> -DHAVE_DIRENT_D_TYPE -DHAVE_STRTOD_L -DHAVE_DLADDR -DHAVE_DL_ITERATE_PHDR
> -DSUPPORT_INTEL
> _INTEGRATED_GPUS -DHAVE_ZLIB -DHAVE_ZSTD -DHAVE_COMPRESSION -DHAVE_PTHREAD
> -DHAVE_LIBDRM '-DMESA_LLVM_VERSION_STRING="15.0.7"' -DLLVM_IS_SHARED=1
> -DLLVM_AVAILABLE=1 -DDRAW_LLVM_AVAILABLE=1 -DUSE_LIBELF -DWL_HIDE_
> DEPRECATED -DHAVE_DRI -DHAVE_DRI2 -DHAVE_DRI3 -DHAVE_DRI3_MODIFIERS
> -DHAVE_DRISW_KMS -Werror=implicit-function-declaration
> -Werror=missing-prototypes -Werror=return-type -Werror=empty-body
> -Werror=incompatible-po
> inter-types -Werror=int-conversion -Wimplicit-fallthrough
> -Wmisleading-indentation -Wno-missing-field-initializers
> -Wno-format-truncation -fno-math-errno -fno-trapping-math
> -Qunused-arguments -fno-common -Wno-unk
> nown-pragmas -Wno-microsoft-enum-value -Wno-unused-function -Werror=format
> -Wformat-security -ffunction-sections -fdata-sections -Wno-unused-variable
> -Wno-unused-but-set-variable -O2 -pipe -fstack-protector-stron
> g -fno-strict-aliasing -fPIC -pthread -Wno-override-init
> -Wno-initializer-overrides -MD -MQ
> src/intel/common/libintel_common.a.p/xe_intel_gem.c.o -MF
> src/intel/common/libintel_common.a.p/xe_intel_gem.c.o.d -o src
> /intel/common/libintel_common.a.p/xe_intel_gem.c.o -c
> ../src/intel/common/xe/intel_gem.c
> FAILED: src/intel/common/libintel_common.a.p/xe_intel_gem.c.o
> cc -Isrc/intel/common/libintel_common.a.p -Isrc/intel/common
> -I../src/intel/common -Iinclude -I../include -Isrc -I../src -Isrc/intel
> -I../src/intel -Isrc/intel/genxml -Isrc/intel/dev -I/usr/local/include
> -I/usr/l
> ocal/include/libdrm -fvisibility=hidden -fdiagnostics-color=never -DNDEBUG
> -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=c11
> -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
> '-DPACKAGE_VERS
> ION="24.0.8"' '-DPACKAGE_BUGREPORT="
> https://gitlab.freedesktop.org/mesa/mesa/-/issues;' -DHAVE_OPENGL=1
> -DHAVE_OPENGL_ES_1=1 -DHAVE_OPENGL_ES_2=1 -DHAVE_SWRAST -DHAVE_ZINK
> -DHAVE_R300 -DHAVE_R600 -DHAVE_RADEONSI
> -DHAVE_CROCUS -DHAVE_I915 -DHAVE_IRIS -DHAVE_SVGA -DUSE_VK_COMPILER=1
> -DVIDEO_CODEC_VC1DEC=1 -DVIDEO_CODEC_H264DEC=1 

mesa-dri-24.0.8 failing to build on d1bd097d52cb

[Nuno Teixeira]

Hello all,

Anyone seeing this error on main?

Thanks

[ 28% 661/2246] cc -Isrc/intel/common/libintel_common.a.p
-Isrc/intel/common -I../src/intel/common -Iinclude -I../include -Isrc
-I../src -Isrc/intel -I../src/intel -Isrc/intel/genxml -Isrc/intel/dev
-I/usr/local/
include -I/usr/local/include/libdrm -fvisibility=hidden
-fdiagnostics-color=never -DNDEBUG -D_FILE_OFFSET_BITS=64 -Wall
-Winvalid-pch -std=c11 -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
-D__STDC_LIMIT_MACROS
 '-DPACKAGE_VERSION="24.0.8"' '-DPACKAGE_BUGREPORT="
https://gitlab.freedesktop.org/mesa/mesa/-/issues;' -DHAVE_OPENGL=1
-DHAVE_OPENGL_ES_1=1 -DHAVE_OPENGL_ES_2=1 -DHAVE_SWRAST -DHAVE_ZINK
-DHAVE_R300 -DHAVE_R600
-DHAVE_RADEONSI -DHAVE_CROCUS -DHAVE_I915 -DHAVE_IRIS -DHAVE_SVGA
-DUSE_VK_COMPILER=1 -DVIDEO_CODEC_VC1DEC=1 -DVIDEO_CODEC_H264DEC=1
-DVIDEO_CODEC_H264ENC=1 -DVIDEO_CODEC_H265DEC=1 -DVIDEO_CODEC_H265ENC=1
-DVIDEO
_CODEC_AV1DEC=1 -DVIDEO_CODEC_AV1ENC=1 -DVIDEO_CODEC_VP9DEC=1
-DHAVE_X11_PLATFORM -DHAVE_WAYLAND_PLATFORM -DHAVE_SURFACELESS_PLATFORM
-DHAVE_DRM_PLATFORM -DHAVE_XCB_PLATFORM -DENABLE_ST_OMX_BELLAGIO=0
-DENABLE_ST
_OMX_TIZONIA=0 -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING
-DGLX_USE_DRM -DGLAPI_EXPORT_PROTO_ENTRY_POINTS=0 -DALLOW_KCMP
-DETIME=ETIMEDOUT -DENABLE_SHADER_CACHE -DHAVE___BUILTIN_BSWAP32
-DHAVE___BUILTIN_BSWA
P64 -DHAVE___BUILTIN_CLZ -DHAVE___BUILTIN_CLZLL -DHAVE___BUILTIN_CTZ
-DHAVE___BUILTIN_EXPECT -DHAVE___BUILTIN_FFS -DHAVE___BUILTIN_FFSLL
-DHAVE___BUILTIN_POPCOUNT -DHAVE___BUILTIN_POPCOUNTLL -DHAVE___BUILTIN_UNRE
ACHABLE -DHAVE___BUILTIN_TYPES_COMPATIBLE_P -DHAVE_FUNC_ATTRIBUTE_CONST
-DHAVE_FUNC_ATTRIBUTE_FLATTEN -DHAVE_FUNC_ATTRIBUTE_MALLOC
-DHAVE_FUNC_ATTRIBUTE_PURE -DHAVE_FUNC_ATTRIBUTE_UNUSED
-DHAVE_FUNC_ATTRIBUTE_WAR
N_UNUSED_RESULT -DHAVE_FUNC_ATTRIBUTE_WEAK -DHAVE_FUNC_ATTRIBUTE_FORMAT
-DHAVE_FUNC_ATTRIBUTE_PACKED -DHAVE_FUNC_ATTRIBUTE_RETURNS_NONNULL
-DHAVE_FUNC_ATTRIBUTE_ALIAS -DHAVE_FUNC_ATTRIBUTE_NORETURN -DHAVE_FUNC_AT
TRIBUTE_VISIBILITY -DHAVE_UINT128 -DHAVE_REALLOCARRAY -DHAVE_FMEMOPEN
-D_GNU_SOURCE -DUSE_SSE41 -DHAVE___BUILTIN_IA32_CLFLUSHOPT
-DUSE_GCC_ATOMIC_BUILTINS -DUSE_X86_64_ASM -DHAS_SCHED_H
-DHAS_SCHED_GETAFFINITY -D
HAVE_SYS_SYSCTL_H -DHAVE_XLOCALE_H -DHAVE_ENDIAN_H -DHAVE_DLFCN_H
-DHAVE_SYS_SHM_H -DHAVE_CET_H -DHAVE_PTHREAD_NP_H -DHAVE_STRTOF
-DHAVE_MKOSTEMP -DHAVE_MEMFD_CREATE -DHAVE_FLOCK -DHAVE_STRTOK_R
-DHAVE_GETRANDOM
-DHAVE_QSORT_S -DHAVE_POSIX_FALLOCATE -DHAVE_SECURE_GETENV
-DHAVE_GNU_QSORT_R -DHAVE_STRUCT_TIMESPEC -DHAVE_POSIX_MEMALIGN
-DHAVE_DIRENT_D_TYPE -DHAVE_STRTOD_L -DHAVE_DLADDR -DHAVE_DL_ITERATE_PHDR
-DSUPPORT_INTEL
_INTEGRATED_GPUS -DHAVE_ZLIB -DHAVE_ZSTD -DHAVE_COMPRESSION -DHAVE_PTHREAD
-DHAVE_LIBDRM '-DMESA_LLVM_VERSION_STRING="15.0.7"' -DLLVM_IS_SHARED=1
-DLLVM_AVAILABLE=1 -DDRAW_LLVM_AVAILABLE=1 -DUSE_LIBELF -DWL_HIDE_
DEPRECATED -DHAVE_DRI -DHAVE_DRI2 -DHAVE_DRI3 -DHAVE_DRI3_MODIFIERS
-DHAVE_DRISW_KMS -Werror=implicit-function-declaration
-Werror=missing-prototypes -Werror=return-type -Werror=empty-body
-Werror=incompatible-po
inter-types -Werror=int-conversion -Wimplicit-fallthrough
-Wmisleading-indentation -Wno-missing-field-initializers
-Wno-format-truncation -fno-math-errno -fno-trapping-math
-Qunused-arguments -fno-common -Wno-unk
nown-pragmas -Wno-microsoft-enum-value -Wno-unused-function -Werror=format
-Wformat-security -ffunction-sections -fdata-sections -Wno-unused-variable
-Wno-unused-but-set-variable -O2 -pipe -fstack-protector-stron
g -fno-strict-aliasing -fPIC -pthread -Wno-override-init
-Wno-initializer-overrides -MD -MQ
src/intel/common/libintel_common.a.p/xe_intel_gem.c.o -MF
src/intel/common/libintel_common.a.p/xe_intel_gem.c.o.d -o src
/intel/common/libintel_common.a.p/xe_intel_gem.c.o -c
./src/intel/common/xe/intel_gem.c
FAILED: src/intel/common/libintel_common.a.p/xe_intel_gem.c.o
cc -Isrc/intel/common/libintel_common.a.p -Isrc/intel/common
-I../src/intel/common -Iinclude -I../include -Isrc -I../src -Isrc/intel
-I../src/intel -Isrc/intel/genxml -Isrc/intel/dev -I/usr/local/include
-I/usr/l
ocal/include/libdrm -fvisibility=hidden -fdiagnostics-color=never -DNDEBUG
-D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=c11
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
'-DPACKAGE_VERS
ION="24.0.8"' '-DPACKAGE_BUGREPORT="
https://gitlab.freedesktop.org/mesa/mesa/-/issues;' -DHAVE_OPENGL=1
-DHAVE_OPENGL_ES_1=1 -DHAVE_OPENGL_ES_2=1 -DHAVE_SWRAST -DHAVE_ZINK
-DHAVE_R300 -DHAVE_R600 -DHAVE_RADEONSI
-DHAVE_CROCUS -DHAVE_I915 -DHAVE_IRIS -DHAVE_SVGA -DUSE_VK_COMPILER=1
-DVIDEO_CODEC_VC1DEC=1 -DVIDEO_CODEC_H264DEC=1 -DVIDEO_CODEC_H264ENC=1
-DVIDEO_CODEC_H265DEC=1 -DVIDEO_CODEC_H265ENC=1 -DVIDEO_CODEC_AV1DEC=1
-DVIDEO_CODEC_AV1ENC=1 -DVIDEO_CODEC_VP9DEC=1 -DHAVE_X11_PLATFORM
-DHAVE_WAYLAND_PLATFORM -DHAVE_SURFACELESS_PLATFORM -DHAVE_DRM_PLATFORM
-DHAVE_XCB_PLATFORM -DENABLE_ST_OMX_BELLAGIO=0 -DENABLE_ST_OMX_TIZONIA=0
-DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DGLX_USE_DRM
-DGLAPI_EXPORT_PROTO_ENTRY_POINTS=0 -DALLOW_KCMP 

Re: May 2024 stabilization week

[void]

On Mon, May 27, 2024 at 09:24:14PM -0700, Gleb Smirnoff wrote:


Replying to this email thread with your success reports as well
as reporting any regressions is very much appreciated. Thanks!


This is new. In the daily security run output (arm64.aarch64):

/etc/periodic/security/900.tcpwrap: security_daily_compat_var: not found
/etc/periodic/security/900.tcpwrap: security_daily_compat_var: not found   
--

Re: CURRENT: exec_machdep.c:80:2: error: KDB must be enabled in order for DDB

[Gary Jennejohn]

On Thu, 30 May 2024 05:12:01 +0200
FreeBSD User  wrote:

> Hello,
>
> for customising my world and kernel, I try to "overlay" GENERIC via included 
> files containing
> "nodevice" and "nooptions" tags starting from a top level config file like
>
> include GENERIC
> include NODEVICE-GENERIC
> include   SPECIAL
>
> Within "NODEVICE-GENERIC" I utilize
> [...]
> # Debugging support.  Always need this:
> nooptions   KDB # Enable kernel debugger support.
> nooptions   KDB_TRACE   # Print a stack trace for a panic.
> # For full debugger support use (turn off in stable branch):
> include "std.nodebug"
> [...]
>
> to disable KDB. The include "std.debug" in GENERIC is new, prior to its 
> occurence the sketched
> scheme worked fine for me, but now I get this error while perfoming "make -jX 
> buildworld
> buildkernel":
>
> [...]
> /usr/src/sys/amd64/amd64/exec_machdep.c:80:2: error: KDB must be enabled in 
> order for DDB to
> work! 80 | #error KDB must be enabled in order for DDB to work!
>   |  ^
> [...]
>
> Apart from the recommendation not to disable KDB in CURRENT, is there a way 
> to disable
> debugging features and mimik a stable branch?
>
> Thanks in advance,
>

GENERIC contains options DDB_CTF, which results in opt_ddb.h being created.

/sys/conf/kern.pre.mk:DDB_ENABLED!= grep DDB opt_ddb.h || true ; echo
will result in DDB_ENABLED being true, since #define DDB_CTF 1 will be
present in opt_ddb.h.

So adding noptions DDB and nooptions DDB_CTF to your NODEVICE-GENERIC
might solve your problem.

--
Gary Jennejohn

CURRENT: exec_machdep.c:80:2: error: KDB must be enabled in order for DDB

[FreeBSD User]

Hello,

for customising my world and kernel, I try to "overlay" GENERIC via included 
files containing
"nodevice" and "nooptions" tags starting from a top level config file like

include GENERIC
include NODEVICE-GENERIC
include SPECIAL

Within "NODEVICE-GENERIC" I utilize
[...]
# Debugging support.  Always need this:
nooptions   KDB # Enable kernel debugger support.
nooptions   KDB_TRACE   # Print a stack trace for a panic.
# For full debugger support use (turn off in stable branch):
include "std.nodebug"
[...]

to disable KDB. The include "std.debug" in GENERIC is new, prior to its 
occurence the sketched
scheme worked fine for me, but now I get this error while perfoming "make -jX 
buildworld
buildkernel":

[...]
/usr/src/sys/amd64/amd64/exec_machdep.c:80:2: error: KDB must be enabled in 
order for DDB to
work! 80 | #error KDB must be enabled in order for DDB to work!
  |  ^
[...]

Apart from the recommendation not to disable KDB in CURRENT, is there a way to 
disable
debugging features and mimik a stable branch?

Thanks in advance,

oh



-- 
O. Hartmann

Re: May 2024 stabilization week

[Gleb Smirnoff]

On Mon, May 27, 2024 at 09:24:14PM -0700, Gleb Smirnoff wrote:
T> On Mon, May 27, 2024 at 01:00:24AM -0700, Gleb Smirnoff wrote:
T> T> This is an automated email to inform you that the May 2024 stabilization 
week
T> T> started with FreeBSD/main at main-n270422-cca0ce62f367, which was tagged 
as
T> T> main-stabweek-2024-May.
T> 
T> Monday night status update:
T> 
T> - Updated my personal desktop and home router, no issues noticed.
T> - Testing at Netflix is delayed due to several issues: the test cluster
T>   busy with other stuff, some small difficulties with merging, etc.
T>   Usually we run the test Monday night to Tuesday, but this time we
T>   plan to do it Tuesday to Wednesday.

This time at Netflix we had limited testing capacity.  The test was run
on 3 pairs of machines (normally we have > 20).  Anyway, no stability
issues neither performance regressions were found by our testing.

Since I didn't receive any negative feedback on the stabilization snapshot,
the stabilization week is declared completed.

I created a branch stabweek-2024-May that has two bugfixes cherry-picked:

4c053c17f2c8a715988f215d16284879857ca376 (affects 32-bit ZFS users)
2780e5f43d5b0e8b155472300ee63816a660780e (affects users of linuxulator)

The branch is published at https://github.com/glebius/FreeBSD.

For those, who want to recreate the branch without using my repo:

git checkout -b stabweek-2024-May cca0ce62f367d03ed429bf99e41e6aca8cb7f2ac
git cherry-pick -x 4c053c17f2c8a715988f215d16284879857ca376
git cherry-pick -x 2780e5f43d5b0e8b155472300ee63816a660780e

-- 
Gleb Smirnoff

Re: May 2024 stabilization week

[void]

Hi Gleb,

On Mon, May 27, 2024 at 09:24:14PM -0700, Gleb Smirnoff wrote:


Replying to this email thread with your success reports as well
as reporting any regressions is very much appreciated. Thanks!


Works fine, no issues on arm64.aarch64 where it's running
nginx, monit and a poudriere instance.

--

Re: [Bug 269133] bnxt(4): BCM57416 - HWRM_CFA_L2_SET_RX_MASK command returned RESOURCE_ALLOC_ERROR error

[Gerrit Kühn]

Am Tue, 28 May 2024 11:25:09 +0200
schrieb Santiago Martinez :

> *"The latest I have is 214.0.286.18"*
> Indeed, the firmware on my box is older, I cannot upgrade it right now, 
> but it is on my to-do list.

Same here, I guess (pkgver). It says
dev.bnxt.0.ver.fw_ver: 214.4.9.10/pkg 214.0.286.18
on both systems.

Also, I don't think I can upgrade the firmware separately, it comes with
the mainboard's bios (which is the latest available).


cu
  Gerrit


smime.p7s
Description: S/MIME cryptographic signature

Re: [Bug 269133] bnxt(4): BCM57416 - HWRM_CFA_L2_SET_RX_MASK command returned RESOURCE_ALLOC_ERROR error

[Santiago Martinez]

Hi!

*"The latest I have is 214.0.286.18"*
Indeed, the firmware on my box is older, I cannot upgrade it right now, 
but it is on my to-do list.


I'm also trying to apply the patch recommended by @Warner.

I will keep you posted.

Santi


On 5/28/24 11:19, Gerrit Kühn wrote:

Am Tue, 28 May 2024 10:59:00 +0200
schrieb Santiago Martinez:


Not sure if it will break your setup, but this already happened with
13.2 (I cant recall the exact release).

I have two machines with onboard NICs (Supermicro H12SSL-CT mainboards)
running just fine. One is 13.3, the other is 14.0.


Drivers used to be ok, before 13.X and then I started to see many errors.

No errors at all on my side here. Do you have onboard NICs or PCIe cards?
 From the bugreport linked in earliers mails I can also see that the
firmware I have here appears to be much older than what other people use.
The latest I have is 214.0.286.18.


is it possible for you to test on that machine and see what happens or
its prod?

Well, the 13.3 is production, the 14.0 is configured and loaded with
data, should actually go into production this week (that's why I was
asking... :-). However, I do have a third system of the same hardware that
is unused right now. I could do tests there (given I find some time).


cu
   Gerrit

Re: [Bug 269133] bnxt(4): BCM57416 - HWRM_CFA_L2_SET_RX_MASK command returned RESOURCE_ALLOC_ERROR error

[Gerrit Kühn]

Am Tue, 28 May 2024 10:59:00 +0200
schrieb Santiago Martinez :

> Not sure if it will break your setup, but this already happened with 
> 13.2 (I cant recall the exact release).

I have two machines with onboard NICs (Supermicro H12SSL-CT mainboards)
running just fine. One is 13.3, the other is 14.0.

> Drivers used to be ok, before 13.X and then I started to see many errors.

No errors at all on my side here. Do you have onboard NICs or PCIe cards?
From the bugreport linked in earliers mails I can also see that the
firmware I have here appears to be much older than what other people use.
The latest I have is 214.0.286.18.

> is it possible for you to test on that machine and see what happens or 
> its prod?

Well, the 13.3 is production, the 14.0 is configured and loaded with
data, should actually go into production this week (that's why I was
asking... :-). However, I do have a third system of the same hardware that
is unused right now. I could do tests there (given I find some time).


cu
  Gerrit


smime.p7s
Description: S/MIME cryptographic signature

Re: [Bug 269133] bnxt(4): BCM57416 - HWRM_CFA_L2_SET_RX_MASK command returned RESOURCE_ALLOC_ERROR error

[Santiago Martinez]

Hi Gerrit,

Not sure if it will break your setup, but this already happened with 
13.2 (I cant recall the exact release).


Drivers used to be ok, before 13.X and then I started to see many errors.

That's why I was suggesting to have a pkg with if_bnxt to get releases 
as required without needing a P1/2/++ release.


is it possible for you to test on that machine and see what happens or 
its prod?


Santi

On 5/28/24 08:40, Gerrit Kühn wrote:

Am Mon, 27 May 2024 15:05:31 -0600
schrieb Warner Losh:


I'd like it there, but I think this will need to be a EN to get it into
14.1 given the late date of this commit  Unless we slip 14.1 for
other reasons...

I have systems running 14.0 that use onboard bnxt  chipsets, seen no issues so far. Does this
mean I'll have to stick with 14.0 as 14.1 will probably break the
interfaces?


cu
   Gerrit

Re: May 2024 stabilization week

[Alexander Leidinger]

Am 2024-05-28 06:24, schrieb Gleb Smirnoff:

On Mon, May 27, 2024 at 01:00:24AM -0700, Gleb Smirnoff wrote:
T> This is an automated email to inform you that the May 2024 
stabilization week
T> started with FreeBSD/main at main-n270422-cca0ce62f367, which was 
tagged as

T> main-stabweek-2024-May.

Monday night status update:

- Updated my personal desktop and home router, no issues noticed.
- Testing at Netflix is delayed due to several issues: the test cluster
  busy with other stuff, some small difficulties with merging, etc.
  Usually we run the test Monday night to Tuesday, but this time we
  plan to do it Tuesday to Wednesday.

Regressions I am aware of and tracking:

- Linuxulator too strict on Netlink (PR 279012)

Replying to this email thread with your success reports as well
as reporting any regressions is very much appreciated. Thanks!


Intel 32bit users users which use ZFS may want to have
  
https://cgit.FreeBSD.org/src/commit/?id=4c053c17f2c8a715988f215d16284879857ca376


Apart from that much more stable on my 30-jails + poudriere host than 
the src as from the middle of the month.


Bye,
Alexander.

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


signature.asc
Description: OpenPGP digital signature

Re: [Bug 269133] bnxt(4): BCM57416 - HWRM_CFA_L2_SET_RX_MASK command returned RESOURCE_ALLOC_ERROR error

[Gerrit Kühn]

Am Mon, 27 May 2024 15:05:31 -0600
schrieb Warner Losh :

> I'd like it there, but I think this will need to be a EN to get it into
> 14.1 given the late date of this commit  Unless we slip 14.1 for
> other reasons...

I have systems running 14.0 that use onboard bnxt  chipsets, seen no issues so far. Does this
mean I'll have to stick with 14.0 as 14.1 will probably break the
interfaces?


cu
  Gerrit


smime.p7s
Description: S/MIME cryptographic signature

Re: May 2024 stabilization week

[Gleb Smirnoff]

On Mon, May 27, 2024 at 01:00:24AM -0700, Gleb Smirnoff wrote:
T> This is an automated email to inform you that the May 2024 stabilization week
T> started with FreeBSD/main at main-n270422-cca0ce62f367, which was tagged as
T> main-stabweek-2024-May.

Monday night status update:

- Updated my personal desktop and home router, no issues noticed.
- Testing at Netflix is delayed due to several issues: the test cluster
  busy with other stuff, some small difficulties with merging, etc.
  Usually we run the test Monday night to Tuesday, but this time we
  plan to do it Tuesday to Wednesday.

Regressions I am aware of and tracking:

- Linuxulator too strict on Netlink (PR 279012)

Replying to this email thread with your success reports as well
as reporting any regressions is very much appreciated. Thanks!

-- 
Gleb Smirnoff

Re: [Bug 269133] bnxt(4): BCM57416 - HWRM_CFA_L2_SET_RX_MASK command returned RESOURCE_ALLOC_ERROR error

[Warner Losh]

On Mon, May 27, 2024 at 3:01 PM Colin Percival  wrote:

> On 5/27/24 13:51, Warner Losh wrote:
> > On Mon, May 27, 2024 at 10:16 AM Santiago Martinez  > > wrote:
> > Just wondering if anyone has any contact at broadcom.
> >
> > The bnxt drivers on 14.1BETA1 are unusable.
> >
> > Cards stop working randomly, LRO cannot be disable (fail
> FILTER_ALLOT),
> > even chaining mtu renders the card unusable.
> >
> > The cards, is the same it was used to open the original PR.
> >
> >
> > There's a series of reviews that I've reviewed, but haven't yet been
> committed.
> >
> > I think they start at https://reviews.freebsd.org/D45005
> > .
> >
> > I'll see if I can prevail upon them to commit them to -current soon.
> Just to be clear, you're not expecting this to get into 14.1-RELEASE,
> right?
>

I'd like it there, but I think this will need to be a EN to get it into
14.1 given the late date of this commit  Unless we slip 14.1 for other
reasons...

Warner

Re: [Bug 269133] bnxt(4): BCM57416 - HWRM_CFA_L2_SET_RX_MASK command returned RESOURCE_ALLOC_ERROR error

[Warner Losh]

On Mon, May 27, 2024 at 10:16 AM Santiago Martinez 
wrote:

> Hi Everyone,
>
> Just wondering if anyone has any contact at broadcom.
>
> The bnxt drivers on 14.1BETA1 are unusable.
>
> Cards stop working randomly, LRO cannot be disable (fail FILTER_ALLOT),
> even chaining mtu renders the card unusable.
>
> The cards, is the same it was used to open the original PR.
>

There's a series of reviews that I've reviewed, but haven't yet been
committed.

I think they start at https://reviews.freebsd.org/D45005.

I'll see if I can prevail upon them to commit them to -current soon.

Warner


> Best regards.
>
> Santiago
>
>
> On 5/4/23 14:20, bugzilla-nore...@freebsd.org wrote:
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269133
> >
> > --- Comment #8 from geoffroy desvernay  ---
> > Since upgrade from 12.3p1x to 13.2-RELEASE, we have the same error
> message here
> > with bnxt (not tested with 13.1):
> >
> > dmesg:
> > bnxt0:  mem
> > 0xb9a1-0xb9a1,0xb910-0xb91f,0xb9aa2000-0xb9aa3fff irq 48
> at
> > device 0.0 numa-domain 0 on pci9
> > bnxt0: Using 256 TX descriptors and 256 RX descriptors
> > bnxt0: Using 12 RX queues 12 TX queues
> > bnxt0: Using MSI-X interrupts with 13 vectors
> > bnxt0: Ethernet address: d0:94:66:81:60:e3
> > bnxt0: netmap queues/slots: TX 12/256, RX 12/256
> > bnxt1:  mem
> > 0xb9a0-0xb9a0,0xb880-0xb88f,0xb9aa-0xb9aa1fff irq 52
> at
> > device 0.1 numa-domain 0 on pci9
> > bnxt1: Using 256 TX descriptors and 256 RX descriptors
> > bnxt1: Using 12 RX queues 12 TX queues
> > bnxt1: Using MSI-X interrupts with 13 vectors
> > bnxt1: Ethernet address: d0:94:66:81:60:e4
> > bnxt1: netmap queues/slots: TX 12/256, RX 12/256
> > bnxt0: Link is UP full duplex, FC - none - 1 Mbps
> > bnxt0: link state changed to UP
> > bnxt1: Link is UP full duplex, FC - none - 1 Mbps
> > bnxt1: link state changed to UP
> > bnxt0: Attempt to re-allocate l2 ctx filter (fid: 0x1170204)
> > bnxt1: Attempt to re-allocate l2 ctx filter (fid: 0x11c0003f004)
> > bnxt0: Attempt to re-allocate l2 ctx filter (fid: 0x1250204)
> > bnxt1: Attempt to re-allocate l2 ctx filter (fid: 0x1280003f004)
> > bnxt0: HWRM_CFA_L2_SET_RX_MASK command returned RESOURCE_ALLOC_ERROR
> error.
> > bnxt0: set_multi: rx_mask set failed
> > bnxt0: HWRM_CFA_L2_SET_RX_MASK command returned RESOURCE_ALLOC_ERROR
> error.
> > bnxt0: set_multi: rx_mask set failed
> > [same messages x 100's]
> >
> >
> > sysctl:
> >
> > dev.bnxt.0.%domain: 0
> > dev.bnxt.0.%parent: pci9
> > dev.bnxt.0.%pnpinfo: vendor=0x14e4 device=0x16d8 subvendor=0x1028
> > subdevice=0x1feb class=0x02
> > dev.bnxt.0.%location: slot=0 function=0 dbsf=pci0:94:0:0
> > dev.bnxt.0.%driver: bnxt
> > dev.bnxt.0.%desc: Broadcom BCM57416 NetXtreme-E 10GBase-T Ethernet
> > dev.bnxt.0.ver.hwrm_min_ver: 1.10.2
> > dev.bnxt.0.ver.package_ver: 
> > dev.bnxt.0.ver.chip_type: ASIC
> > dev.bnxt.0.ver.chip_bond_id: 0
> > dev.bnxt.0.ver.chip_metal: 1
> > dev.bnxt.0.ver.chip_rev: 1
> > dev.bnxt.0.ver.chip_num: 5848
> > dev.bnxt.0.ver.phy_partnumber: 616740003
> > dev.bnxt.0.ver.phy_vendor: Amphenol
> > dev.bnxt.0.ver.roce_fw_name: BONO_FW
> > dev.bnxt.0.ver.netctrl_fw_name: KONG_FW
> > dev.bnxt.0.ver.mgmt_fw_name: AFW_223.0.205.0
> > dev.bnxt.0.ver.hwrm_fw_name: CHIMP_FW
> > dev.bnxt.0.ver.phy: 13.1.11
> > dev.bnxt.0.ver.fw_ver: 223.0.205.0/pkg 22.31.13.70
> > dev.bnxt.0.ver.roce_fw: 223.0.205
> > dev.bnxt.0.ver.netctrl_fw: 223.0.205
> > dev.bnxt.0.ver.mgmt_fw: 223.0.205
> > dev.bnxt.0.ver.hwrm_fw: 223.0.205
> > dev.bnxt.0.ver.driver_hwrm_if: 1.10.2.34
> > dev.bnxt.0.ver.hwrm_if: 1.10.2
> >
>
>

Re: [Bug 269133] bnxt(4): BCM57416 - HWRM_CFA_L2_SET_RX_MASK command returned RESOURCE_ALLOC_ERROR error

[Santiago Martinez]

Hi Everyone,

Just wondering if anyone has any contact at broadcom.

The bnxt drivers on 14.1BETA1 are unusable.

Cards stop working randomly, LRO cannot be disable (fail FILTER_ALLOT), 
even chaining mtu renders the card unusable.


The cards, is the same it was used to open the original PR.

Best regards.

Santiago


On 5/4/23 14:20, bugzilla-nore...@freebsd.org wrote:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269133

--- Comment #8 from geoffroy desvernay  ---
Since upgrade from 12.3p1x to 13.2-RELEASE, we have the same error message here
with bnxt (not tested with 13.1):

dmesg:
bnxt0:  mem
0xb9a1-0xb9a1,0xb910-0xb91f,0xb9aa2000-0xb9aa3fff irq 48 at
device 0.0 numa-domain 0 on pci9
bnxt0: Using 256 TX descriptors and 256 RX descriptors
bnxt0: Using 12 RX queues 12 TX queues
bnxt0: Using MSI-X interrupts with 13 vectors
bnxt0: Ethernet address: d0:94:66:81:60:e3
bnxt0: netmap queues/slots: TX 12/256, RX 12/256
bnxt1:  mem
0xb9a0-0xb9a0,0xb880-0xb88f,0xb9aa-0xb9aa1fff irq 52 at
device 0.1 numa-domain 0 on pci9
bnxt1: Using 256 TX descriptors and 256 RX descriptors
bnxt1: Using 12 RX queues 12 TX queues
bnxt1: Using MSI-X interrupts with 13 vectors
bnxt1: Ethernet address: d0:94:66:81:60:e4
bnxt1: netmap queues/slots: TX 12/256, RX 12/256
bnxt0: Link is UP full duplex, FC - none - 1 Mbps
bnxt0: link state changed to UP
bnxt1: Link is UP full duplex, FC - none - 1 Mbps
bnxt1: link state changed to UP
bnxt0: Attempt to re-allocate l2 ctx filter (fid: 0x1170204)
bnxt1: Attempt to re-allocate l2 ctx filter (fid: 0x11c0003f004)
bnxt0: Attempt to re-allocate l2 ctx filter (fid: 0x1250204)
bnxt1: Attempt to re-allocate l2 ctx filter (fid: 0x1280003f004)
bnxt0: HWRM_CFA_L2_SET_RX_MASK command returned RESOURCE_ALLOC_ERROR error.
bnxt0: set_multi: rx_mask set failed
bnxt0: HWRM_CFA_L2_SET_RX_MASK command returned RESOURCE_ALLOC_ERROR error.
bnxt0: set_multi: rx_mask set failed
[same messages x 100's]


sysctl:

dev.bnxt.0.%domain: 0
dev.bnxt.0.%parent: pci9
dev.bnxt.0.%pnpinfo: vendor=0x14e4 device=0x16d8 subvendor=0x1028
subdevice=0x1feb class=0x02
dev.bnxt.0.%location: slot=0 function=0 dbsf=pci0:94:0:0
dev.bnxt.0.%driver: bnxt
dev.bnxt.0.%desc: Broadcom BCM57416 NetXtreme-E 10GBase-T Ethernet
dev.bnxt.0.ver.hwrm_min_ver: 1.10.2
dev.bnxt.0.ver.package_ver: 
dev.bnxt.0.ver.chip_type: ASIC
dev.bnxt.0.ver.chip_bond_id: 0
dev.bnxt.0.ver.chip_metal: 1
dev.bnxt.0.ver.chip_rev: 1
dev.bnxt.0.ver.chip_num: 5848
dev.bnxt.0.ver.phy_partnumber: 616740003
dev.bnxt.0.ver.phy_vendor: Amphenol
dev.bnxt.0.ver.roce_fw_name: BONO_FW
dev.bnxt.0.ver.netctrl_fw_name: KONG_FW
dev.bnxt.0.ver.mgmt_fw_name: AFW_223.0.205.0
dev.bnxt.0.ver.hwrm_fw_name: CHIMP_FW
dev.bnxt.0.ver.phy: 13.1.11
dev.bnxt.0.ver.fw_ver: 223.0.205.0/pkg 22.31.13.70
dev.bnxt.0.ver.roce_fw: 223.0.205
dev.bnxt.0.ver.netctrl_fw: 223.0.205
dev.bnxt.0.ver.mgmt_fw: 223.0.205
dev.bnxt.0.ver.hwrm_fw: 223.0.205
dev.bnxt.0.ver.driver_hwrm_if: 1.10.2.34
dev.bnxt.0.ver.hwrm_if: 1.10.2

[HEADSUP] broken kernels for head this week for pkgbase

[Baptiste Daroussin]

Hello,

For people running, current, this week the kenrel was broken from
da76d349b6b104f4e70562304c800a0793dea18d to
73eb53813fe3a2245edbeb670902e4bb9d41e288

the kernel built and published as part of this weekly snapshot is impacted
I have launch a publication of a new snapshot which should replace the current
weekly in a couple of hours.

If you have install 15.snap20240525190352 make sure to upgrade again before
rebooting.

Best regards,
Bapt

May 2024 stabilization week

[Gleb Smirnoff]

  Hi FreeBSD/main users & developers:

This is an automated email to inform you that the May 2024 stabilization week
started with FreeBSD/main at main-n270422-cca0ce62f367, which was tagged as
main-stabweek-2024-May.

The tag main-stabweek-2024-May has been published at
https://github.com/glebius/FreeBSD/tags.  Those who want to participate
in the stabilization week are encouraged to update to the above
revision/tag and test their systems.

Developers are encouraged to avoid pushing new features to FreeBSD/main,
but focus on bugfixes instead.  The stabilization week runs up to
Friday 18:00 UTC, but if there is consensus that any regressions
discovered by participants have been fixed, it will end early.

Once that happens, the advisory freeze of FreeBSD/main branch is thawed.

--
Gleb Smirnoff

Re: CURRENT kernel crash beyond git: 02d15215cef2

[Graham Perrin]

On 26/05/2024 13:45, Herbert J. Skuhra wrote:

… No, idea why the fix hasn't been committed yet: …


A few hours earlier:

uma: Fix improper uses of UMA_MD_SMALL_ALLOC · freebsd/freebsd-src@d25ed65


HTH

Re: main cadd2ca217 doesn't boot

[FreeBSD User]

Am Sun, 26 May 2024 09:29:08 +0200
Bojan Novković  schrieb:

> Hi,
> 
> da76d349b6b1 replaced a UMA-related symbol but missed three instances 
> where the old one was used, ultimately causing the wrong UMA page 
> allocator to get selected and crashing the machine.
> 
> I tested this patch as a part of a bigger series where it works fine, so 
> this slipped through cracks without getting noticed.
> 
> I've attached a patch with a fix, I can boot an amd64 VM with it applied.
> Could you please give it a try and let me know if it fixes the issue?
> 
> Bojan

The patch fixes the problem on amd64 here ...

-- 
O. Hartmann

Re: main cadd2ca217 doesn't boot

[David Wolfskill]

On Sun, May 26, 2024 at 09:29:08AM +0200, Bojan Novković wrote:
> Hi,
> 
> da76d349b6b1 replaced a UMA-related symbol but missed three instances where
> the old one was used, ultimately causing the wrong UMA page allocator to get
> selected and crashing the machine.
> 
> I tested this patch as a part of a bigger series where it works fine, so
> this slipped through cracks without getting noticed.
> 
> I've attached a patch with a fix, I can boot an amd64 VM with it applied.
> Could you please give it a try and let me know if it fixes the issue?

TL;DR: Yes, it fixes it (for 2 of my laptops, at least).

Details:
Laptops were running (e.g.):

FreeBSD 15.0-CURRENT #155 main-n270400-02d15215cef2: Sat May 25 14:19:27 UTC 
2024 
r...@g1-70.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64 
1500018 1500018

After updating sources to main-n270407-73eb53813fe3 and doing a normal
in-place source-based update (which owrked, as such), I (attempted)
rebooting, which exhibited the previously-documented failures.

I rebooted using the kernel from main-n270400-02d15215cef2, applied the
patch, rebuilt the kernel, and ... the reboot this time was successful:

FreeBSD 15.0-CURRENT #157 main-n270407-73eb53813fe3-dirty: Sun May 26 13:02:07 
UTC 2024 
r...@g1-51.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64 
1500018 1500018

(My 3rd "development" machine -- the fastest one -- is still bogged down
with Yet Another Chromium Rebuild on behalf of production machines that
are due to be updated once that completes.)

Thanks!

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
I will not be voting for a "unified reich" in the US.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: CURRENT kernel crash beyond git: 02d15215cef2

[FreeBSD User]

Am Sun, 26 May 2024 14:45:37 +0200
"Herbert J. Skuhra"  schrieb:

> On Sun, May 26, 2024 at 02:35:16PM +0200, FreeBSD User wrote:
> > Hello,
> > 
> > boxes running CURRENT are last good with FreeBSD 15.0-CURRENT #44
> > main-n270400-02d15215cef2: Sat May 25 10:56:09 CEST 2024 amd64. Customized 
> > kernel.
> > 
> > After that commit, booting the kernel dies silently without any trace/core 
> > or similar and
> > resetting the system.
> > 
> > I tried to enable at least the standard debugging features, but that 
> > doesn't improve the
> > fact the machine resets/dies silently.  
> 
> Check the archive! Known issue:
> 
> https://lists.freebsd.org/archives/freebsd-current/2024-May/005990.html
> 
> No, idea why the fix hasn't been committed yet:
> 
> https://lists.freebsd.org/archives/freebsd-current/2024-May/005993.html
> 

My apology.
Nuni Teixeiras posting was right below mine :-(

Sorry for the noise,

Thanks and kind regards
oh

-- 
O. Hartmann

Re: CURRENT kernel crash beyond git: 02d15215cef2

[Herbert J. Skuhra]

On Sun, May 26, 2024 at 02:35:16PM +0200, FreeBSD User wrote:
> Hello,
> 
> boxes running CURRENT are last good with FreeBSD 15.0-CURRENT #44 
> main-n270400-02d15215cef2:
> Sat May 25 10:56:09 CEST 2024 amd64. Customized kernel.
> 
> After that commit, booting the kernel dies silently without any trace/core or 
> similar and
> resetting the system.
> 
> I tried to enable at least the standard debugging features, but that doesn't 
> improve the fact
> the machine resets/dies silently.

Check the archive! Known issue:

https://lists.freebsd.org/archives/freebsd-current/2024-May/005990.html

No, idea why the fix hasn't been committed yet:

https://lists.freebsd.org/archives/freebsd-current/2024-May/005993.html

-- 
Herbert 

Re: main cadd2ca217 doesn't boot

[Oleg Nauman]

Hello,

I can confirm that your patch fixes this issue ( am64 CURRENT cadd2ca21765 )

Thank you

On Sun, May 26, 2024 at 10:29 AM Bojan Novković  wrote:
>
> Hi,
>
> da76d349b6b1 replaced a UMA-related symbol but missed three instances
> where the old one was used, ultimately causing the wrong UMA page
> allocator to get selected and crashing the machine.
>
> I tested this patch as a part of a bigger series where it works fine, so
> this slipped through cracks without getting noticed.
>
> I've attached a patch with a fix, I can boot an amd64 VM with it applied.
> Could you please give it a try and let me know if it fixes the issue?
>
> Bojan

Re: main cadd2ca217 doesn't boot

[tuexen]

> On 26. May 2024, at 09:29, Bojan Novković  wrote:
> 
> Hi,
> 
> da76d349b6b1 replaced a UMA-related symbol but missed three instances where 
> the old one was used, ultimately causing the wrong UMA page allocator to get 
> selected and crashing the machine.
> 
> I tested this patch as a part of a bigger series where it works fine, so this 
> slipped through cracks without getting noticed.
> 
> I've attached a patch with a fix, I can boot an amd64 VM with it applied.
> Could you please give it a try and let me know if it fixes the issue?
Hi Hojan,

this fixes the issue for me using an arm64 VM (VMWare Fusion).

Best regards
Michael
> 
> Bojan
> 

Re: main cadd2ca217 doesn't boot

[Bojan Novković]

Hi,

da76d349b6b1 replaced a UMA-related symbol but missed three instances 
where the old one was used, ultimately causing the wrong UMA page 
allocator to get selected and crashing the machine.


I tested this patch as a part of a bigger series where it works fine, so 
this slipped through cracks without getting noticed.


I've attached a patch with a fix, I can boot an amd64 VM with it applied.
Could you please give it a try and let me know if it fixes the issue?

Bojan
diff --git a/sys/vm/uma_core.c b/sys/vm/uma_core.c
index 59066eb96ae9..516ac2c2965a 100644
--- a/sys/vm/uma_core.c
+++ b/sys/vm/uma_core.c
@@ -2523,7 +2523,7 @@ keg_ctor(void *mem, int size, void *udata, int flags)
 	 * If we haven't booted yet we need allocations to go through the
 	 * startup cache until the vm is ready.
 	 */
-#ifdef UMA_MD_SMALL_ALLOC
+#ifdef UMA_USE_DMAP
 	if (keg->uk_ppera == 1)
 		keg->uk_allocf = uma_small_alloc;
 	else
@@ -2536,7 +2536,7 @@ keg_ctor(void *mem, int size, void *udata, int flags)
 		keg->uk_allocf = contig_alloc;
 	else
 		keg->uk_allocf = page_alloc;
-#ifdef UMA_MD_SMALL_ALLOC
+#ifdef UMA_USE_DMAP
 	if (keg->uk_ppera == 1)
 		keg->uk_freef = uma_small_free;
 	else
@@ -5221,7 +5221,7 @@ uma_zone_reserve_kva(uma_zone_t zone, int count)
 	keg->uk_kva = kva;
 	keg->uk_offset = 0;
 	zone->uz_max_items = pages * keg->uk_ipers;
-#ifdef UMA_MD_SMALL_ALLOC
+#ifdef UMA_USE_DMAP
 	keg->uk_allocf = (keg->uk_ppera > 1) ? noobj_alloc : uma_small_alloc;
 #else
 	keg->uk_allocf = noobj_alloc;

Re: main cadd2ca217 doesn't boot

[Ryan Libby]

On Sat, May 25, 2024 at 5:47 PM Tomoaki AOKI  wrote:
>
> On Sun, 26 May 2024 00:21:31 +0100
> Nuno Teixeira  wrote:
>
> > Hello,
> >
> > Just upgraded to latest main at cadd2ca217
> >
> > Boot menu shows up and then it stops earlier around:
> > ..
> > FreeBSD clang version ...
> >
> > No crash dump.
> >
> > Thanks,
> >
> > --
> > Nuno Teixeira
> > FreeBSD UNIX: Web:  https://FreeBSD.org
>
> Just a FYI:
> commit 40d951bc5932deb87635f5c1780a6706d0c7c012, amd64 boots fine for
> me. So commits after 02d15215cef2a28f1865e6ad5b19f18af1398b8b caused
> the problem, maybe.
>
> Regards.
>
> --
> Tomoaki AOKI
>

I'm on amd64 running GENERIC.

This boots:
9b1de7e4844d vt/sc: retire logic to select vt(4) by default for UEFI boot

This doesn't:
da76d349b6b1 uma: Deduplicate uma_small_alloc

On one failed boot I saw a failed MPASS
panic: Assertion size != 0 && qsize != 0 failed at
/usr/src/freebsd/sys/kern/subr_vmem.c:427

Followed by about 1000 stack frames with 7 frames repeating, presumably
deep/infinite recursion.

Probably want to back this out until stabilized.

Ryan

Re: main cadd2ca217 doesn't boot

[Tomoaki AOKI]

On Sun, 26 May 2024 00:21:31 +0100
Nuno Teixeira  wrote:

> Hello,
> 
> Just upgraded to latest main at cadd2ca217
> 
> Boot menu shows up and then it stops earlier around:
> ..
> FreeBSD clang version ...
> 
> No crash dump.
> 
> Thanks,
> 
> -- 
> Nuno Teixeira
> FreeBSD UNIX: Web:  https://FreeBSD.org

Just a FYI:
commit 40d951bc5932deb87635f5c1780a6706d0c7c012, amd64 boots fine for
me. So commits after 02d15215cef2a28f1865e6ad5b19f18af1398b8b caused
the problem, maybe.

Regards.

-- 
Tomoaki AOKI

main cadd2ca217 doesn't boot

[Nuno Teixeira]

Hello,

Just upgraded to latest main at cadd2ca217

Boot menu shows up and then it stops earlier around:
..
FreeBSD clang version ...

No crash dump.

Thanks,

-- 
Nuno Teixeira
FreeBSD UNIX: Web:  https://FreeBSD.org

Re: panic: lock "tmpfsni" 0xfffff80721307090 already initialized

[Ryan Libby]

On Sat, May 25, 2024 at 1:32 AM Alexander Leidinger
 wrote:
>
> Hi,
>
> [123095] panic: lock "tmpfsni" 0xf80721307090 already initialized
> [123095] cpuid = 8
> [123095] time = 1716597585
> [123095] KDB: stack backtrace:
> [123095] db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> 0xfe08285c9690
> [123095] vpanic() at vpanic+0x13f/frame 0xfe08285c97c0
> [123095] panic() at panic+0x43/frame 0xfe08285c9820
> [123095] lock_init() at lock_init+0x155/frame 0xfe08285c9830
> [123095] _mtx_init() at _mtx_init+0x89/frame 0xfe08285c9850
> [123095] tmpfs_node_init() at tmpfs_node_init+0x28/frame
> 0xfe08285c9870
> [123095] keg_alloc_slab() at keg_alloc_slab+0x28d/frame
> 0xfe08285c98c0
> [123095] zone_import() at zone_import+0xec/frame 0xfe08285c9950
> [123095] cache_alloc() at cache_alloc+0x3b3/frame 0xfe08285c99b0
> [123095] cache_alloc_retry() at cache_alloc_retry+0x23/frame
> 0xfe08285c99f0
> [123095] tmpfs_alloc_node() at tmpfs_alloc_node+0x108/frame
> 0xfe08285c9a40
> [123095] tmpfs_alloc_file() at tmpfs_alloc_file+0xbf/frame
> 0xfe08285c9ad0
> [123095] tmpfs_create() at tmpfs_create+0x38/frame 0xfe08285c9b00
> [123095] VOP_CREATE_APV() at VOP_CREATE_APV+0x3c/frame
> 0xfe08285c9b20
> [123095] vn_open_cred() at vn_open_cred+0x2e2/frame 0xfe08285c9c80
> [123095] openatfp() at openatfp+0x268/frame 0xfe08285c9dc0
> [123095] sys_openat() at sys_openat+0x28/frame 0xfe08285c9de0
> [123095] filemon_wrapper_openat() at filemon_wrapper_openat+0x12/frame
> 0xfe08285c9e00
> [123095] amd64_syscall() at amd64_syscall+0x15b/frame 0xfe08285c9f30
> [123095] fast_syscall_common() at fast_syscall_common+0xf8/frame
> 0xfe08285c9f30
> [123095] --- syscall (499, FreeBSD ELF64, openat), rip = 0xab82ba, rsp =
> 0x8217439e8, rbp = 0x821743a20 ---
> [123095] Uptime: 1d10h11m35s
>
> This is with a world from 2024-05-17-084543.
>
> Full logs available at https://wiki.leidinger.net/core.txt.7 (1.1 MB).
>
> This was in the middle of the night, poudriere was running.
>
> Bye,
> Alexander.
>
> --
> http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
> http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF

It looks like tmpfs_node_init ought to pass the MTX_NEW flag, but I am
not seeing what may have changed recently that would explain why this
hasn't been hit before or more often on INVARIANTS kernels.

For future debugging, maybe uma should do an initial trashing of memory
even for zones that have an init procedure.

Ryan

Re: _mtx_lock_sleep: recursed on non-recursive mutex CAM device lock @ /..../sys/cam/nvme/nvme_da.c:469

[Alexander Leidinger]

Am 2024-05-22 22:45, schrieb Alexander Leidinger:


Am 2024-05-22 20:53, schrieb Warner Losh:


First order:

Looks like we're trying to schedule a trim, but that fails due to a 
malloc issue. So then, since it's a
malloc issue, we wind up trying to automatically reschedule this I/O, 
which recurses into the driver

with a bad lock held and boop.

Can you reproduce this?


So far I had it once. At least I have only one crashdump. I had one 
more reboot/crash, but no dump. I also have a watchdog running on this 
system, so not sure what caused the (unusual) reboot. I had a poudriere 
build running at both times. Since the crashdump I didn't run poudriere 
anymore.



If so, can you test this patch?


I give it a try tomorrow anyway, and I will try to stress the system 
again with poudriere.


The nvme is a cache and also a log device for a zpool, so not really a 
deterministic way to trigger access to it.


I've run a lot of poudriere builds together with other load (about 30 
jails with mysql, postgresql, redis, webmail, postfix, imap, java stuff, 
..) on this system since thursday. So far no panic in the nvme part.


Bye,
Alexander.

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

signature.asc
Description: OpenPGP digital signature

panic: lock "tmpfsni" 0xfffff80721307090 already initialized

[Alexander Leidinger]

Hi,

[123095] panic: lock "tmpfsni" 0xf80721307090 already initialized
[123095] cpuid = 8
[123095] time = 1716597585
[123095] KDB: stack backtrace:
[123095] db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
0xfe08285c9690

[123095] vpanic() at vpanic+0x13f/frame 0xfe08285c97c0
[123095] panic() at panic+0x43/frame 0xfe08285c9820
[123095] lock_init() at lock_init+0x155/frame 0xfe08285c9830
[123095] _mtx_init() at _mtx_init+0x89/frame 0xfe08285c9850
[123095] tmpfs_node_init() at tmpfs_node_init+0x28/frame 
0xfe08285c9870
[123095] keg_alloc_slab() at keg_alloc_slab+0x28d/frame 
0xfe08285c98c0

[123095] zone_import() at zone_import+0xec/frame 0xfe08285c9950
[123095] cache_alloc() at cache_alloc+0x3b3/frame 0xfe08285c99b0
[123095] cache_alloc_retry() at cache_alloc_retry+0x23/frame 
0xfe08285c99f0
[123095] tmpfs_alloc_node() at tmpfs_alloc_node+0x108/frame 
0xfe08285c9a40
[123095] tmpfs_alloc_file() at tmpfs_alloc_file+0xbf/frame 
0xfe08285c9ad0

[123095] tmpfs_create() at tmpfs_create+0x38/frame 0xfe08285c9b00
[123095] VOP_CREATE_APV() at VOP_CREATE_APV+0x3c/frame 
0xfe08285c9b20

[123095] vn_open_cred() at vn_open_cred+0x2e2/frame 0xfe08285c9c80
[123095] openatfp() at openatfp+0x268/frame 0xfe08285c9dc0
[123095] sys_openat() at sys_openat+0x28/frame 0xfe08285c9de0
[123095] filemon_wrapper_openat() at filemon_wrapper_openat+0x12/frame 
0xfe08285c9e00

[123095] amd64_syscall() at amd64_syscall+0x15b/frame 0xfe08285c9f30
[123095] fast_syscall_common() at fast_syscall_common+0xf8/frame 
0xfe08285c9f30
[123095] --- syscall (499, FreeBSD ELF64, openat), rip = 0xab82ba, rsp = 
0x8217439e8, rbp = 0x821743a20 ---

[123095] Uptime: 1d10h11m35s

This is with a world from 2024-05-17-084543.

Full logs available at https://wiki.leidinger.net/core.txt.7 (1.1 MB).

This was in the middle of the night, poudriere was running.

Bye,
Alexander.

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


signature.asc
Description: OpenPGP digital signature

Re: build of main broken? (ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_...' failed: symbol not defined)

[Ed Maste]

On Fri, 24 May 2024 at 11:28, Matteo Riondato  wrote:
>
> > In lib/libc/rpc/Symbol.map there is:
> >
> >/* From yp_xdr.c (generated by rpcgen - include/rpcsvc/yp.x) */
> >xdr_domainname;
> >xdr_keydat;
> >
> > so maybe the rpcgen step went wrong somehow? Do you have WITHOUT_NIS 
> > enabled?
>
> Yes, I do have WITHOUT_NIS=y in src.conf

peterj reported this in PR279270 as well and I've opened a review in
https://reviews.freebsd.org/D45347 to move these symbols to
lib/libc/yp/Symbol.map. Can you give that a try?

I originally proposed augmenting Version.map generation to pass CFLAGS
to CPP in D45346 and adding #ifdef YP in D45345, before finding Peter
PR and discovering that lib/libc/yp/Symbol.map already exists.

Re: build of main broken? (ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_...' failed: symbol not defined)

[Matteo Riondato]

> On May 24, 2024, at 10:54 AM, Dimitry Andric  wrote:
> 
> On 24 May 2024, at 15:19, Matteo Riondato  wrote:
>> 
>> I’m trying to build 59aa64914aeb1b20d4fc39ead2ee159a1e5b from 
>> main-62adeb92df, and got the error below.
>> 
>> I cannot immediately trace it back to any recent commit, so I’m a bit 
>> surprised by it.
>> 
>> Any hint?
>> 
>> --
> stage 4.2: building libraries
>> --
>> cd /usr/src;  time env MACHINE_ARCH=amd64  MACHINE=amd64  
>> CPUTYPE=skylake-avx512 BUILD_TOOLS_META=.NOMETA CC="/usr/local/bin/ccache cc 
>> -target x86_64-unknown-freebsd15.0 
>> --sysroot=/usr/obj/usr/src/amd64.amd64/tmp 
>> -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin" CXX="/usr/local/bin/ccache c++  
>> -target x86_64-unknown-freebsd15.0 
>> --sysroot=/usr/obj/usr/src/amd64.amd64/tmp 
>> -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin"  CPP="cpp -target 
>> x86_64-unknown-freebsd15.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp 
>> -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin"  AS="as" AR="ar" ELFCTL="elfctl" 
>> LD="ld"  LLVM_LINK="" NM=nm OBJCOPY="objcopy"  RANLIB=ranlib STRINGS=  
>> SIZE="size" STRIPBIN="strip"  INSTALL="install -U"  
>> PATH=/usr/obj/usr/src/amd64.amd64/tmp/bin:/usr/obj/usr/src/amd64.amd64/tmp/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin
>>   SYSROOT=/usr/obj/usr/src/amd64.amd64/tmp make  -f Makefile.inc1  
>> BWPHASE=libraries  DESTDIR=/usr/obj/usr/src/amd64.amd64/tmp -DNO_FSCHG 
>> MK_HTML=no -DNO_LINT MK_MAN=no  MK_PROFILE=no MK_TESTS=no 
>> MK_TESTS_SUPPORT=no  libraries
>> cd /usr/src;  make -f Makefile.inc1 _prereq_libs;  make -f Makefile.inc1 
>> _startup_libs;  make -f Makefile.inc1 _prebuild_libs 
>> -DLIBCRYPTO_WITHOUT_SUBDIRS;  make -f Makefile.inc1 _generic_libs
>> Building /usr/obj/usr/src/amd64.amd64/lib/libcompiler_rt/_libinstall
>> Building /usr/obj/usr/src/amd64.amd64/lib/libcompiler_rt/_installlinks
>> Building /usr/obj/usr/src/amd64.amd64/lib/libssp_nonshared/_libinstall
>> Building /usr/obj/usr/src/amd64.amd64/lib/libgcc_eh/_libinstall
>> Building /usr/obj/usr/src/amd64.amd64/lib/libgcc_eh/_INCSINS
>> installing DIRS FILESDIR
>> install -U  -d -m 0755 -o root  -g wheel  
>> /usr/obj/usr/src/amd64.amd64/tmp/usr/lib
>> Building /usr/obj/usr/src/amd64.amd64/lib/csu/amd64/_FILESINS_Scrt1.o
>> Building /usr/obj/usr/src/amd64.amd64/lib/csu/amd64/_FILESINS_crt1.o
>> Building /usr/obj/usr/src/amd64.amd64/lib/csu/amd64/_FILESINS_gcrt1.o
>> Building /usr/obj/usr/src/amd64.amd64/lib/csu/amd64/_FILESINS_crtbegin.o
>> Building /usr/obj/usr/src/amd64.amd64/lib/csu/amd64/_FILESINS_crtbeginS.o
>> Building /usr/obj/usr/src/amd64.amd64/lib/csu/amd64/_FILESINS_crtbeginT.o
>> Building /usr/obj/usr/src/amd64.amd64/lib/csu/amd64/_FILESINS_crtend.o
>> Building /usr/obj/usr/src/amd64.amd64/lib/csu/amd64/_FILESINS_crtendS.o
>> Building /usr/obj/usr/src/amd64.amd64/lib/csu/amd64/_FILESINS_crti.o
>> Building /usr/obj/usr/src/amd64.amd64/lib/csu/amd64/_FILESINS_crtn.o
>> Building /usr/obj/usr/src/amd64.amd64/lib/libsys/_libinstall
>> Building /usr/obj/usr/src/amd64.amd64/lib/libsys/_INCSINS
>> Building /usr/obj/usr/src/amd64.amd64/lib/libc/libc.so.7
>> building shared library libc.so.7
>> ld: error: version script assignment of 'FBSD_1.0' to symbol 
>> 'xdr_domainname' failed: symbol not defined
>> ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_keydat' 
>> failed: symbol not defined
> 
> In lib/libc/rpc/Symbol.map there is:
> 
>/* From yp_xdr.c (generated by rpcgen - include/rpcsvc/yp.x) */
>xdr_domainname;
>xdr_keydat;
> 
> so maybe the rpcgen step went wrong somehow? Do you have WITHOUT_NIS enabled?

Yes, I do have WITHOUT_NIS=y in src.conf

Thanks,
Matteo