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

t; 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: l

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

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

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:

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

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

Re: bsdinstall wifi setup is broken on CURRENT

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

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

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

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

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.

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

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

Re: __memcpy_chk family of functions

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

Re: __memcpy_chk family of functions

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

Re: __memcpy_chk family of functions

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

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

Re: __memcpy_chk family of functions

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

Re: devd nomatch does not load uslcom anymore

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

Re: __memcpy_chk family of functions

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 >

Re: bsdinstall wifi setup is broken on CURRENT

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

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

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,

Re: usb mouse not work on boot

On 2024-05-18 08:33, Warner Losh wrote: On Sat, May 18, 2024, 9:22 AM Oleksandr Kryvulia wrote: 18.05.24 16:06, Warner Losh: On Sat, May 18, 2024, 6:51 AM Oleksandr Kryvulia wrote: 18.05.24 12:59, Oleksandr Kryvulia: 18.05.24 12:55, Dag-Erling Smørgrav: Oleksandr Kryvulia writes:

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

18.05.24 21:39, Ivan Quitschal: Not sure, im on 14-current because of my synergy  insists on crashing  after version synergy-1.14.0.4,3 But that’s pretty simple to check Just do a # grep ‘return (BUS_PROBE_’ /user/src/sys/dev/usb/input/usbhidc in your own kernel source tree to see what

Re: RES: usb mouse not work on boot

18.05.24 19:29, Ivan Quitschal: Hi Warner /  WBR / Oleksandr Im not sure if that’s the case with this uhid.ko, but you guys remember I had a priority issue with this module and Vladimir made me a patch to fix the attach priority? Warner, was it fixed since then? Let me show the patch I

Re: usb mouse not work on boot

On Sat, May 18, 2024, 9:22 AM Oleksandr Kryvulia wrote: > 18.05.24 16:06, Warner Losh: > > > > On Sat, May 18, 2024, 6:51 AM Oleksandr Kryvulia > wrote: > >> 18.05.24 12:59, Oleksandr Kryvulia: >> >> 18.05.24 12:55, Dag-Erling Smørgrav: >> >> Oleksandr Kryvulia writes: >> >> Gary Jennejohn

Re: usb mouse not work on boot

18.05.24 16:06, Warner Losh: On Sat, May 18, 2024, 6:51 AM Oleksandr Kryvulia wrote: 18.05.24 12:59, Oleksandr Kryvulia: 18.05.24 12:55, Dag-Erling Smørgrav: Oleksandr Kryvulia writes: Gary Jennejohn writes:

Re: bsdinstall wifi setup is broken on CURRENT

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

Re: usb mouse not work on boot

his case, kld_list is a terrible place to load the files. You're better off loading them with xxx_load=YES in loader.conf. The reason is that both uhid and ums will match your mouse. kld_list loads these in a random order (effectively) and the first one to load will claim the device, since there's n

Re: usb mouse not work on boot

On Sat, May 18, 2024, 6:51 AM Oleksandr Kryvulia wrote: > 18.05.24 12:59, Oleksandr Kryvulia: > > 18.05.24 12:55, Dag-Erling Smørgrav: > > Oleksandr Kryvulia writes: > > Gary Jennejohn writes: > > Try adding uhid_load="YES" to your /boot/loader.conf. With that > added the module should be

Re: usb mouse not work on boot

18.05.24 12:59, Oleksandr Kryvulia: 18.05.24 12:55, Dag-Erling Smørgrav: Oleksandr Kryvulia writes: Gary Jennejohn writes: Try adding uhid_load="YES" to your /boot/loader.conf. With that added the module should be automatically loaded during the kernel boot. As workaround I already have

Re: usb mouse not work on boot

18.05.24 12:55, Dag-Erling Smørgrav: Oleksandr Kryvulia writes: Gary Jennejohn writes: Try adding uhid_load="YES" to your /boot/loader.conf. With that added the module should be automatically loaded during the kernel boot. As workaround I already have kld_list+="uhid" in /etc/rc.conf. I

Re: usb mouse not work on boot

Oleksandr Kryvulia writes: > Gary Jennejohn writes: > > Try adding uhid_load="YES" to your /boot/loader.conf. With that > > added the module should be automatically loaded during the kernel > > boot. > As workaround I already have kld_list+="uhid" in /etc/rc.conf. I hope you don't mean that

Re: usb mouse not work on boot

18.05.24 12:42, Tomek CEDRO: does it also affect usb keyboard in single boot mode? Good question. I don't have usb keyboerd right now and will check it a bit later.

Re: usb mouse not work on boot

Hello, To fix my setup with usb mouse and audio dac on both amd64 (laptop) and rpi4: /boot/loader.conf.local: snd_uaudio_load="YES" ums_load="YES" This restores previous behaviour as it detects mouse before login prompt and audio dac that it is processed correctly by sysctl. Cheers, Oleksandr

Re: usb mouse not work on boot

18.05.24 10:26, Gary Jennejohn: On Sat, 18 May 2024 09:20:24 +0300 Oleksandr Kryvulia wrote: After 6437872c1d665c2605f54e8ff040b0ba41edad07 my usb mouse no longer works on boot because uhid(4) is not autoloaded. To make it work I need manualy load uhid or replug my usb mouse. Try adding

Re: usb mouse not work on boot

On Sat, 18 May 2024 09:20:24 +0300 Oleksandr Kryvulia wrote: > After 6437872c1d665c2605f54e8ff040b0ba41edad07 my usb mouse no longer > works on boot because uhid(4) is not autoloaded. To make it work I need > manualy load uhid or replug my usb mouse. > Try adding uhid_load="YES" to your

Re: kldload tpm: Fail to load: "link_elf_obj: symbol tpm_bus_driver undefined"

Working fine! Thanks for fast fix. Justin Hibbits escreveu (sexta, 17/05/2024 à(s) 13:57): > On Fri, 17 May 2024 11:09:00 +0100 > Nuno Teixeira wrote: > > > Hello, > > > > tpm kernel module fails to load starting on main from May 9. > > Updated today and same error: > > > > ``` > > $ kldload

Re: kldload tpm: Fail to load: "link_elf_obj: symbol tpm_bus_driver undefined"

On Fri, 17 May 2024 11:09:00 +0100 Nuno Teixeira wrote: > Hello, > > tpm kernel module fails to load starting on main from May 9. > Updated today and same error: > > ``` > $ kldload tpm > kldload: an error occurred while loading module tpm. Please check > dmesg(8) for more details. > >

Re: Panic: lock "lnxspin" 0xfffff800176c0730 already initialized

On Fri, May 17, 2024 at 08:00:05AM +0200, Emmanuel Vadot wrote: > ... > Indeed, even if I know that I tested with GENERIC and amdgpu I think > that I've only tested GENERIC-NODEBUG with i915kms. > Anyway, I've pushed both patches now. Sorry for the breakage. > > Cheers, > Success:

Re: Panic: lock "lnxspin" 0xfffff800176c0730 already initialized

On Thu, 16 May 2024 22:10:16 -0700 Ryan Libby wrote: > On Thu, May 16, 2024 at 9:56?PM Emmanuel Vadot wrote: > > > > On Thu, 16 May 2024 10:27:40 -0700 > > Ryan Libby wrote: > > > > > On Thu, May 16, 2024 at 6:00?AM David Wolfskill > > > wrote: > > > > > > > > This is running

Re: Panic: lock "lnxspin" 0xfffff800176c0730 already initialized

On Thu, May 16, 2024 at 9:56 PM Emmanuel Vadot wrote: > > On Thu, 16 May 2024 10:27:40 -0700 > Ryan Libby wrote: > > > On Thu, May 16, 2024 at 6:00?AM David Wolfskill > > wrote: > > > > > > This is running main-n270174-abb1a1340e3f (built in-place from > > > main-n270163-154ad8e0f88f), with

Re: Panic: lock "lnxspin" 0xfffff800176c0730 already initialized

On Thu, 16 May 2024 10:27:40 -0700 Ryan Libby wrote: > On Thu, May 16, 2024 at 6:00?AM David Wolfskill wrote: > > > > This is running main-n270174-abb1a1340e3f (built in-place from > > main-n270163-154ad8e0f88f), with ports at main-n663685-3f732745ab06; > > the ports-resident kernel modules

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

> On May 17, 2024, at 2:26 AM, Konstantin Belousov wrote: > > On Thu, May 16, 2024 at 08:06:46PM +0800, Zhenlei Huang wrote: >> Hi, >> >> I'm recently working on https://reviews.freebsd.org/D45194 and got noticed >> that gcc behaves weirdly. >> >> A simple source file to demonstrate that. >>

Re: bsdinstall wifi setup is broken on CURRENT

Renato Botelho writes: > I'm not sure about a good way to test it on a running system instead. Update your source tree, build and install world, run `sudo bsdconfig`, scroll down and select “Network Management”, then select “Wireless Networks”. DES -- Dag-Erling Smørgrav - d...@freebsd.org

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

On Thu, May 16, 2024 at 08:05:57PM +, 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

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

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

Re: bsdinstall wifi setup is broken on CURRENT

Hello Renato, I will give it a try this weekend with bhyve since I have a passtrhu for iwlwifi card. Cheers, Renato Botelho escreveu (quinta, 16/05/2024 à(s) 19:56): > On 16/05/24 15:47, Jessica Clarke wrote: > > On 16 May 2024, at 19:40, Renato Botelho wrote: > >> > >> I saw some users on a

Re: bsdinstall wifi setup is broken on CURRENT

On 16/05/24 15:47, Jessica Clarke wrote: On 16 May 2024, at 19: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. I

Re: bsdinstall wifi setup is broken on CURRENT

On 16 May 2024, at 19: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. > > I noticed Network Selection screen

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

On Thu, May 16, 2024 at 08:06:46PM +0800, Zhenlei Huang wrote: > Hi, > > I'm recently working on https://reviews.freebsd.org/D45194 and got noticed > that gcc behaves weirdly. > > A simple source file to demonstrate that. > > ``` > # cat ctors.c > > #include > >

Re: Panic: lock "lnxspin" 0xfffff800176c0730 already initialized

On Thu, May 16, 2024 at 6:00 AM David Wolfskill wrote: > > This is running main-n270174-abb1a1340e3f (built in-place from > main-n270163-154ad8e0f88f), with ports at main-n663685-3f732745ab06; > the ports-resident kernel modules were rebuilt with the kernel, > courtesy (e.g.): > >

Re: pkg scripts need updating

Am 15.05.24 um 02:21 schrieb Enji Cooper: On May 14, 2024, at 7:19 AM, Michael Butler wrote: After commit aa48259f337100e79933d660fec8856371f761ed to src which removed security_daily_compat_var, I get these warnings daily.. aaron.protected-networks.net login failures:

Re: Unfamiliar console message: in prompt_tty(): caught signal 2

> On Apr 21, 2024, at 1:48 PM, bob prohaska wrote: > > On Sun, Apr 21, 2024 at 10:16:55PM +0200, Dag-Erling Smørgrav wrote: >> bob prohaska writes: >>> Apr 20 22:14:37 www su[30398]: in prompt_tty(): caught signal 2 >> >> This means someone ran `su` and pressed Ctrl-C instead of entering a >>

Re: pkg scripts need updating

> On May 14, 2024, at 7:19 AM, Michael Butler > wrote: > > After commit aa48259f337100e79933d660fec8856371f761ed to src which removed > security_daily_compat_var, I get these warnings daily.. > > aaron.protected-networks.net login failures: > > aaron.protected-networks.net refused

Re: Graph of the FreeBSD memory fragmentation

On Tue, May 14, 2024 at 9:09 AM Ryan Libby wrote: > > On Tue, May 14, 2024 at 1:14 AM Alexander Leidinger > wrote: > > > > Am 2024-05-14 03:54, schrieb Ryan Libby: > > > That was a long winded way of saying: the "UMA bucket" axis is > > > actually "vm phys free list order". > > > > > > That

Re: Graph of the FreeBSD memory fragmentation

On Tue, May 14, 2024 at 1:14 AM Alexander Leidinger wrote: > > Am 2024-05-14 03:54, schrieb Ryan Libby: > > That was a long winded way of saying: the "UMA bucket" axis is > > actually "vm phys free list order". > > > > That said, I find that dimension confusing because in fact there's > > just

Re: Graph of the FreeBSD memory fragmentation

Am 2024-05-14 03:54, schrieb Ryan Libby: That was a long winded way of saying: the "UMA bucket" axis is actually "vm phys free list order". That said, I find that dimension confusing because in fact there's just one piece of information there, the average size of a free list entry, and it

Re: Graph of the FreeBSD memory fragmentation

the handful of UMA_ZONE_CONTIG zones. Because otherwise, UMA doesn't explicitly do or require allocations of contiguous pages. Most allocations by UMA of backing pages are done as single pages from the perspective of the vm phys free lists. When possible (slab size of one page and machine architec

Re: Graph of the FreeBSD memory fragmentation

Am 2024-05-08 18:45, schrieb Bojan Novković: Hi, On 5/7/24 14:02, Alexander Leidinger wrote: Hi, I created some graphs of the memory fragmentation. https://www.leidinger.net/blog/2024/05/07/plotting-the-freebsd-memory-fragmentation/ My goal was not comparing a specific change on a given

Re: Graph of the FreeBSD memory fragmentation

Hi Alex, No, i can't comment on the C code or it's change impact otherwise. But the graphs are impressive, i say lets try it. I can test i 14-stable. Ty. On Tue, May 7, 2024 at 8:03 AM Alexander Leidinger wrote: > Hi, > > I created some graphs of the memory fragmentation. > > >

Re: pkg server for current/arm64 stopped ? [main-armv7 on ampere2, . . .] [Update to Host OSVERSION 1500018 did not help]

On 2024-05-08 23:53:57 (+0800), Mark Millard wrote: On Apr 29, 2024, at 20:16, Mark Millard wrote: On Apr 29, 2024, at 20:11, Mark Millard wrote: On Apr 29, 2024, at 19:54, Mark Millard wrote: On Apr 28, 2024, at 18:06, Philip Paeps wrote: On 2024-04-18 23:14:22 (+0800), Mark

Re: Graph of the FreeBSD memory fragmentation

Hi, On 5/7/24 14:02, Alexander Leidinger wrote: Hi, I created some graphs of the memory fragmentation. https://www.leidinger.net/blog/2024/05/07/plotting-the-freebsd-memory-fragmentation/ My goal was not comparing a specific change on a given benchmark, but to "have something which

Re: pkg server for current/arm64 stopped ? [main-armv7 on ampere2, . . .] [Update to Host OSVERSION 1500018 did not help]

On Apr 29, 2024, at 20:16, Mark Millard wrote: > On Apr 29, 2024, at 20:11, Mark Millard wrote: > >> On Apr 29, 2024, at 19:54, Mark Millard wrote: >> >>> On Apr 28, 2024, at 18:06, Philip Paeps wrote: >>> On 2024-04-18 23:14:22 (+0800), Mark Millard wrote: > On Apr 18, 2024, at

Re: main [so: 15] amd64: Rare poudriere bulk builder "stuck in umtxq_sleep" condition (race failure?) during high-load-average "poudriere bulk -c -a" runs

On May 4, 2024, at 09:59, Mark Millard wrote: > I recently did some of my rare "poudriere bulk -c -a" high-load-average > style experiments, here on a 7950X3D (amd64) system and I ended up with > a couple of stuck builders (one per bulk run of 2 runs). Contexts: > > # uname -apKU > FreeBSD

Re: build failure affecting port: "error: reference to 'filesystem' is ambiguous"

Nice to see that upstream chose the more correct solution. :) -Dimitry > On 2 May 2024, at 11:57, Nuno Teixeira wrote: > > Hello Dimitry, > > I've quoted your words in upstream PR and it solved with: > > Stop using namespace std >

Re: build failure affecting port: "error: reference to 'filesystem' is ambiguous"

Hello Dimitry, I've quoted your words in upstream PR and it solved with: Stop using namespace std https://github.com/amsynth/amsynth/commit/6fb79100a6254220e5adc69a1428572539ecc377 I'm using patch globally that unbreak main and rest of supported releases don't complaint about it. Thanks!

Re: build failure affecting port: "error: reference to 'filesystem' is ambiguous"

On 30 Apr 2024, at 14:26, Nuno Teixeira wrote: > > I'm lost on build failure of audio/amsynth (updated to version 1.13.3) on > recent main. > Thre strange thing is if I use llvm from ports, USES+=llvm, it fails with > same error so I suspect that something related to main. > > Any help is

Re: pkg server for current/arm64 stopped ? [main-armv7 on ampere2, elapsed so far: 651:21:56]

On Apr 29, 2024, at 20:11, Mark Millard wrote: > On Apr 29, 2024, at 19:54, Mark Millard wrote: > >> On Apr 28, 2024, at 18:06, Philip Paeps wrote: >> >>> On 2024-04-18 23:14:22 (+0800), Mark Millard wrote: On Apr 18, 2024, at 08:02, Mark Millard wrote: > void wrote on >

Re: pkg server for current/arm64 stopped ? [main-armv7 on ampere2, elapsed so far: 651:21:56]

On Apr 29, 2024, at 19:54, Mark Millard wrote: > On Apr 28, 2024, at 18:06, Philip Paeps wrote: > >> On 2024-04-18 23:14:22 (+0800), Mark Millard wrote: >>> On Apr 18, 2024, at 08:02, Mark Millard wrote: void wrote on Date: Thu, 18 Apr 2024 14:08:36 UTC : > Not sure where

Re: pkg server for current/arm64 stopped ? [main-armv7 on ampere2, elapsed so far: 651:21:56]

On Apr 28, 2024, at 18:06, Philip Paeps wrote: > On 2024-04-18 23:14:22 (+0800), Mark Millard wrote: >> On Apr 18, 2024, at 08:02, Mark Millard wrote: >>> void wrote on >>> Date: Thu, 18 Apr 2024 14:08:36 UTC : >>> Not sure where to post this.. The last bulk build for arm64

Re: pkg server for current/arm64 stopped ? [main-armv7 on ampere2, elapsed so far: 651:21:56]

On 2024-04-18 23:14:22 (+0800), Mark Millard wrote: On Apr 18, 2024, at 08:02, Mark Millard wrote: void wrote on Date: Thu, 18 Apr 2024 14:08:36 UTC : Not sure where to post this.. The last bulk build for arm64 appears to have happened around mid-March on ampere2. Is it broken?

Re: serial/ulscom: response timeout using pySerial/esptool.py

Am Sat, 27 Apr 2024 11:28:55 +0200 FreeBSD User schrieb: Just for the record: running a small "victim NAS" based on an HP EliteDesk 800 G2 mini, XigmaNAS (latest official version, kernel see below), installing packages from an official FreeBSD site for FBSD 13.2-RELEASE, gives me on an ESP32

Re: serial/ulscom: response timeout using pySerial/esptool.py

Am Thu, 25 Apr 2024 21:51:21 +0200 Tomek CEDRO schrieb: > CP2102 are pretty good ones and never let me down :-) > > Is your UART connection to ESP32 working correctly? Can you see the > boot message and whatever happens next in terminal (cu / minicom)? Are > RX TX pins not swapped? Power supply

Re: TXT Kernel linking failed on -CURRENT

Konstantin, good day! 25.04.2024 0:09, Konstantin Belousov пишет: On Wed, Apr 24, 2024 at 01:12:39PM +0500, BSD USER wrote: linking kernel ld: error: undefined symbol: ktrcapfail referenced by vfs_lookup.c    vfs_lookup.o:(namei) referenced by vfs_lookup.c   

Re: pkg server for current/arm64 stopped ? [main-armv7 on ampere2, elapsed so far: 651:21:56]

On Apr 26, 2024, at 18:55, Philip Paeps wrote: > On 2024-04-18 23:02:30 (+0800), Mark Millard wrote: >> void wrote on >> Date: Thu, 18 Apr 2024 14:08:36 UTC : >> >>> Not sure where to post this.. >>> >>> The last bulk build for arm64 appears to have happened around >>> mid-March on ampere2.

Re: pkg server for current/arm64 stopped ? [main-armv7 on ampere2, elapsed so far: 651:21:56]

On 2024-04-18 23:02:30 (+0800), Mark Millard wrote: void wrote on Date: Thu, 18 Apr 2024 14:08:36 UTC : Not sure where to post this.. The last bulk build for arm64 appears to have happened around mid-March on ampere2. Is it broken? main-armv7 building is broken and the last completed build

Re: mysterious setting of B_DIRECT?

On Thu, Apr 25, 2024 at 8:51 PM Rick Macklem wrote: > > On Thu, Apr 25, 2024 at 8:09 PM Konstantin Belousov wrote: > > > > On Thu, Apr 25, 2024 at 07:49:23PM -0700, Rick Macklem wrote: > > > Hi, > > > > > > This week I have been doing active testing as a part of an IETF > > > bakeathon for

Re: mysterious setting of B_DIRECT?

On Thu, Apr 25, 2024 at 8:09 PM Konstantin Belousov wrote: > > On Thu, Apr 25, 2024 at 07:49:23PM -0700, Rick Macklem wrote: > > Hi, > > > > This week I have been doing active testing as a part of an IETF > > bakeathon for NFSv4. During the week I had a NFSv4 client > > crash. On the surface, it

Re: mysterious setting of B_DIRECT?

On Thu, Apr 25, 2024 at 07:49:23PM -0700, Rick Macklem wrote: > Hi, > > This week I have been doing active testing as a part of an IETF > bakeathon for NFSv4. During the week I had a NFSv4 client > crash. On the surface, it is straightforward, in that it called > ncl_doio_directwrite() and the

Re: serial/ulscom: response timeout using pySerial/esptool.py

Can you isolate out the extraneous stuff and loop tx and rx on a CP2101 board and send bytes through? I did a bunch of development on an esp8266 board in the last few weeks and had no issues, but I’ve no idea if it were the same usb serial chip. I’ll have a dig around and see if I have

Re: serial/ulscom: response timeout using pySerial/esptool.py

CP2102 are pretty good ones and never let me down :-) Is your UART connection to ESP32 working correctly? Can you see the boot message and whatever happens next in terminal (cu / minicom)? Are RX TX pins not swapped? Power supply okay? Are boards generic devkits of custom hardware? ESP32 in

Re: TXT Kernel linking failed on -CURRENT

On Wed, Apr 24, 2024 at 01:12:39PM +0500, BSD USER wrote: > linking kernel > ld: error: undefined symbol: ktrcapfail > >>> referenced by vfs_lookup.c > >>>   vfs_lookup.o:(namei) > >>> referenced by vfs_lookup.c > >>>   vfs_lookup.o:(namei_setup) > >>> referenced by

Re: Strange network/socket anomalies since about a month

Alexander Leidinger writes: > Gleb Smirnoff writes: > > I don't have any better idea than ktrace over failing application. > > Yep, I understand that poudriere will produce a lot. > Yes, it does. 4.4 GB just for the start of poudriere until the first > package build fails due to a failed sccache

  1   2   3   4   5   6   7   8   9   10   >