Re: Booting in bhyve always sets currdev to ZFS

[Rick Macklem]

On Tue, Jul 2, 2024 at 7:30 AM Rodney W. Grimes
 wrote:
>
> > On Sun, Jun 30, 2024 at 8:23?AM Rodney W. Grimes
> >  wrote:
> > >
> > > > On Fri, Jun 28, 2024 at 6:26?PM Rick Macklem  
> > > > wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > I've installed FreeBSD current in a bhvye instance. Everything
> > > > > went ok, with UFS as a root partition.
> > > > > Then I created a zpool in another partition...
> > > > > - Now, every time I boot it I have to
> > > > >   OK set currdev=disk0s1a:
> > > > > to get it to boot.
> > > > >
> > > > > What is the trick to keep ZFS from messing up the boot variables?
> > > > I've been poking around, but haven't learned much.
> > > > I think it is userboot (although there are so many boot programs in 
> > > > /boot,
> > > > I am not 100% sure?) that sets currdev=zfs:example: since it sees there 
> > > > is ZFS
> > > > in a partition on the drive. It is not the boot partition and doesn't 
> > > > have
> > > > any boot stuff in it.
> > > >
> > > > When I look at userboot, it appears that it always sets 
> > > > userboot_zfs_found
> > > > to 1 whenever userboot_zfs_probe() is called, given that there is a ZFS
> > > > partition with a pool on it. This makes extract_currdev get set to the
> > > > ZFS stuff,
> > > > assuming I am reading the code correctly.
> > > > What I do not understand is why I have not seen this before?
> > > > (Was the a change to building it with USERBOOT_ZFS_SUPPORT done?)
> > > >
> > > > It seems that userboot_zfs_probe() should check for boot files on the 
> > > > volume
> > > > and not just that a pool exists on the partition, maybe?
> > > >
> > > > Anyhow, manually setting currdev=disk0s1a: gets around the problem.
> > >
> > > You should be able to set that in your ufs partition /boot/loader.conf
> > > file and at least then your not having to drop to the OK prompt and
> > > manually entering this.
> > Doesn't help, because it is not reading files from the boot ufs file system.
> > (I could copy all the boot stuff over into the ZFS file system, but that 
> > kinda
> > defeats the purpose of having UFS as the boot fs.)
>
> It had to of loaded userboot from the ufs, right?
I assume it is reading some boot file from UFS. Way back when I thought a
primary boot was read from 8K at the begining of the partition, but that's
how out of date I on this.
-> Put another way, I don't know if "userboot" is the one I am seeing try
   to use the ZFS partition.

>
> What type of disk is this?  gpt or mbr?
It's old MBR. Although I'll assume bhyve knows other stuff, most of my old
hardware only does MBR and not EFI, so I'll still in the MBR habit.

>
> Can you show the output of gpart show and gpart list?
root@nfsv4-foo:~ # gpart show
=>  63  67108801  vtbd0  MBR  (32G)
63 1 - free -  (512B)
64  67108800  1  freebsd  [active]  (32G)

=>   0  67108800  vtbd0s1  BSD  (32G)
 0  335544321  freebsd-ufs  (16G)
  33554432  125829122  freebsd-swap  (6.0G)
  46137344  209714564  freebsd-zfs  (10G)

root@nfsv4-foo:~ # gpart list
Geom name: vtbd0
modified: false
state: OK
fwheads: 255
fwsectors: 63
last: 67108863
first: 63
entries: 4
scheme: MBR
Providers:
1. Name: vtbd0s1
   Mediasize: 34359705600 (32G)
   Sectorsize: 512
   Stripesize: 32768
   Stripeoffset: 0
   Mode: r3w3e5
   efimedia: HD(1,MBR,0x90909090,0x40,0x3c0)
   attrib: active
   rawtype: 165
   length: 34359705600
   offset: 32768
   type: freebsd
   index: 1
   end: 67108863
   start: 64
Consumers:
1. Name: vtbd0
   Mediasize: 34359738368 (32G)
   Sectorsize: 512
   Stripesize: 32768
   Stripeoffset: 0
   Mode: r3w3e8

Geom name: vtbd0s1
modified: false
state: OK
fwheads: 255
fwsectors: 63
last: 67108799
first: 0
entries: 8
scheme: BSD
Providers:
1. Name: vtbd0s1a
   Mediasize: 17179869184 (16G)
   Sectorsize: 512
   Stripesize: 32768
   Stripeoffset: 0
   Mode: r1w1e1
   rawtype: 7
   length: 17179869184
   offset: 0
   type: freebsd-ufs
   index: 1
   end: 33554431
   start: 0
2. Name: vtbd0s1b
   Mediasize: 6442450944 (6.0G)
   Sectorsize: 512
   Stripesize: 32768
   Stripeoffset: 0
   Mode: r1w1e0
   rawtype: 1
   length: 6442450944
   offset: 17179869184
   type: freebsd-swap
   index: 2
   end: 46137343
   start: 33554432
3. Name: vtbd0s1d
   Mediasize: 10737385472 (10G)
   Sectorsize: 512
   Stripesize: 32768
   Stripeoffset: 0
   Mode: r1w1e1
   rawtype: 27
   length: 10737385472
   offset: 23622320128
   type: freebsd-zfs
   index: 4
   end: 67108799
   start: 46137344
Consumers:
1. Name: vtbd0s1
   Mediasize: 34359705600 (32G)
   Sectorsize: 512
   Stripesize: 32768
   Stripeoffset: 0
   Mode: r3w3e5

>
> >
> > For example, it always fails with:
> > ERROR: cannot open /boot/lua/loader.lua: no such file or directory.
> >
> > When I look in stand/efi/loader/main.c, there is a function that checks
> > for boot files called sanity_check_currdev(). However, userboot does not
> > have a similar function and just seems to assume 

Re: Booting in bhyve always sets currdev to ZFS

[Rodney W. Grimes]

> On Sun, Jun 30, 2024 at 8:23?AM Rodney W. Grimes
>  wrote:
> >
> > > On Fri, Jun 28, 2024 at 6:26?PM Rick Macklem  
> > > wrote:
> > > >
> > > > Hi,
> > > >
> > > > I've installed FreeBSD current in a bhvye instance. Everything
> > > > went ok, with UFS as a root partition.
> > > > Then I created a zpool in another partition...
> > > > - Now, every time I boot it I have to
> > > >   OK set currdev=disk0s1a:
> > > > to get it to boot.
> > > >
> > > > What is the trick to keep ZFS from messing up the boot variables?
> > > I've been poking around, but haven't learned much.
> > > I think it is userboot (although there are so many boot programs in /boot,
> > > I am not 100% sure?) that sets currdev=zfs:example: since it sees there 
> > > is ZFS
> > > in a partition on the drive. It is not the boot partition and doesn't have
> > > any boot stuff in it.
> > >
> > > When I look at userboot, it appears that it always sets userboot_zfs_found
> > > to 1 whenever userboot_zfs_probe() is called, given that there is a ZFS
> > > partition with a pool on it. This makes extract_currdev get set to the
> > > ZFS stuff,
> > > assuming I am reading the code correctly.
> > > What I do not understand is why I have not seen this before?
> > > (Was the a change to building it with USERBOOT_ZFS_SUPPORT done?)
> > >
> > > It seems that userboot_zfs_probe() should check for boot files on the 
> > > volume
> > > and not just that a pool exists on the partition, maybe?
> > >
> > > Anyhow, manually setting currdev=disk0s1a: gets around the problem.
> >
> > You should be able to set that in your ufs partition /boot/loader.conf
> > file and at least then your not having to drop to the OK prompt and
> > manually entering this.
> Doesn't help, because it is not reading files from the boot ufs file system.
> (I could copy all the boot stuff over into the ZFS file system, but that kinda
> defeats the purpose of having UFS as the boot fs.)

It had to of loaded userboot from the ufs, right?

What type of disk is this?  gpt or mbr?

Can you show the output of gpart show and gpart list?

> 
> For example, it always fails with:
> ERROR: cannot open /boot/lua/loader.lua: no such file or directory.
> 
> When I look in stand/efi/loader/main.c, there is a function that checks
> for boot files called sanity_check_currdev(). However, userboot does not
> have a similar function and just seems to assume that the ZFS partition
> in the bootable one, if it finds one.

That sounds like a wrong assumption by the code.

> --> I am wondering if sanity_check_currdev() shoud be added to userboot
>   to handle this case?

Warner??
 
> rick
> 
> >
> > There is much magic in boot code that bites, and not just in FreeBSD.
> > Often assumptions are made that "this" boot code, and "this" OS are
> > the only things on the disk(s).
> >
> > The fact that Linux uses a "apple-zfs" uuid, and FreeBSD a "FreeBSD-zfs"
> > drove me nuts for 2 days until I found this little tid bit.
> >
> > Zpool import doesnt care, but the boot code does!
> >
> > --
> > Rod Grimes 
> > rgri...@freebsd.org
-- 
Rod Grimes rgri...@freebsd.org

Re: Booting in bhyve always sets currdev to ZFS

[Jan Martin Mikkelsen]

On 29. Jun 2024, at 03:26, Rick Macklem  wrote:
> 
> Hi,
> 
> I've installed FreeBSD current in a bhvye instance. Everything
> went ok, with UFS as a root partition.
> Then I created a zpool in another partition...
> - Now, every time I boot it I have to
>  OK set currdev=disk0s1a:
> to get it to boot.
> 
> What is the trick to keep ZFS from messing up the boot variables?


I remember having this problem a few years ago. I see I have in an old startup 
file, ‘-e “rootdev=disk0”’ to set a loader environment variable. I also recall 
needing different Bhyve firmware, and I used gptboot. Some of these things 
might have been for different reasons. Other details are fuzzy.

Regards,

Jan M.

Re: Booting in bhyve always sets currdev to ZFS

[Rick Macklem]

On Sun, Jun 30, 2024 at 8:23 AM Rodney W. Grimes
 wrote:
>
> > On Fri, Jun 28, 2024 at 6:26?PM Rick Macklem  wrote:
> > >
> > > Hi,
> > >
> > > I've installed FreeBSD current in a bhvye instance. Everything
> > > went ok, with UFS as a root partition.
> > > Then I created a zpool in another partition...
> > > - Now, every time I boot it I have to
> > >   OK set currdev=disk0s1a:
> > > to get it to boot.
> > >
> > > What is the trick to keep ZFS from messing up the boot variables?
> > I've been poking around, but haven't learned much.
> > I think it is userboot (although there are so many boot programs in /boot,
> > I am not 100% sure?) that sets currdev=zfs:example: since it sees there is 
> > ZFS
> > in a partition on the drive. It is not the boot partition and doesn't have
> > any boot stuff in it.
> >
> > When I look at userboot, it appears that it always sets userboot_zfs_found
> > to 1 whenever userboot_zfs_probe() is called, given that there is a ZFS
> > partition with a pool on it. This makes extract_currdev get set to the
> > ZFS stuff,
> > assuming I am reading the code correctly.
> > What I do not understand is why I have not seen this before?
> > (Was the a change to building it with USERBOOT_ZFS_SUPPORT done?)
> >
> > It seems that userboot_zfs_probe() should check for boot files on the volume
> > and not just that a pool exists on the partition, maybe?
> >
> > Anyhow, manually setting currdev=disk0s1a: gets around the problem.
>
> You should be able to set that in your ufs partition /boot/loader.conf
> file and at least then your not having to drop to the OK prompt and
> manually entering this.
Doesn't help, because it is not reading files from the boot ufs file system.
(I could copy all the boot stuff over into the ZFS file system, but that kinda
defeats the purpose of having UFS as the boot fs.)

For example, it always fails with:
ERROR: cannot open /boot/lua/loader.lua: no such file or directory.

When I look in stand/efi/loader/main.c, there is a function that checks
for boot files called sanity_check_currdev(). However, userboot does not
have a similar function and just seems to assume that the ZFS partition
in the bootable one, if it finds one.
--> I am wondering if sanity_check_currdev() shoud be added to userboot
  to handle this case?

rick

>
> There is much magic in boot code that bites, and not just in FreeBSD.
> Often assumptions are made that "this" boot code, and "this" OS are
> the only things on the disk(s).
>
> The fact that Linux uses a "apple-zfs" uuid, and FreeBSD a "FreeBSD-zfs"
> drove me nuts for 2 days until I found this little tid bit.
>
> Zpool import doesnt care, but the boot code does!
>
>
> --
> Rod Grimes rgri...@freebsd.org

Please can we do something about programmatic interfaces to ZFS?

[David Chisnall]

Hi,

Since updating to 15-CURRENT, I have been unable to get some existing code that 
used libzfs_core to take snapshots.  There are a lot of reasons that this could 
have broken and it’s hard to track it down:

 - We ship both libnv and libnvpair.  These define the same data structure but 
with different APIs and are incompatible.  I believe libnv can create the 
serialised data structures that the ZFS ioctls expect.
 - We don’t install headers for libnvpair or libzfs_core (or libzfs) and so any 
code using these has to either depend on things in the src tree (which depend 
on OpenSolaris headers that are incompatible with FreeBSD ones, so must be in 
separate compilation units) or provide its own definitions, which may get out 
of sync with the libraries.
 - We don’t provide any documentation of the underlying ZFS ioctls (and there 
is some code that suggests that these vary between platforms), and so the 
*only* API for interacting with ZFS is libzfs_core.
 - The APIs in libzfs_core are also poorly documented.

This makes it incredibly difficult to interact with ZFS via anything other than 
the `zfs` command-line tool.  When things break, I have no idea which of these 
layers caused the breakage.

David

Multiple exports(5) lines generated by ZFS's sharenfs property (patch for review)

[Rick Macklem]

Hi,

I just put a patch on phabricator (D45814) that adds support for multiple
sets of options for different hosts/networks to the ZFS sharenfs property.
(It is based loosely on a patch in bugzilla PR#147881, now 14 years old.)

I have listed a couple of reviewers, but please feel free to review it as well.
(It will eventually need to become a pull request for OpenZFS, but I'd like
to run it past FreeBSD'ers first.)

The sets are separated by ';'s. One question is whether ';'s separated by
only whitespace should be allowed. If allowed they generate a "default"
exports line that exports the file system to the world with default options,
such as read/write.
The patch currently on phabricator allows this, but I am thinking that it
should not do so.
--> The default case could still be specified as it is now, as a single set
 of options without any ';'s in the sharenfs property.

Thanks in advance for any reviews, rick

Re: Booting in bhyve always sets currdev to ZFS

[Rodney W. Grimes]

> On Fri, Jun 28, 2024 at 6:26?PM Rick Macklem  wrote:
> >
> > Hi,
> >
> > I've installed FreeBSD current in a bhvye instance. Everything
> > went ok, with UFS as a root partition.
> > Then I created a zpool in another partition...
> > - Now, every time I boot it I have to
> >   OK set currdev=disk0s1a:
> > to get it to boot.
> >
> > What is the trick to keep ZFS from messing up the boot variables?
> I've been poking around, but haven't learned much.
> I think it is userboot (although there are so many boot programs in /boot,
> I am not 100% sure?) that sets currdev=zfs:example: since it sees there is ZFS
> in a partition on the drive. It is not the boot partition and doesn't have
> any boot stuff in it.
> 
> When I look at userboot, it appears that it always sets userboot_zfs_found
> to 1 whenever userboot_zfs_probe() is called, given that there is a ZFS
> partition with a pool on it. This makes extract_currdev get set to the
> ZFS stuff,
> assuming I am reading the code correctly.
> What I do not understand is why I have not seen this before?
> (Was the a change to building it with USERBOOT_ZFS_SUPPORT done?)
> 
> It seems that userboot_zfs_probe() should check for boot files on the volume
> and not just that a pool exists on the partition, maybe?
> 
> Anyhow, manually setting currdev=disk0s1a: gets around the problem.

You should be able to set that in your ufs partition /boot/loader.conf
file and at least then your not having to drop to the OK prompt and
manually entering this.

There is much magic in boot code that bites, and not just in FreeBSD.
Often assumptions are made that "this" boot code, and "this" OS are
the only things on the disk(s).

The fact that Linux uses a "apple-zfs" uuid, and FreeBSD a "FreeBSD-zfs"
drove me nuts for 2 days until I found this little tid bit.

Zpool import doesnt care, but the boot code does!


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

Re: Booting in bhyve always sets currdev to ZFS

[Rick Macklem]

On Fri, Jun 28, 2024 at 6:26 PM Rick Macklem  wrote:
>
> Hi,
>
> I've installed FreeBSD current in a bhvye instance. Everything
> went ok, with UFS as a root partition.
> Then I created a zpool in another partition...
> - Now, every time I boot it I have to
>   OK set currdev=disk0s1a:
> to get it to boot.
>
> What is the trick to keep ZFS from messing up the boot variables?
I've been poking around, but haven't learned much.
I think it is userboot (although there are so many boot programs in /boot,
I am not 100% sure?) that sets currdev=zfs:example: since it sees there is ZFS
in a partition on the drive. It is not the boot partition and doesn't have
any boot stuff in it.

When I look at userboot, it appears that it always sets userboot_zfs_found
to 1 whenever userboot_zfs_probe() is called, given that there is a ZFS
partition with a pool on it. This makes extract_currdev get set to the
ZFS stuff,
assuming I am reading the code correctly.
What I do not understand is why I have not seen this before?
(Was the a change to building it with USERBOOT_ZFS_SUPPORT done?)

It seems that userboot_zfs_probe() should check for boot files on the volume
and not just that a pool exists on the partition, maybe?

Anyhow, manually setting currdev=disk0s1a: gets around the problem.

rick

>
> Thanks, rick

Booting in bhyve always sets currdev to ZFS

[Rick Macklem]

Hi,

I've installed FreeBSD current in a bhvye instance. Everything
went ok, with UFS as a root partition.
Then I created a zpool in another partition...
- Now, every time I boot it I have to
  OK set currdev=disk0s1a:
to get it to boot.

What is the trick to keep ZFS from messing up the boot variables?

Thanks, rick

Re: Build issue with ncurses?

[David Wolfskill]

On Thu, Jun 27, 2024 at 03:12:47PM +0200, Baptiste Daroussin wrote:
> On Thu 27 Jun 05:29, David Wolfskill wrote:
> > ...
> > But my secondary laptop choked on ncurses while running
> > main-n270474-d2f1f71ec8c6, first after updating sources to
> > main-n270948-8521ea135f5b, then after the update to
> > main-n270979-cde6642431bb.
> ...
> This does not ring any bell to me, and I so nothing obvious here.
> 
> Best regards,
> Bapt

In the "get a bigger hammer" spirit, I moved /usr/obj aside, then
re-started the build.

It's got through "make buildworld" without issue, and is building the
kernel (which is considerably further along than it was when it had
failed, earlier).

Maybe that information will help someone else. 

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
In a collision, you don't get to choose which aspects of Physics apply.

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


signature.asc
Description: PGP signature

Build issue with ncurses?

[David Wolfskill]

I normally track FreeBSD daily, but was away from home for the first
coule of weeks of June, and am trying to get back into my usual update
cadence.

My (headless) build machine had no trouble updating:

main-n270474-d2f1f71ec8c6 (30 May) -> main-n270948-8521ea135f5b (25 June)
main-n270948-8521ea135f5b -> main-n270979-cde6642431bb (27 June)

But my secondary laptop choked on ncurses while running
main-n270474-d2f1f71ec8c6, first after updating sources to
main-n270948-8521ea135f5b, then after the update to
main-n270979-cde6642431bb.

I'm using meta-mode; I have attached a copy of the full meta file.  Here
is the part that I think is particularly relevant:

# Meta data file 
/common/S4/obj/usr/src/amd64.amd64/lib/ncurses/ncurses/new_pair.o.meta
CMD cc -target x86_64-unknown-freebsd15.0 
--sysroot=/common/S4/obj/usr/src/amd64.amd64/tmp 
-B/common/S4/obj/usr/src/amd64.amd64/tmp/usr/bin  -O2 -pipe -fno-common   
-D_XOPEN_SOURCE_EXTENDED -I. -I/usr/src/lib/ncurses/tinfo 
-I/usr/src/lib/ncurses/ncurses -I/usr/src/contrib/ncurses/include 
-I/usr/src/contrib/ncurses/ncurses 
-I/common/S4/obj/usr/src/amd64.amd64/lib/ncurses/tinfo -Wall -DNDEBUG 
-DHAVE_CONFIG_H -g -gz=zlib -std=gnu99 -Wno-format-zero-length 
-fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W 
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith 
-Wno-uninitialized -Wno-pointer-sign -Wdate-time -Wno-empty-body 
-Wno-string-plus-int -Wno-unused-const-variable 
-Wno-error=unused-but-set-parameter -Wno-tautological-compare -Wno-unused-value 
-Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion 
-Wno-unused-local-typedef -Wno-address-of-packed-member  -Qunused-arguments 
-c /usr/src/contrib/ncurses/ncurses/base/new_pair.c -o new_pair.o
CMD
CWD /common/S4/obj/usr/src/amd64.amd64/lib/ncurses/ncurses
TARGET new_pair.o
OODATE /usr/src/contrib/ncurses/ncurses/base/new_pair.c
-- command output --
In file included from /usr/src/contrib/ncurses/ncurses/base/new_pair.c:40:
In file included from /usr/src/contrib/ncurses/ncurses/curses.priv.h:425:
/usr/src/contrib/ncurses/ncurses/term.priv.h:141:16: error: redefinition of 
'term'
  141 | typedef struct term {   /* describe an actual terminal 
*/
  |^
./term.h:735:16: note: previous definition is here
  735 | typedef struct term {   /* describe an actual terminal */
  |^
In file included from /usr/src/contrib/ncurses/ncurses/base/new_pair.c:40:
In file included from /usr/src/contrib/ncurses/ncurses/curses.priv.h:425:
/usr/src/contrib/ncurses/ncurses/term.priv.h:153:3: error: typedef redefinition 
with different types ('struct (unnamed struct at 
/usr/src/contrib/ncurses/ncurses/term.priv.h:141:16)' vs 'struct term')
  153 | } TERMINAL;
  |   ^
./term.h:743:3: note: previous definition is here
  743 | } TERMINAL;
  |   ^
In file included from /usr/src/contrib/ncurses/ncurses/base/new_pair.c:40:
/usr/src/contrib/ncurses/ncurses/curses.priv.h:1248:3: error: redefinition of 
typedef 'SCREEN' is a C11 feature [-Werror,-Wtypedef-redefinition]
 1248 | } SCREEN;
  |   ^
./curses.h:394:24: note: previous definition is here
  394 | typedef struct screen  SCREEN;
  |^
3 errors generated.


I don't believe I have anything "suspect" in /etc/{src,make}*.conf:

g1-48(15.0-C)[22] foreach f ( /etc/{src,make}*.conf )
foreach? echo "${f}:" && grep -v '^#' $f; echo "==="; echo ""
foreach? end
/etc/src-env.conf:
WITH_META_MODE=yes
===

/etc/src.conf:
KERNCONF=CANARY
PORTS_MODULES+=x11/nvidia-driver
PORTS_MODULES+=graphics/drm-61-kmod
.MAKE.META.IGNORE_PATHS += /usr/local/etc/libmap.d
IWN_DEBUG=1
IEEE80211_DEBUG=1
BATCH_DELETE_OLD_FILES=1
WITHOUT_REPRODUCIBLE_BUILD=yes
WITHOUT_LLVM_TARGET_ALL=yes
===

/etc/make.conf:
NET_SNMP_SYS_CONTACT="da...@catwhisker.org"
NET_SNMP_SYS_LOCATION="variable"
NET_SNMP_LOGFILE=/var/log/snmpd.log
NET_SNMP_PERSISTENTDIR=/var/net-snmp
EXTRA_PATCH_TREE=/usr/local/port_patches
WITH_BSD_JDK=TRUE
WITHOUT_RUNTIME_CPUDETECTION=   YES
WITHOUT_CJK=YES
NO_SUID_XSERVER=YES
INSTALL_AS_NCFTP=yes
OPTIONS_SET=OPTIMIZED_CFLAGS
FORCE_PKG_REGISTER=YES
PKG_NOCOMPRESS=1
SENDMAIL_MC=/etc/mail/laptop.mc

.if ${.CURDIR:M*/graphics/drm-*kmod}
DISABLE_CONFLICTS=  YES
.endif
===

May I have the use of a clue, please?

Thanks!

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
In a collision, you don't get to choose which aspects of Physics apply.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.
# Meta data file 
/common/S4/obj/usr/src/amd64.amd64/lib/ncurses/ncurses/new_pair.o.meta
CMD cc -target x86_64-unknown-freebsd15.0 
--sysroot=/common/S4/obj/usr/src/amd64.amd64/tmp 
-B/common/S4/obj/usr/src/amd64.amd64/tmp/usr/bin  -O2 -pipe -fno-common   
-D_XOPEN_SOURCE_EXTENDED -I. -I/usr/src/lib/ncurses/tinfo 
-I/usr/src/lib/ncurses/ncurses 

random USB detach in CURRENT

[Rodrigo Osorio]

Hi,

Since a couple of weeks I'm start seeing random USB detach for all my 
devices once in a while.
The issue doesn't occurs so often and there is no other details in the 
var log. I'm able to recover all my devices by just unplugging and 
re-plug the devices.


I'm running 15.0-CURRENT main-n270900-dfaeeacc2cc2 GENERIC amd64 which 
is the latest weekly update.


Regards
-- Rodrigo
Jun 26 18:01:12 defiant kernel: ugen1.11:  at 
usbus1 (disconnected)
Jun 26 18:01:12 defiant kernel: uhub3: at uhub1, port 13, addr 10 (disconnected)
Jun 26 18:01:12 defiant kernel: uhub3: detached
Jun 26 18:01:12 defiant kernel: ugen1.3:  at usbus1 
(disconnected)
Jun 26 18:01:12 defiant kernel: uhub2: at uhub1, port 3, addr 2 (disconnected)
Jun 26 18:01:12 defiant kernel: ugen1.4:  at usbus1 (disconnected)
Jun 26 18:01:12 defiant kernel: uaudio0: at uhub2, port 1, addr 3 (disconnected)
Jun 26 18:01:12 defiant kernel: pcm1: detached
Jun 26 18:01:12 defiant kernel: uaudio0: detached
Jun 26 18:01:12 defiant kernel: ugen1.5:  at 
usbus1 (disconnected)
Jun 26 18:01:12 defiant kernel: ums0: at uhub2, port 2, addr 15 (disconnected)
Jun 26 18:01:12 defiant kernel: ums0: detached
Jun 26 18:01:13 defiant kernel: ugen1.12:  at usbus1 
(disconnected)
Jun 26 18:01:13 defiant kernel: uftdi0: at uhub2, port 3, addr 16 (disconnected)
Jun 26 18:01:13 defiant kernel: uftdi0: detached
Jun 26 18:01:13 defiant kernel: ugen1.6:  at usbus1 
(disconnected)
Jun 26 18:01:13 defiant kernel: ukbd0: at uhub2, port 4, addr 5 (disconnected)
Jun 26 18:01:13 defiant kernel: ukbd0: detached
Jun 26 18:01:13 defiant kernel: uhid0: at uhub2, port 4, addr 5 (disconnected)
Jun 26 18:01:13 defiant kernel: uhid0: detached
Jun 26 18:01:13 defiant kernel: ukbd1: at uhub2, port 4, addr 5 (disconnected)
Jun 26 18:01:13 defiant kernel: ukbd1: detached
Jun 26 18:01:13 defiant kernel: uhub2: detached
Jun 26 18:01:17 defiant kernel: ugen1.3:  at usbus1
Jun 26 18:01:17 defiant kernel: uhub2 on uhub1
Jun 26 18:01:17 defiant kernel: uhub2:  on usbus1
Jun 26 18:01:17 defiant kernel: uhub2: 4 ports with 4 removable, self powered
Jun 26 18:01:17 defiant kernel: ugen1.4:  at usbus1
Jun 26 18:01:17 defiant kernel: uhub3 on uhub1
Jun 26 18:01:17 defiant kernel: uhub3:  on usbus1
Jun 26 18:01:18 defiant kernel: uhub3: 4 ports with 4 removable, self powered
Jun 26 18:01:18 defiant kernel: ugen1.5:  at usbus1
Jun 26 18:01:18 defiant kernel: uaudio0 on uhub3
Jun 26 18:01:18 defiant kernel: uaudio0:  on usbus1
Jun 26 18:01:18 defiant webcamd[11677]: Webcamd is already running for ugen1.5.0
Jun 26 18:01:19 defiant kernel: uaudio0: No playback.
Jun 26 18:01:19 defiant kernel: uaudio0: Record[0]: 48000 Hz, 1 ch, 16-bit S-LE 
PCM format, 2x4ms buffer. (selected)
Jun 26 18:01:19 defiant kernel: uaudio0: Record[0]: 44100 Hz, 1 ch, 16-bit S-LE 
PCM format, 2x4ms buffer.
Jun 26 18:01:19 defiant kernel: uaudio0: Record[0]: 32000 Hz, 1 ch, 16-bit S-LE 
PCM format, 2x4ms buffer.
Jun 26 18:01:19 defiant kernel: uaudio0: Record[0]: 24000 Hz, 1 ch, 16-bit S-LE 
PCM format, 2x4ms buffer.
Jun 26 18:01:19 defiant kernel: uaudio0: Record[0]: 22050 Hz, 1 ch, 16-bit S-LE 
PCM format, 2x4ms buffer.
Jun 26 18:01:19 defiant kernel: uaudio0: Record[0]: 16000 Hz, 1 ch, 16-bit S-LE 
PCM format, 2x4ms buffer.
Jun 26 18:01:19 defiant kernel: uaudio0: Record[0]: 8000 Hz, 1 ch, 16-bit S-LE 
PCM format, 2x4ms buffer.
Jun 26 18:01:19 defiant kernel: uaudio0: No MIDI sequencer.
Jun 26 18:01:19 defiant kernel: pcm1 on uaudio0
Jun 26 18:01:19 defiant kernel: uaudio0: No HID volume keys found.
Jun 26 18:01:19 defiant pulseaudio[6791]: [] oss-util.c: '/dev/dsp1' doesn't 
support full duplex
Jun 26 18:01:19 defiant kernel: ugen1.6:  at 
usbus1
Jun 26 18:01:19 defiant kernel: ums0 on uhub3
Jun 26 18:01:19 defiant kernel: ums0:  on usbus1
Jun 26 18:01:19 defiant kernel: ums0: 3 buttons and [XYZ] coordinates ID=1
Jun 26 18:01:19 defiant kernel: ugen1.11:  at usbus1
Jun 26 18:01:19 defiant kernel: uftdi0 on uhub3
Jun 26 18:01:19 defiant kernel: uftdi0:  on usbus1
Jun 26 18:01:20 defiant kernel: ugen1.12:  at usbus1
Jun 26 18:01:20 defiant kernel: ukbd0 on uhub3
Jun 26 18:01:20 defiant kernel: ukbd0:  on usbus1
Jun 26 18:01:20 defiant kernel: kbd2 at ukbd0
Jun 26 18:01:20 defiant webcamd[11789]: webcamd: Cannot find USB device
Jun 26 18:01:20 defiant kernel: uhid0 on uhub3
Jun 26 18:01:20 defiant kernel: uhid0:  on usbus1
Jun 26 18:01:20 defiant kernel: ukbd1 on uhub3
Jun 26 18:01:20 defiant kernel: ukbd1:  on usbus1
Jun 26 18:01:20 defiant kernel: kbd3 at ukbd1

Re: June 2024 stabilization week

[Gleb Smirnoff]

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

The 5dbf886104b4 aka main-stabweek-2024-Jun passed regression A/B testing at
Netflix with no issues.

I also updated my desktops (using nVidia graphics) and home router to that
revision, also no issues noticed.

We have had a regression in the previous stabilization cycle, which went
unnoticed back then - the tpm(4) driver failed to attach on ACPI bus.   The
problem already fixed in main, but not in main-stabweek-2024-Jun!  Given that
TPM is still not a ubiquitous thing around, I decided not to create a branch
just to cherry pick that.  If using TPM you can either update all the way to
bbecd3148abf or cherry-pick that revision on top of main-stabweek-2024-Jun.

Unless we receive any regression report in this email thread until Wednesday
morning at 8:00 UTC, let's declare the stabilization cycle done by that time.

Thanks everyone!

-- 
Gleb Smirnoff

June 2024 stabilization week

[Gleb Smirnoff]

  Hi FreeBSD/main users & developers:

This is an automated email to inform you that the June 2024 stabilization week
started with FreeBSD/main at main-n270917-5dbf886104b4, which was tagged as
main-stabweek-2024-Jun.

The tag main-stabweek-2024-Jun 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

[LAST OFFICIAL 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: pax(1) looping infinitely

[Ganael Laplanche]

On 6/22/24 08:19, Warner Losh wrote:


The last core team announced one.

But you can add Approved by: imp


Thanks Warner! I've just committed the change.

Have a nice week-end,
Best regards,

--
Ganael LAPLANCHE 
http://www.martymac.org | http://contribs.martymac.org
FreeBSD: martymac , http://www.FreeBSD.org

Re: pax(1) looping infinitely

[Warner Losh]

The last core team announced one.

But you can add Approved by: imp

Warner


On Sat, Jun 22, 2024, 12:16 AM Ganael Laplanche <
ganael.laplan...@martymac.org> wrote:

>
>
> On 6/21/24 23:41, Yuri Pankov wrote:
>
> > .mailmap
>
> Thanks Yuri!
>
> I cannot see any blanket approval for a ports committer modifying that
> file within the src repo.
>
> Can a src committer approve (or commit) the following change please ? :
>
> diff --git a/.mailmap b/.mailmap
> index 0d0231a3da68..3d33acc8d59a 100644
> --- a/.mailmap
> +++ b/.mailmap
> @@ -16,3 +16,4 @@ Jose Luis Duran 
> 
>   Val Packett  
>   Piotr Paweł Stefaniak  
>   Sumit Saxena  
> +Ganael LAPLANCHE  
>
> Thanks in advance,
> Best regards,
>
> --
> Ganael LAPLANCHE 
> http://www.martymac.org | http://contribs.martymac.org
> FreeBSD: martymac , http://www.FreeBSD.org
>
>

Re: pax(1) looping infinitely

[Ganael Laplanche]

On 6/21/24 23:41, Yuri Pankov wrote:


.mailmap


Thanks Yuri!

I cannot see any blanket approval for a ports committer modifying that 
file within the src repo.


Can a src committer approve (or commit) the following change please ? :

diff --git a/.mailmap b/.mailmap
index 0d0231a3da68..3d33acc8d59a 100644
--- a/.mailmap
+++ b/.mailmap
@@ -16,3 +16,4 @@ Jose Luis Duran  


 Val Packett  
 Piotr Paweł Stefaniak  
 Sumit Saxena  
+Ganael LAPLANCHE  

Thanks in advance,
Best regards,

--
Ganael LAPLANCHE 
http://www.martymac.org | http://contribs.martymac.org
FreeBSD: martymac , http://www.FreeBSD.org

Re: pax(1) looping infinitely

[Yuri Pankov]

Ganael Laplanche wrote:
> 
> 
> Le 21/06/2024 à 18:58, Warner Losh a écrit :
> 
>> My apologies...  I didn't check, but. it's in your sig so I should
>> have. 
> 
> Hey, no pb :)
> 
>> There's a mapping file that can be updated for cases like this.
> 
> Hmmm, I could add my address there. Can you point me to that file, I
> can't find it in the source tree ?

mailmap

Re: pax(1) looping infinitely

[Ganael Laplanche]

Le 21/06/2024 à 18:58, Warner Losh a écrit :

My apologies...  I didn't check, but. it's in your sig so I should have. 



Hey, no pb :)


There's a mapping file that can be updated for cases like this.


Hmmm, I could add my address there. Can you point me to that file, I 
can't find it in the source tree ?


Cheers,

--
Ganael LAPLANCHE 
http://www.martymac.org | http://contribs.martymac.org
FreeBSD: martymac , http://www.FreeBSD.org

Re: pax(1) looping infinitely

[Warner Losh]

On Fri, Jun 21, 2024 at 10:55 AM Ganael Laplanche <
ganael.laplan...@martymac.org> wrote:

> On 6/21/24 18:44, Warner Losh wrote:
>
> Hi Warner,
>
> > Fixed.
>  >
> > commit 681fd2bed8eaba88693867ba928a1c03a5b152cc (HEAD -> main)
> > Author: Ganael Laplanche 
> Thanks!
>
> > Wrote the commit message and had to guess at the right email to use. But
> > it looked like bz and the mail here were the same.
>
> You could just have used my FreeBSD.org (martymac@) address here.
> Anyway, my personal address is OK too :)
>

My apologies...  I didn't check, but. it's in your sig so I should have.


There's a mapping file that can be updated for cases like this.


> > In the future, simple patches like this might work better as a github
> > pull request, though, since that would resolve all that ambiguity.
>
> Yep, thanks again!
>

You Bet. IT was an easy one to work with since the patch applied cleanly,
it clearly fixed the problem, (which I was able to reproduce and verify
things
were fixed), etc.

Warner


> Cheers,


> --

Ganael LAPLANCHE 

http://www.martymac.org | http://contribs.martymac.org

FreeBSD: martymac , http://www.FreeBSD.org

Re: pax(1) looping infinitely

[Ganael Laplanche]

On 6/21/24 18:44, Warner Losh wrote:

Hi Warner,


Fixed.

>

commit 681fd2bed8eaba88693867ba928a1c03a5b152cc (HEAD -> main)
Author: Ganael Laplanche 

Thanks!

Wrote the commit message and had to guess at the right email to use. But 
it looked like bz and the mail here were the same.


You could just have used my FreeBSD.org (martymac@) address here. 
Anyway, my personal address is OK too :)


In the future, simple patches like this might work better as a github 
pull request, though, since that would resolve all that ambiguity.


Yep, thanks again!

Cheers,

--
Ganael LAPLANCHE 
http://www.martymac.org | http://contribs.martymac.org
FreeBSD: martymac , http://www.FreeBSD.org

Re: pax(1) looping infinitely

[Warner Losh]

Fixed.

commit 681fd2bed8eaba88693867ba928a1c03a5b152cc (HEAD -> main)
Author: Ganael Laplanche 
Date:   Fri Jun 21 10:39:09 2024 -0600

pax: Terminate loop for empty directory names
..

Wrote the commit message and had to guess at the right email to use. But it
looked like bz and the mail here were the same.

In the future, simple patches like this might work better as a github pull
request, though, since that would resolve all that ambiguity.

Warner


On Fri, Jun 21, 2024 at 4:51 AM Ganael Laplanche <
ganael.laplan...@martymac.org> wrote:

> Hello,
>
> Our pax(1) implementation has a small bug triggered when it is fed with
> a directory containing a trailing slash.
>
> Could a src committer have a look at:
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277060
>
> ?
>
> I've submitted a small patch that fixes the problem.
>
> Thanks!
>
> Cheers,
>
> --
> Ganael LAPLANCHE 
> http://www.martymac.org | http://contribs.martymac.org
> FreeBSD: martymac , http://www.FreeBSD.org
>
>

Re: ncurses message spam

[Baptiste Daroussin]

On Fri 21 Jun 15:23, Shawn Webb wrote:
> Hey all,
> 
> With the recent changes to ncurses in base, I'm getting a bunch of
> messages (snippet below) on every single new PTY. Every time I open a
> new window in tmux or login via ssh, I'm getting spammed with a flood
> of messages like below.
> 
>  BEGIN LOG 
> Name collision 'tvi950-b' between
> tvi950-b|bare tvi950 no is
> and tvi950-b|bare tvi950 no is
> ...now  bare tvi950 no is 
> Cannot remove alias 'bare tvi950 no is'
> Name collision 'tvi950-ns' between
> tvi950-ns|tvi950 w/no standout
> and tvi950-ns|tvi950 w/no standout   
> ...now  tvi950 w/no standout  
> Cannot remove alias 'tvi950 w/no standout'
> Name collision 'tvi925' between
> tvi925|925|televideo model 925
> and tvi925|925|televideo model 925
> ...now  925|televideo model 925
> ...now  televideo model 925   
> Cannot remove alias 'televideo model 925'
> Name collision 'tvi925vb' between
> tvi925vb|925vb|televideo model 925 visual bells
> and tvi925vb|925vb|televideo model 925 visual bells
> ...now  925vb|televideo model 925 visual bells
> ...now  televideo model 925 visual bells   
> Cannot remove alias 'televideo model 925 visual bells'
> Name collision 'tvi925n' between  
>  
> tvi925n|925n|televideo model 925 no standout or underline
> and tvi925n|925n|televideo model 925 no standout or underline
> ...now  925n|televideo model 925 no standout or underline
> ...now  televideo model 925 no standout or underline
> Cannot remove alias 'televideo model 925 no standout or underline'
> Name collision 'tvi925vbn' between
> tvi925vbn|925vbn|televideo model 925 visual bells no so or ul
> and tvi925vbn|925vbn|televideo model 925 visual bells no so or ul
> ...now  925vbn|televideo model 925 visual bells no so or ul
> ...now  televideo model 925 visual bells no so or ul
> Cannot remove alias 'televideo model 925 visual bells no so or ul'
> Name collision '925a' between
> 925a|tvi925a|TeleVideo Model 925
> and 925a|tvi925a|TeleVideo Model 925
> ...now  tvi925a|TeleVideo Model 925
> ...now  TeleVideo Model 925 
> Cannot remove alias 'TeleVideo Model 925'
> Name collision 'tvi950' between   
>   
>   
> tvi950|950|televideo950
> and tvi950|950|televideo950   
>   
>   
> ...now  950|televideo950  
>   
>   
> ...now  televideo950  
>   
>   
> Cannot remove alias 'televideo950'
>  END LOG 
> 
> 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



Do your sync again, this has been fixed a few hours after the ncurses 6.5
upgrade

Bapt

ncurses message spam

[Shawn Webb]

Hey all,

With the recent changes to ncurses in base, I'm getting a bunch of
messages (snippet below) on every single new PTY. Every time I open a
new window in tmux or login via ssh, I'm getting spammed with a flood
of messages like below.

 BEGIN LOG 
Name collision 'tvi950-b' between
tvi950-b|bare tvi950 no is
and tvi950-b|bare tvi950 no is
...now  bare tvi950 no is 
Cannot remove alias 'bare tvi950 no is'
Name collision 'tvi950-ns' between
tvi950-ns|tvi950 w/no standout
and tvi950-ns|tvi950 w/no standout   
...now  tvi950 w/no standout  
Cannot remove alias 'tvi950 w/no standout'
Name collision 'tvi925' between
tvi925|925|televideo model 925
and tvi925|925|televideo model 925
...now  925|televideo model 925
...now  televideo model 925   
Cannot remove alias 'televideo model 925'
Name collision 'tvi925vb' between
tvi925vb|925vb|televideo model 925 visual bells
and tvi925vb|925vb|televideo model 925 visual bells
...now  925vb|televideo model 925 visual bells
...now  televideo model 925 visual bells   
Cannot remove alias 'televideo model 925 visual bells'
Name collision 'tvi925n' between
   
tvi925n|925n|televideo model 925 no standout or underline
and tvi925n|925n|televideo model 925 no standout or underline
...now  925n|televideo model 925 no standout or underline
...now  televideo model 925 no standout or underline
Cannot remove alias 'televideo model 925 no standout or underline'
Name collision 'tvi925vbn' between
tvi925vbn|925vbn|televideo model 925 visual bells no so or ul
and tvi925vbn|925vbn|televideo model 925 visual bells no so or ul
...now  925vbn|televideo model 925 visual bells no so or ul
...now  televideo model 925 visual bells no so or ul
Cannot remove alias 'televideo model 925 visual bells no so or ul'
Name collision '925a' between
925a|tvi925a|TeleVideo Model 925
and 925a|tvi925a|TeleVideo Model 925
...now  tvi925a|TeleVideo Model 925
...now  TeleVideo Model 925 
Cannot remove alias 'TeleVideo Model 925'
Name collision 'tvi950' between 

  
tvi950|950|televideo950
and tvi950|950|televideo950 

  
...now  950|televideo950

  
...now  televideo950

  
Cannot remove alias 'televideo950'
 END LOG 

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

pax(1) looping infinitely

[Ganael Laplanche]

Hello,

Our pax(1) implementation has a small bug triggered when it is fed with 
a directory containing a trailing slash.


Could a src committer have a look at:

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

?

I've submitted a small patch that fixes the problem.

Thanks!

Cheers,

--
Ganael LAPLANCHE 
http://www.martymac.org | http://contribs.martymac.org
FreeBSD: martymac , http://www.FreeBSD.org

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