Re: Is anyone using libzfs_core on 15-CURRENT?

On Wed, Jun 19, 2024 at 06:34:24PM +0100, David Chisnall wrote: > Hi all, > > I have some code using libzfs_core that works fine on 13, but seems not to on > 15-CURRENT. The lzc_snapshot function is failing with exactly the same nv > list argument. It is failing with errno 2 (ENOENT) from the

Is anyone using libzfs_core on 15-CURRENT?

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

maintainer take for security/globalprotect-openconnect

I filed an issue: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279853 to take over maintainer for security/globalprotect-openconnect Thanks matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub

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

On Tue, 18 Jun 2024, Moin Rahman wrote: On Jun 18, 2024, at 5:41 PM, Bjoern A. Zeeb wrote: Hi, I have no idea where to start but I know if I uninstall the ncruses port the problem goes away. I am trying to build a few packages on main/arm64 (from the last 24h) and this is like the 5th port

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

> On Jun 18, 2024, at 6:13 PM, Moin Rahman wrote: > > > >> On Jun 18, 2024, at 5:41 PM, Bjoern A. Zeeb >> wrote: >> >> Hi, >> >> I have no idea where to start but I know if I uninstall the ncruses port >> the problem goes away. >> >> I am trying to build a few packages on main/arm64

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

> On Jun 18, 2024, at 5:41 PM, Bjoern A. Zeeb > wrote: > > Hi, > > I have no idea where to start but I know if I uninstall the ncruses port > the problem goes away. > > I am trying to build a few packages on main/arm64 (from the last 24h) > and this is like the 5th port I run into this

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

Hi, I have no idea where to start but I know if I uninstall the ncruses port the problem goes away. I am trying to build a few packages on main/arm64 (from the last 24h) and this is like the 5th port I run into this problem now: ld: error: undefined symbol: newterm referenced by clamdtop.c

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

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

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

> On 17. Jun 2024, at 20:34, Shawn Webb wrote: > > On Mon, Jun 17, 2024 at 10:54:29AM -0400, Ed Maste wrote: >> It is currently possible to specify an IPv4 address without a >> netmask/width to ifconfig or in rc.conf, e.g.: >> >>ifconfig_igb0="192.168.0.2" >> >> phk recently

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

On Mon, Jun 17, 2024 at 10:54:29AM -0400, Ed Maste wrote: > It is currently possible to specify an IPv4 address without a > netmask/width to ifconfig or in rc.conf, e.g.: > > ifconfig_igb0="192.168.0.2" > > phk recently discovered[1] that ifconfig chose a poor netmask/width > when none was

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

On Mon, 17 Jun 2024 10:54:29 -0400 Ed Maste wrote: > It is currently possible to specify an IPv4 address without a > netmask/width to ifconfig or in rc.conf, e.g.: > > ifconfig_igb0="192.168.0.2" > > phk recently discovered[1] that ifconfig chose a poor netmask/width > when none was

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

It is currently possible to specify an IPv4 address without a netmask/width to ifconfig or in rc.conf, e.g.: ifconfig_igb0="192.168.0.2" phk recently discovered[1] that ifconfig chose a poor netmask/width when none was specified. This was not an intentional change in defaults but rather a

Heads up: Changes in VM image URLs

Hi everyone, We currently publish a number of VM images on download.freebsd.org: * Generic VM images, with URLs like https://download.freebsd.org/snapshots/VM-IMAGES/15.0-CURRENT/amd64/20240613/FreeBSD-15.0-CURRENT-amd64-ufs-20240613-bb53f071e85a-270741.qcow2.xz

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

Am Thu, 6 Jun 2024 10:39:33 GMT Sumit Saxena schrieb: > The branch main has been updated by ssaxena: > > URL: > https://cgit.FreeBSD.org/src/commit/?id=8d3c3b52423f9740da424aa6dd73a20e694a9e08 > > commit 8d3c3b52423f9740da424aa6dd73a20e694a9e08 > Author: Chandrakanth patil > AuthorDate:

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

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

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

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

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

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

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

> "Poul-Henning Kamp" writes: > > > Defaulting to a /8 netmask for 192.168.x.y does not make *any* sense ever. > > Well, not in the last 30 years or so, anyway. No, never ever did /8 make since on 192.*.*.*, that has always been class C address space. -- Rod Grimes

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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 :-)" --

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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: > > > > > > > [...] > > > > >

Re: 41dfea24eec panics during ata attach on ESXi VM

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

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

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

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

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

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

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 >

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

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: > > > > > > > [...] > > > > > > >

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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,

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

> 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

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

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

Call for 2024Q2 status reports

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

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

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

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

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)

Re: May 2024 stabilization week

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 -

Re: May 2024 stabilization week

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

Re: May 2024 stabilization week

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.

Re: May 2024 stabilization week

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,

Re: May 2024 stabilization week

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

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

(...) 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? >

mesa-dri-24.0.8 failing to build on d1bd097d52cb

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

Re: May 2024 stabilization week

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:

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

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 >

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

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

Re: May 2024 stabilization week

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

Re: May 2024 stabilization week

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

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

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

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

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

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

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

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

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

Re: May 2024 stabilization week

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.

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

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

Re: May 2024 stabilization week

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

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

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

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

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

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

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.

[HEADSUP] broken kernels for head this week for pkgbase

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

May 2024 stabilization week

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

Re: CURRENT kernel crash beyond git: 02d15215cef2

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

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

Re: main cadd2ca217 doesn't boot

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

Re: CURRENT kernel crash beyond git: 02d15215cef2

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 >

Re: CURRENT kernel crash beyond git: 02d15215cef2

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

Re: main cadd2ca217 doesn't boot

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

Re: main cadd2ca217 doesn't boot

> 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

Re: main cadd2ca217 doesn't boot

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

Re: main cadd2ca217 doesn't boot

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

Re: main cadd2ca217 doesn't boot

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:

main cadd2ca217 doesn't boot

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

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 >

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

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

panic: lock "tmpfsni" 0xfffff80721307090 already initialized

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

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

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

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

> 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

  1   2   3   4   5   6   7   8   9   10   >