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

[Chris]

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

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

ifconfig_bla0="192.168.87.11"

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

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

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

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

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

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

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

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

10/8
172.16/12
192.168/16

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

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

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

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



Poul-Henning

--Chris

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

[Ed Maste]

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

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

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

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

[Michael Gmelin]

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

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

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

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

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

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

So this is simply a bug.

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

Best
Michael

-- 
Michael Gmelin

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

[Poul-Henning Kamp]

Michael Gmelin writes:

> @phk From which version did you upgrade?

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

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

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

[Michael Gmelin]

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

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

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

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

@phk From which version did you upgrade?

Best

-- 
Michael Gmelin

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

[Bjoern A. Zeeb]

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


On Wed, 12 Jun 2024, Michael Gmelin wrote:




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



Bjoern A. Zeeb writes:


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

ifconfig_bla0="192.168.87.11"

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


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

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


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



I just tried on 14.0-p6, same there:

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

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

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


No it pre-dates that chnage.

It goes back to d8237b95552807e937fc389c7e2237679ef0c984 and related
changes.


Sorry I hit send too early

And I think it came out of

commit 2f35e7d9fa03f27543f347cd6277af5bfc6a7e95
commit 20d59403961d531467cfab22163f49c131cc8b55

--
Bjoern A. Zeeb r15:7

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

[Bjoern A. Zeeb]

On Wed, 12 Jun 2024, Michael Gmelin wrote:




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



Bjoern A. Zeeb writes:


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

ifconfig_bla0="192.168.87.11"

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


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

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


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



I just tried on 14.0-p6, same there:

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

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

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


No it pre-dates that chnage.

It goes back to d8237b95552807e937fc389c7e2237679ef0c984 and related
changes.

--
Bjoern A. Zeeb r15:7

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

[Michael Gmelin]

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

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

I just tried on 14.0-p6, same there:

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

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

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

-m

-- 
Michael Gmelin

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

[Poul-Henning Kamp]

Rodney W. Grimes writes:

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

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

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

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

[Rodney W. Grimes]

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

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

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

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

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

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

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

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

[Poul-Henning Kamp]

Bjoern A. Zeeb writes:

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

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

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

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

[Bjoern A. Zeeb]

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


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

ifconfig_bla0="192.168.87.11"

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


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

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

--
Bjoern A. Zeeb r15:7

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

[Bob Bishop]

Hi,

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

+1

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

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

[Ronald Klop]

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


Ronald Klop writes:

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

I dont think that will work ?

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

Poul-Henning

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






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

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

Regards,
Ronald.

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

[Michael Gmelin]

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

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

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

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

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

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

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

Agreed.

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

Agreed as well.

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

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

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

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

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

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

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

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

Best
Michael

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

-- 
Michael Gmelin

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

[Poul-Henning Kamp]

Michael Gmelin writes:

> You can do an interface route hack

I think you misunderstand the situation.

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

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

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

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

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

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

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

[Michael Gmelin]

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

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

You can do an interface route hack

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

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

Cheers

-- 
Michael Gmelin

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

[Poul-Henning Kamp]

Ronald Klop writes:

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

I dont think that will work ?

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

Poul-Henning

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

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

[Ronald Klop]

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


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

ifconfig_bla0="192.168.87.11"

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

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

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

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

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

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

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

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

10/8
172.16/12
192.168/16

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

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

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

Poul-Henning

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







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

Regards,
Ronald.

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

[Poul-Henning Kamp]

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

ifconfig_bla0="192.168.87.11"

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

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

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

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

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

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

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

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

10/8
172.16/12
192.168/16

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

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

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

Poul-Henning

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

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

[Tomoaki AOKI]

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

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

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

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

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

-- 
Tomoaki AOKI

Re: 41dfea24eec panics during ata attach on ESXi VM

[John Baldwin]

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

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

ata0:  at channel 0 on atapci0


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

--
John Baldwin

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

[Gleb Popov]

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

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

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

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

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

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

[Miroslav Lachman]

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


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


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


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


Best regards
Miroslav Lachman

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

[Rick Macklem]

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

rick

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

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

[Alan Somers]

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

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

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

[John Hixson]

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

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

- John


signature.asc
Description: PGP signature

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

[Miroslav Lachman]

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

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

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

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

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


[...]



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

rick


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

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

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


I'm glad to hear that.


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

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

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


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



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

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


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


Best regards
Miroslav Lachman

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

[John Hixson]

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

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

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

- John


signature.asc
Description: PGP signature

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

[John Baldwin]

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

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

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

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

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

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


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


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

Is that expected behavior ?

I have not tried Linux version of gcc.


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


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

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


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

--
John Baldwin

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

[FreeBSD User]

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

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

Hello Alexander and everybody brave enough reading my post.

Somehow I managed it to let 

"ifconfig_igb1="up"

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

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

Kind regards,

oh

-- 
O. Hartmann


pgpEjETT1Jdg5.pgp
Description: OpenPGP digital signature

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

[Warner Losh]

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

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

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

Warner


> cu
>   Gerrit
>

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

[Gerrit Kühn]

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

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

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

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


cu
  Gerrit


smime.p7s
Description: S/MIME cryptographic signature

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

[Santiago Martinez]

Hi everyone, just to follow up.

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


I have found the following:

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


echo "Creating Interfaces and brick the card"

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

--- then destroy and shutdown bnxt1 ---

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


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

This is tested against main from yesterday.

Best regards.

Santi


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

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


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

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

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


cu
   Gerrit

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

[Alexander Leidinger]

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

Hello,

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

bridge is performed by the jail.conf script.

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


I check all setups for net.link.bridge:

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

I did not change anything (knowingly).

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

working as expected.

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

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


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


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

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


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


Bye,
Alexander.

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


signature.asc
Description: OpenPGP digital signature

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

[Zhenlei Huang]

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

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

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

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

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

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

Best regards,
Zhenlei

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

[FreeBSD User]

Hello,

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

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

I check all setups for net.link.bridge:

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

I did not change anything (knowingly). 

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

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

Maybe someone has a clue what might break the bridge.

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

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

Kind regards

oh

-- 
O. Hartmann

Call for 2024Q2 status reports

[Lorenzo Salvadore]

Dear FreeBSD Community,

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

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

The following methods are available to submit your reports:

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

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

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

An AsciiDoc template is available at
.

We look forward to seeing your 2024Q2 reports!

Thanks,

Lorenzo Salvadore (on behalf of status@)

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

[Cy Schubert]

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


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

e^(i*pi)+1=0


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

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

[Cy Schubert]

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

Re: May 2024 stabilization week

[void]

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

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


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

Might be relevant:

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

   installworld. i didn't do that.
--

Re: May 2024 stabilization week

[Mike Karels]

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

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

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

Mike

Re: May 2024 stabilization week

[void]

Hi Mike,

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

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


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


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


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

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


There is a new version of pkg that corrects this.


Unsure what you mean - how would pkg be involved?

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

The issue occured after a source build of cca0ce62f367
--

Re: May 2024 stabilization week

[Service Aktionheizung]

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

i...@aktionheizung.de

Submit information exclusively to this E -Mail address. Thanks


-

Am 01.06.2024 um 14:06 schrieb Mike Karels:

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


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


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

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

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

There is a new version of pkg that corrects this.

Mike

Re: May 2024 stabilization week

[Mike Karels]

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

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

There is a new version of pkg that corrects this.

Mike

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

[Nuno Teixeira]

(...)

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

Redefine CLOCK_BOOTTIME to alias CLOCK_MONOTONIC, not CLOCK_UPTIME

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

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

mesa-dri-24.0.8 failing to build on d1bd097d52cb

[Nuno Teixeira]

Hello all,

Anyone seeing this error on main?

Thanks

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

Re: May 2024 stabilization week

[void]

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


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


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

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

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

[Gary Jennejohn]

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

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

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

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

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

--
Gary Jennejohn

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

[FreeBSD User]

Hello,

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

include GENERIC
include NODEVICE-GENERIC
include SPECIAL

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

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

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

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

Thanks in advance,

oh



-- 
O. Hartmann

Re: May 2024 stabilization week

[Gleb Smirnoff]

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

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

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

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

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

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

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

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

-- 
Gleb Smirnoff

Re: May 2024 stabilization week

[void]

Hi Gleb,

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


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


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

--

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

[Gerrit Kühn]

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

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

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

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


cu
  Gerrit


smime.p7s
Description: S/MIME cryptographic signature

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

[Santiago Martinez]

Hi!

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


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

I will keep you posted.

Santi


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

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


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

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


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

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


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

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


cu
   Gerrit

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

[Gerrit Kühn]

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

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

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

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

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

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

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


cu
  Gerrit


smime.p7s
Description: S/MIME cryptographic signature

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

[Santiago Martinez]

Hi Gerrit,

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


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

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


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


Santi

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

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


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

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


cu
   Gerrit

Re: May 2024 stabilization week

[Alexander Leidinger]

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

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

T> main-stabweek-2024-May.

Monday night status update:

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

Regressions I am aware of and tracking:

- Linuxulator too strict on Netlink (PR 279012)

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


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


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


Bye,
Alexander.

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


signature.asc
Description: OpenPGP digital signature

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

[Gerrit Kühn]

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

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

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


cu
  Gerrit


smime.p7s
Description: S/MIME cryptographic signature

Re: May 2024 stabilization week

[Gleb Smirnoff]

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

Monday night status update:

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

Regressions I am aware of and tracking:

- Linuxulator too strict on Netlink (PR 279012)

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

-- 
Gleb Smirnoff

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

[Warner Losh]

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

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

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

Warner

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

[Warner Losh]

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

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

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

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

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

Warner


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

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

[Santiago Martinez]

Hi Everyone,

Just wondering if anyone has any contact at broadcom.

The bnxt drivers on 14.1BETA1 are unusable.

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


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

Best regards.

Santiago


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

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

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

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


sysctl:

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

[HEADSUP] broken kernels for head this week for pkgbase

[Baptiste Daroussin]

Hello,

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

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

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

Best regards,
Bapt

May 2024 stabilization week

[Gleb Smirnoff]

  Hi FreeBSD/main users & developers:

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

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

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

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

--
Gleb Smirnoff

Re: CURRENT kernel crash beyond git: 02d15215cef2

[Graham Perrin]

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

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


A few hours earlier:

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


HTH

Re: main cadd2ca217 doesn't boot

[FreeBSD User]

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

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

The patch fixes the problem on amd64 here ...

-- 
O. Hartmann

Re: main cadd2ca217 doesn't boot

[David Wolfskill]

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

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

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

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

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

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

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

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

Thanks!

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

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


signature.asc
Description: PGP signature

Re: CURRENT kernel crash beyond git: 02d15215cef2

[FreeBSD User]

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

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

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

Sorry for the noise,

Thanks and kind regards
oh

-- 
O. Hartmann

Re: CURRENT kernel crash beyond git: 02d15215cef2

[Herbert J. Skuhra]

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

Check the archive! Known issue:

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

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

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

-- 
Herbert 

Re: main cadd2ca217 doesn't boot

[Oleg Nauman]

Hello,

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

Thank you

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

Re: main cadd2ca217 doesn't boot

[tuexen]

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

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

Best regards
Michael
> 
> Bojan
> 

Re: main cadd2ca217 doesn't boot

[Bojan Novković]

Hi,

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


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


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

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

Re: main cadd2ca217 doesn't boot

[Ryan Libby]

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

I'm on amd64 running GENERIC.

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

This doesn't:
da76d349b6b1 uma: Deduplicate uma_small_alloc

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

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

Probably want to back this out until stabilized.

Ryan

Re: main cadd2ca217 doesn't boot

[Tomoaki AOKI]

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

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

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

Regards.

-- 
Tomoaki AOKI

main cadd2ca217 doesn't boot

[Nuno Teixeira]

Hello,

Just upgraded to latest main at cadd2ca217

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

No crash dump.

Thanks,

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

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

[Ryan Libby]

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

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

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

Ryan

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

[Alexander Leidinger]

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


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


First order:

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

with a bad lock held and boop.

Can you reproduce this?


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



If so, can you test this patch?


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


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


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


Bye,
Alexander.

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

signature.asc
Description: OpenPGP digital signature

panic: lock "tmpfsni" 0xfffff80721307090 already initialized

[Alexander Leidinger]

Hi,

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

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

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

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

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

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

[123095] Uptime: 1d10h11m35s

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

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

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

Bye,
Alexander.

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


signature.asc
Description: OpenPGP digital signature

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

[Ed Maste]

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

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

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

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

[Matteo Riondato]

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

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

Thanks,
Matteo

Re: bsdinstall wifi setup is broken on CURRENT

[Renato Botelho]

On 18/05/24 11:33, Alfonso S. Siciliano wrote:

On 5/16/24 20:40, Renato Botelho wrote:
I saw some users on a .br group complaining bsdinstall was failing to 
setup wifi network on 15.0 snapshots and tried it myself.  I was able 
to reproduce the problem and also noticed another one.




Thank you for your report, the video is highly appreciated to understand 
the problem quickly and exactly.


I noticed Network Selection screen only shows one line, it's not 
beautiful to navigate through items this way.  On 14.1-BETA2 it shows 
multiple lines so it seems to be a regression.


Problem 1. Looking at wlanconfig it seems related to $height $width 
$rows for the selecting menu. Please could you open a PR adding me, so 
we can test and solve.




The problem users reported was: after selecting desired network it 
just starts over instead of asking for password.  I made a video [1] 
showing the problem.


Problem 2. I know this issue about --mixedform, my last import 2 day ago 
should solve a6d8be451f62d425b71a4874f7d4e133b9fb393c.
You could try the last main snapshot (yesterday 17 May), please let me 
know any problem.


I confirmed it is fixed with bsddialog 1.0.2 but I found another issue 
while testing.


Instead of password, it was adding SSID to psk field of 
wpa_supplicant.conf.  I've created following review to address that


https://reviews.freebsd.org/D45344

Thanks!
--
Renato Botelho

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

[Dimitry Andric]

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

In lib/libc/rpc/Symbol.map there is:

/* From yp_xdr.c (generated by rpcgen - include/rpcsvc/yp.x) */
xdr_domainname;
xdr_keydat;

so maybe the rpcgen step went wrong somehow? Do you have WITHOUT_NIS enabled?

-Dimitry

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

[Matteo Riondato]

Hi All,

I’m trying to build 59aa64914aeb1b20d4fc39ead2ee159a1e5b from 
main-62adeb92df, and got the error below.

I cannot immediately trace it back to any recent commit, so I’m a bit surprised 
by it.

Any hint?

--
>>> stage 4.2: building libraries
--
cd /usr/src;  time env MACHINE_ARCH=amd64  MACHINE=amd64  
CPUTYPE=skylake-avx512 BUILD_TOOLS_META=.NOMETA CC="/usr/local/bin/ccache cc 
-target x86_64-unknown-freebsd15.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp 
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin" CXX="/usr/local/bin/ccache c++  
-target x86_64-unknown-freebsd15.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp 
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin"  CPP="cpp -target 
x86_64-unknown-freebsd15.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp 
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin"  AS="as" AR="ar" ELFCTL="elfctl" 
LD="ld"  LLVM_LINK="" NM=nm OBJCOPY="objcopy"  RANLIB=ranlib STRINGS=  
SIZE="size" STRIPBIN="strip"  INSTALL="install -U"  
PATH=/usr/obj/usr/src/amd64.amd64/tmp/bin:/usr/obj/usr/src/amd64.amd64/tmp/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin
  SYSROOT=/usr/obj/usr/src/amd64.amd64/tmp make  -f Makefile.inc1  
BWPHASE=libraries  DESTDIR=/usr/obj/usr/src/amd64.amd64/tmp -DNO_FSCHG 
MK_HTML=no -DNO_LINT MK_MAN=no  MK_PROFILE=no MK_TESTS=no MK_TESTS_SUPPORT=no  
libraries
cd /usr/src;  make -f Makefile.inc1 _prereq_libs;  make -f Makefile.inc1 
_startup_libs;  make -f Makefile.inc1 _prebuild_libs 
-DLIBCRYPTO_WITHOUT_SUBDIRS;  make -f Makefile.inc1 _generic_libs
Building /usr/obj/usr/src/amd64.amd64/lib/libcompiler_rt/_libinstall
Building /usr/obj/usr/src/amd64.amd64/lib/libcompiler_rt/_installlinks
Building /usr/obj/usr/src/amd64.amd64/lib/libssp_nonshared/_libinstall
Building /usr/obj/usr/src/amd64.amd64/lib/libgcc_eh/_libinstall
Building /usr/obj/usr/src/amd64.amd64/lib/libgcc_eh/_INCSINS
installing DIRS FILESDIR
install -U  -d -m 0755 -o root  -g wheel  
/usr/obj/usr/src/amd64.amd64/tmp/usr/lib
Building /usr/obj/usr/src/amd64.amd64/lib/csu/amd64/_FILESINS_Scrt1.o
Building /usr/obj/usr/src/amd64.amd64/lib/csu/amd64/_FILESINS_crt1.o
Building /usr/obj/usr/src/amd64.amd64/lib/csu/amd64/_FILESINS_gcrt1.o
Building /usr/obj/usr/src/amd64.amd64/lib/csu/amd64/_FILESINS_crtbegin.o
Building /usr/obj/usr/src/amd64.amd64/lib/csu/amd64/_FILESINS_crtbeginS.o
Building /usr/obj/usr/src/amd64.amd64/lib/csu/amd64/_FILESINS_crtbeginT.o
Building /usr/obj/usr/src/amd64.amd64/lib/csu/amd64/_FILESINS_crtend.o
Building /usr/obj/usr/src/amd64.amd64/lib/csu/amd64/_FILESINS_crtendS.o
Building /usr/obj/usr/src/amd64.amd64/lib/csu/amd64/_FILESINS_crti.o
Building /usr/obj/usr/src/amd64.amd64/lib/csu/amd64/_FILESINS_crtn.o
Building /usr/obj/usr/src/amd64.amd64/lib/libsys/_libinstall
Building /usr/obj/usr/src/amd64.amd64/lib/libsys/_INCSINS
Building /usr/obj/usr/src/amd64.amd64/lib/libc/libc.so.7
building shared library libc.so.7
ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_domainname' 
failed: symbol not defined
ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_keydat' 
failed: symbol not defined
ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_mapname' 
failed: symbol not defined
ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_peername' 
failed: symbol not defined
ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_valdat' 
failed: symbol not defined
ld: error: version script assignment of 'FBSD_1.0' to symbol 
'xdr_ypbind_binding' failed: symbol not defined
ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_ypbind_resp' 
failed: symbol not defined
ld: error: version script assignment of 'FBSD_1.0' to symbol 
'xdr_ypbind_resptype' failed: symbol not defined
ld: error: version script assignment of 'FBSD_1.0' to symbol 
'xdr_ypbind_setdom' failed: symbol not defined
ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_ypmap_parms' 
failed: symbol not defined
ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_ypmaplist' 
failed: symbol not defined
ld: error: version script assignment of 'FBSD_1.0' to symbol 
'xdr_yppush_status' failed: symbol not defined
ld: error: version script assignment of 'FBSD_1.0' to symbol 
'xdr_yppushresp_xfr' failed: symbol not defined
ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_ypreq_key' 
failed: symbol not defined
ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_ypreq_nokey' 
failed: symbol not defined
ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_ypreq_xfr' 
failed: symbol not defined
ld: error: version script assignment of 'FBSD_1.0' to symbol 

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

[Alexander Leidinger]

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


First order:

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

with a bad lock held and boop.

Can you reproduce this?


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



If so, can you test this patch?


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


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


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

Chromium with Widevine: kernel panic: condition vp->v_type == VDIR || VN_IS_DOOMED(vp) not met ⋯vfs_cache.c:3452 (vn_fullpath_dir)

[Graham Perrin]

Reproducible at .

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

[Warner Losh]

First order:

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

Can you reproduce this?

If so, can you test this patch?

diff --git a/sys/cam/nvme/nvme_da.c b/sys/cam/nvme/nvme_da.c
index 3f6cf8702870..357e612200e9 100644
--- a/sys/cam/nvme/nvme_da.c
+++ b/sys/cam/nvme/nvme_da.c
@@ -1077,7 +1077,9 @@ ndastart(struct cam_periph *periph, union ccb
*start_ccb)

trim = malloc(sizeof(*trim), M_NVMEDA, M_ZERO |
M_NOWAIT);
if (trim == NULL) {
+ cam_periph_unlock(periph);
biofinish(bp, NULL, ENOMEM);
+ cam_periph_lock(periph);
xpt_release_ccb(start_ccb);
ndaschedule(periph);
return;

(the mailer may mangle it, so I've also attached it in case people want to
comment on this).

The logic here is that we have special logic in the ENOMEM case that will
recursively
call the start routine, which calls the scheduler which expects to be able
to take out the
periph lock. But it can't, because it's already locked. It also invokes a
pacing protocol that
slows down things even more.

What I'm now not sure about is whether or not we need to just release
start_ccb or if we also need to call ndaschedule too here. Seems like we
might not want to (but it's a safe nop if not). I've cc'd mav@ to see if he
has opinions on what's going on.

Warner


On Wed, May 22, 2024 at 11:22 AM Alexander Leidinger <
alexan...@leidinger.net> wrote:

> Hi,
>
> I got the panic in $Subject. Anyone an idea?
>
> Complete crashlog available at https://wiki.leidinger.net/core.txt.6
> (1.2 MB)
>
> Short version:
> ---snip---
> [11417] KDB: stack backtrace:
> [11417] db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> 0xfe043133f830
> [11417] vpanic() at vpanic+0x13f/frame 0xfe043133f960
> [11417] panic() at panic+0x43/frame 0xfe043133f9c0
> [11417] __mtx_lock_sleep() at __mtx_lock_sleep+0x491/frame
> 0xfe043133fa50
> [11417] __mtx_lock_flags() at __mtx_lock_flags+0x9c/frame
> 0xfe043133fa70
> [11417] ndastrategy() at ndastrategy+0x3c/frame 0xfe043133faa0
> [11417] g_disk_start() at g_disk_start+0x569/frame 0xfe043133fb00
> [11417] g_io_request() at g_io_request+0x2b6/frame 0xfe043133fb30
> [11417] g_io_deliver() at g_io_deliver+0x1cc/frame 0xfe043133fb80
> [11417] g_disk_done() at g_disk_done+0xee/frame 0xfe043133fbc0
> [11417] ndastart() at ndastart+0x4a3/frame 0xfe043133fc20
> [11417] xpt_run_allocq() at xpt_run_allocq+0xa5/frame 0xfe043133fc70
> [11417] ndastrategy() at ndastrategy+0x6d/frame 0xfe043133fca0
> [11417] g_disk_start() at g_disk_start+0x569/frame 0xfe043133fd00
> [11417] g_io_request() at g_io_request+0x2b6/frame 0xfe043133fd30
> [11417] g_io_request() at g_io_request+0x2b6/frame 0xfe043133fd60
> [11417] g_io_request() at g_io_request+0x2b6/frame 0xfe043133fd90
> [11417] vdev_geom_io_start() at vdev_geom_io_start+0x257/frame
> 0xfe043133fdc0
> [11417] zio_vdev_io_start() at zio_vdev_io_start+0x321/frame
> 0xfe043133fe10
> [11417] zio_execute() at zio_execute+0x78/frame 0xfe043133fe40
> [11417] taskqueue_run_locked() at taskqueue_run_locked+0x1c7/frame
> 0xfe043133fec0
> [11417] taskqueue_thread_loop() at taskqueue_thread_loop+0xd3/frame
> 0xfe043133fef0
> ---snip---
>
> This is with a world from 2024-05-17-084543.
>
> Bye,
> Alexander.
>
> --
> http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
> http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF
>
diff --git a/sys/cam/nvme/nvme_da.c b/sys/cam/nvme/nvme_da.c
index 3f6cf8702870..357e612200e9 100644
--- a/sys/cam/nvme/nvme_da.c
+++ b/sys/cam/nvme/nvme_da.c
@@ -1077,7 +1077,9 @@ ndastart(struct cam_periph *periph, union ccb *start_ccb)
 
 			trim = malloc(sizeof(*trim), M_NVMEDA, M_ZERO | M_NOWAIT);
 			if (trim == NULL) {
+cam_periph_unlock(periph);
 biofinish(bp, NULL, ENOMEM);
+cam_periph_lock(periph);
 xpt_release_ccb(start_ccb);
 ndaschedule(periph);
 return;

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

[Alexander Leidinger]

Hi,

I got the panic in $Subject. Anyone an idea?

Complete crashlog available at https://wiki.leidinger.net/core.txt.6 
(1.2 MB)


Short version:
---snip---
[11417] KDB: stack backtrace:
[11417] db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
0xfe043133f830

[11417] vpanic() at vpanic+0x13f/frame 0xfe043133f960
[11417] panic() at panic+0x43/frame 0xfe043133f9c0
[11417] __mtx_lock_sleep() at __mtx_lock_sleep+0x491/frame 
0xfe043133fa50
[11417] __mtx_lock_flags() at __mtx_lock_flags+0x9c/frame 
0xfe043133fa70

[11417] ndastrategy() at ndastrategy+0x3c/frame 0xfe043133faa0
[11417] g_disk_start() at g_disk_start+0x569/frame 0xfe043133fb00
[11417] g_io_request() at g_io_request+0x2b6/frame 0xfe043133fb30
[11417] g_io_deliver() at g_io_deliver+0x1cc/frame 0xfe043133fb80
[11417] g_disk_done() at g_disk_done+0xee/frame 0xfe043133fbc0
[11417] ndastart() at ndastart+0x4a3/frame 0xfe043133fc20
[11417] xpt_run_allocq() at xpt_run_allocq+0xa5/frame 0xfe043133fc70
[11417] ndastrategy() at ndastrategy+0x6d/frame 0xfe043133fca0
[11417] g_disk_start() at g_disk_start+0x569/frame 0xfe043133fd00
[11417] g_io_request() at g_io_request+0x2b6/frame 0xfe043133fd30
[11417] g_io_request() at g_io_request+0x2b6/frame 0xfe043133fd60
[11417] g_io_request() at g_io_request+0x2b6/frame 0xfe043133fd90
[11417] vdev_geom_io_start() at vdev_geom_io_start+0x257/frame 
0xfe043133fdc0
[11417] zio_vdev_io_start() at zio_vdev_io_start+0x321/frame 
0xfe043133fe10

[11417] zio_execute() at zio_execute+0x78/frame 0xfe043133fe40
[11417] taskqueue_run_locked() at taskqueue_run_locked+0x1c7/frame 
0xfe043133fec0
[11417] taskqueue_thread_loop() at taskqueue_thread_loop+0xd3/frame 
0xfe043133fef0

---snip---

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

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: __memcpy_chk family of functions

[Dag-Erling Smørgrav]

Marcin Cieslak  writes:
> Dag-Erling Smørgrav  writes:
> > Marcin Cieslak  writes:
> > > I think this (useful) change should go into the future release
> > > notes as a new feature.
> > Which change?
> https://reviews.freebsd.org/D32306 Import _FORTIFY_SOURCE
> implementation from NetBSD which introduced _memcpy_chk and friends to
> our libc.

See commit 9bfd3b4076a7 which has “Relnotes: yes”.  It will be added to
the 15.0 release notes in due time, possibly 14.2 as well if Kyle
decides to merge it.

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

Re: __memcpy_chk family of functions

[Marcin Cieslak]

On Tue, 21 May 2024, Dag-Erling Smørgrav wrote:


Marcin Cieslak  writes:

I think this (useful) change should go into the future release notes
as a new feature.


Which change?


https://reviews.freebsd.org/D32306 Import _FORTIFY_SOURCE implementation from 
NetBSD
which introduced _memcpy_chk and friends to our libc.

Re: __memcpy_chk family of functions

[Dag-Erling Smørgrav]

Marcin Cieslak  writes:
> I think this (useful) change should go into the future release notes
> as a new feature.

Which change?

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

Re: __memcpy_chk family of functions

[Marcin Cieslak]

On Tue, May 21, 2024 at 12:16 AM Dag-Erling Smørgrav 
wrote:


The purpose of UPDATING is to document changes that break backward
compatibility, i.e. running old binaries on a newer world.
happened here is that you tried to run newer binaries on an older world,


On Tue, 21 May 2024, Warner Losh wrote:


Also, our forward compatibility guarantees are extremely weak.


Just for clarification: I am not complaining about my breakage.
It was my stunt and it didn't work out, I got punished by
sitting there and waiting for llvm to compile.

I think this (useful) change should go into the future release notes
as a new feature. Where and how should this be documented?
Shall FreeBSD_version be bumped for this one?

For example, when libsys got introduced, we could learn about
this from the UPDATING file. I do not want UPDATING to be come
unreadable or a copy of git log, though.

Marcin

Re: __memcpy_chk family of functions

[Warner Losh]

On Tue, May 21, 2024 at 12:16 AM Dag-Erling Smørgrav 
wrote:

> Marcin Cieslak  writes:
> > I have updated some binary packages using pkg(8) but neglected to
> > rebuild the world and my favourite web browsers no longer started
> > complaining about the undefined symbol __memcpy_chk@FBSD_1.8
> >
> > Would that be a good idea to add that information to the Handbook and
> > possible bump FreeBSD_version and add this info to UPDATING?
>
> The purpose of UPDATING is to document changes that break backward
> compatibility, i.e. running old binaries on a newer world.  What
> happened here is that you tried to run newer binaries on an older world,
> an issue of _forward_ compatibility, which we've never promised.
> Besides, an entry in UPDATING wouldn't have helped you since your source
> tree predated the change that would have added it.
>

Also, our forward compatibility guarantees are extremely weak.  At most the
outer
bounds are around a sliding window to upgrade from source, using root in
single user
on the console. So having to revert to an old kernel to build a new kernel
when there's
a problem, or having to revert to an old kernel to rebuild old sources. And
even then
it's not something we test, so it's likely broken or broken once you get a
hair's width
away from that path. Plus, with BEs and the easy ability to roll back to
the prior BE,
even this level of forward compat is likely to decay further in the future.

Warner

Re: devd nomatch does not load uslcom anymore

[Warner Losh]

On Tue, May 21, 2024, 1:38 AM Ronald Klop  wrote:

> Hi,
>
> May 16th upgraded the kernel of my RPI4. Previous kernel was fom April
> 10th.
>
> From:
> FreeBSD 15.0-CURRENT #35 main-5716d902ae1: Wed Apr 10 22:59:37 CEST 2024
>
> To:
> FreeBSD 15.0-CURRENT #36 main-42b28f81521: Thu May 16 07:54:05 CEST 2024
>
> Today I noticed my USB serial cable to my RPI3 was not available anymore.
> It hadn't loaded 'uslcom' at boot.
> Adding 'hw.bus.devctl_nomatch_enabled=1' to /boot/loader.conf resolves the
> issue for now.
>
> The proper output during boot is:
> Starting devd.
> Autoloading module: uslcom
> uslcom0 on uhub1
> uslcom0:  rev 1.10/1.00, addr 2> on usbus0
>
> Does anybody need more information about this?
>

I committed a fix a couple of days ago that defaults to always generating
the events.

Or were you wanting a deep dive on usb?

Warner

Regards,
> Ronald.
>
>

devd nomatch does not load uslcom anymore

[Ronald Klop]

Hi,

May 16th upgraded the kernel of my RPI4. Previous kernel was fom April 10th.

From:
FreeBSD 15.0-CURRENT #35 main-5716d902ae1: Wed Apr 10 22:59:37 CEST 2024

To:
FreeBSD 15.0-CURRENT #36 main-42b28f81521: Thu May 16 07:54:05 CEST 2024

Today I noticed my USB serial cable to my RPI3 was not available anymore. It 
hadn't loaded 'uslcom' at boot.
Adding 'hw.bus.devctl_nomatch_enabled=1' to /boot/loader.conf resolves the 
issue for now.

The proper output during boot is:
Starting devd.
Autoloading module: uslcom
uslcom0 on uhub1
uslcom0:  on usbus0

Does anybody need more information about this?

Regards,
Ronald.

Re: __memcpy_chk family of functions

[Dag-Erling Smørgrav]

Marcin Cieslak  writes:
> I have updated some binary packages using pkg(8) but neglected to
> rebuild the world and my favourite web browsers no longer started
> complaining about the undefined symbol __memcpy_chk@FBSD_1.8
>
> Would that be a good idea to add that information to the Handbook and
> possible bump FreeBSD_version and add this info to UPDATING?

The purpose of UPDATING is to document changes that break backward
compatibility, i.e. running old binaries on a newer world.  What
happened here is that you tried to run newer binaries on an older world,
an issue of _forward_ compatibility, which we've never promised.
Besides, an entry in UPDATING wouldn't have helped you since your source
tree predated the change that would have added it.

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

__memcpy_chk family of functions

[Marcin Cieslak]

Hello,

I have updated some binary packages using pkg(8)
but neglected to rebuild the world and my favourite
web browsers no longer started complaining
about the undefined symbol __memcpy_chk@FBSD_1.8

Would that be a good idea to add that information
to the Handbook and possible bump FreeBSD_version
and add this info to UPDATING?

I fully accept that running -CURRENT as a daily
driver leads to surprises like this, but it took
me a bit long to figure out which change
has caused this [1].

I was also thinking, would that be ok to add
the synopsis of _memcpy_chk and other
functions to the relevant memcpy(3) etc. manpages?

Only when viewing the diff I found out I could
learn about those from ssp(3).

Thanks for keeping FreeBSD alive,
Marcin

[1] spoiler alert: https://reviews.freebsd.org/D32306

Re: bsdinstall wifi setup is broken on CURRENT

[Renato Botelho]

On 18/05/24 11:33, Alfonso S. Siciliano wrote:

On 5/16/24 20:40, Renato Botelho wrote:
I saw some users on a .br group complaining bsdinstall was failing to 
setup wifi network on 15.0 snapshots and tried it myself.  I was able 
to reproduce the problem and also noticed another one.




Thank you for your report, the video is highly appreciated to understand 
the problem quickly and exactly.


I noticed Network Selection screen only shows one line, it's not 
beautiful to navigate through items this way.  On 14.1-BETA2 it shows 
multiple lines so it seems to be a regression.


Problem 1. Looking at wlanconfig it seems related to $height $width 
$rows for the selecting menu. Please could you open a PR adding me, so 
we can test and solve.


I've fixed it locally and submitted a fix for review

https://reviews.freebsd.org/D45271



The problem users reported was: after selecting desired network it 
just starts over instead of asking for password.  I made a video [1] 
showing the problem.


Problem 2. I know this issue about --mixedform, my last import 2 day ago 
should solve a6d8be451f62d425b71a4874f7d4e133b9fb393c.
You could try the last main snapshot (yesterday 17 May), please let me 
know any problem.


Last snapshot still contains bsddialog 1.0 so I'll wait for the next one 
and give it a try.




Jessica, I've cc'd you because git shows you were the last person 
making changes in this area.  If it's not related and I made a 
mistake, just ignore me.


[1] https://youtube.com/shorts/Gmeckokw2a0


Again thanks for the video.

Best Regards,
Alfonso




--
Renato Botelho

RES: RES: RES: usb mouse not work on boot

[Ivan Quitschal]

> -Mensagem original-
> De: owner-freebsd-curr...@freebsd.org  curr...@freebsd.org> Em nome de Dag-Erling Smørgrav
> Enviada em: segunda-feira, 20 de maio de 2024 06:01
> Para: Ivan Quitschal 
> Cc: Vladimir Kondratyev ; Warner Losh
> ; Oleksandr Kryvulia ; FreeBSD
> Current 
> Assunto: Re: RES: RES: usb mouse not work on boot
> 
> Ivan Quitschal  writes:
> > > Ivan Quitschal  writes:
> > > > diff --git a/sys/dev/usb/input/usbhid.c
> > > > b/sys/dev/usb/input/usbhid.c index 174e1c28ae96..7b19d713c943
> > > > 100644
> > > > --- a/sys/dev/usb/input/usbhid.c
> > > > +++ b/sys/dev/usb/input/usbhid.c
> > > > @@ -802,6 +802,7 @@ usbhid_probe(device_t dev)
> > > > if (hid_test_quirk(>sc_hw, HQ_HID_IGNORE))
> > > > return (ENXIO);
> > > > +// return (BUS_PROBE_GENERIC + 1);
> > > > return (BUS_PROBE_DEFAULT + 1);  }
> > > You realize this diff does nothing at all, right?
> > Yeap, i also said it worked in 14-current old code only ,and has more
> > than 2 years already
> 
> No, I mean all this does is add a comment.  It has no effect on the code.
> 
> DES
> --
> Dag-Erling Smørgrav - d...@freebsd.org


Oh ok,, sorry

But actually it did change one return for another 

Usbhid.ko used to return this 
return (BUS_PROBE_GENERIC + 1);

and ums.ko used to take place instead , messing up our multimedia kbds and all
Was a priority issue when it shouldn’t matter

Then Vladmir changed to this
return (BUS_PROBE_DEFAULT + 1);  

and everything went to "voil" 


sorry for the miss communication
regards

tzk

Re: RES: RES: usb mouse not work on boot

[Dag-Erling Smørgrav]

Ivan Quitschal  writes:
> > Ivan Quitschal  writes:
> > > diff --git a/sys/dev/usb/input/usbhid.c b/sys/dev/usb/input/usbhid.c
> > > index 174e1c28ae96..7b19d713c943 100644
> > > --- a/sys/dev/usb/input/usbhid.c
> > > +++ b/sys/dev/usb/input/usbhid.c
> > > @@ -802,6 +802,7 @@ usbhid_probe(device_t dev)
> > > if (hid_test_quirk(>sc_hw, HQ_HID_IGNORE))
> > > return (ENXIO);
> > > +// return (BUS_PROBE_GENERIC + 1);
> > > return (BUS_PROBE_DEFAULT + 1);
> > >  }
> > You realize this diff does nothing at all, right?
> Yeap, i also said it worked in 14-current old code only ,and has more
> than 2 years already

No, I mean all this does is add a comment.  It has no effect on the
code.

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

RES: RES: usb mouse not work on boot

[Ivan Quitschal]

Hans participated on that, and in that one too,  he was the last person I spoke 
on this forum, then I found out the tragic news, then I lost some interest, not 
about bsd, bot about those things I remember he was directly involved , like 
that one for example .. 

but yes I know its not a proper patch , he told me that too .. with all the 
9 and such ...

last usb thing I spoke about on this list
https://lists.freebsd.org/archives/freebsd-current/2022-September/002580.html
so please 
not necessary


Thanks
tzk


> -Mensagem original-
> De: owner-freebsd-curr...@freebsd.org  curr...@freebsd.org> Em nome de Ivan Quitschal
> Enviada em: domingo, 19 de maio de 2024 19:49
> Para: Dag-Erling Smørgrav 
> Cc: Vladimir Kondratyev ; Warner Losh
> ; Oleksandr Kryvulia ; FreeBSD
> Current 
> Assunto: RES: RES: usb mouse not work on boot
> 
> Yeap, i also said it worked in 14-current old code only ,and has more than  2 
> years
> already
> 
> Only point was whether freebsd had
> this
> return (BUS_PROBE_DEFAULT + 1); }
> or that
> return (BUS_PROBE_GENERIC + 1);
> 
> glad we have the first one , aka the right return
> 
> We have an entire email chain about this day back in the day august 2022 don’t
> remember correctly
> 
> 
> 
> > -Mensagem original-
> > De: Dag-Erling Smørgrav  Enviada em: domingo, 19 de
> > maio de 2024 08:04
> > Para: Ivan Quitschal 
> > Cc: Vladimir Kondratyev ; Warner Losh
> > ; Oleksandr Kryvulia ; FreeBSD
> > Current 
> > Assunto: Re: RES: usb mouse not work on boot
> >
> > Ivan Quitschal  writes:
> > > diff --git a/sys/dev/usb/input/usbhid.c b/sys/dev/usb/input/usbhid.c
> > > index 174e1c28ae96..7b19d713c943 100644
> > > --- a/sys/dev/usb/input/usbhid.c
> > > +++ b/sys/dev/usb/input/usbhid.c
> > > @@ -802,6 +802,7 @@ usbhid_probe(device_t dev)
> > > if (hid_test_quirk(>sc_hw, HQ_HID_IGNORE))
> > > return (ENXIO);
> > > +// return (BUS_PROBE_GENERIC + 1);
> > > return (BUS_PROBE_DEFAULT + 1); }
> >
> > You realize this diff does nothing at all, right?
> >
> > DES
> > --
> > Dag-Erling Smørgrav - d...@freebsd.org