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

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

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

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:

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.

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

Reproducible at .

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

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

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

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

devd nomatch does not load uslcom anymore

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

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 >

__memcpy_chk family of functions

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

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

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

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

RES: RES: usb mouse not work on boot

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

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

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

RES: RES: usb mouse not work on boot

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/usbhid.c in your own kernel source tree to see what line is there Thanks Ivan De:

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

RES: usb mouse not work on boot

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 use to this very day important line

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

On Sat, May 18, 2024 at 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

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

usb mouse not work on boot

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.

usb devices discovery delay

Hello all, At recent main-n270203-2790ff21452f usb devices mouse and audio dac get detected 30sec after login prompt. Don't see anything relevant on dmesg but I see that: sysctl.conf dev.pcm.4.play.vchanmode=passthrough gives an error on not existing dev.pcm.4 (usb audio dac) what means that

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:

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

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. (dmesg) link_elf_obj: symbol tpm_bus_driver undefined linker_load_file:

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

bsdinstall wifi setup is broken on CURRENT

Thank you for the information. The right email address is i...@aktionheizung.de Pay information exclusively to this email address. Thanks - On 16 May 2024, at 19:40, Renato Botelho wrote: I saw some users on a .br group complaining bsdinstall

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

bsdinstall wifi setup is broken on CURRENT

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 only shows one line, it's not beautiful to navigate through

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

Panic: lock "lnxspin" 0xfffff800176c0730 already initialized

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.): g1-70(14.1-S)[4] grep '^PORT' /etc/src.conf PORTS_MODULES+=graphics/drm-61-kmod And

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

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 __attribute__((constructor(101))) void init_101() { puts("init 1"); } __attribute__((constructor(65535))) void

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

pkg scripts need updating

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 connections: /usr/local/etc/periodic/security/405.pkg-base-audit:

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

On Thu, May 9, 2024 at 2:36 AM Alexander Leidinger wrote: > > 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. > >>

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

  1   2   3   4   5   6   7   8   9   10   >