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

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

termcap.db unused?

I was looking at a ktrace dump file recently (/bin/ls) and noticed that during initialisation, it attempted to read /etc/termcap.db - as that failed, it then read the text version pointed to by /etc/termcap Adding a link: /etc/termcap.db -> /usr/share/misc/termcap.db caused subsequent runs to

Graph of the FreeBSD memory fragmentation

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 visualizes memory fragmentation". As part of that,

FreeBSD Status Report - First Quarter 2024

FreeBSD Status Report First Quarter 2024 Here is the first 2024 status report, with 21 entries. The New Year brings us many new interesting projects, such as the new libsys that separates system calls from libc and libpthread or work on a graphical installer for FreeBSD, which will help making

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

Kenny Wayne Shepherd - Voodoo Child (Slight Return)

https://www.youtube.com/watch?v=oHO5a4l_8zY Kenny Wayne Shepherd - Voodoo Child (Slight Return) - KTBA Cruise 2019 youtube.com

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

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 7950X3D-UFS 15.0-CURRENT FreeBSD 15.0-CURRENT #142

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!

14.1-PRERELEASE boot stuck on feeding entropy

Hello, After upgrading from February's 14-stable amd64 to 14.1-PRERELEASE amd64 one of my systems can't boot anymore. Bootloader was, of course, updated. It's freezes on "Feeding entropy ." message. The system installed on pretty old Supermicro server with dual Intel Xeon E5620 CPU, uses BIOS

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

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

Hello all, 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 welcome and I didn't openned an upstream PR yet.

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

Request for non-GENERIC kernel diff

Hello! Who uses their own kernel config, please share the diff between the 14 and 13.x branches Thanks. -- Vladislav V. Prodan System & Network Administrator support.od.ua

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

mysterious setting of B_DIRECT?

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 field called b_caller1 was NULL. Now, here's the weird part...

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

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

Hello, Host: 15.0-CURRENT FreeBSD 15.0-CURRENT #36 main-n269703-54c3aa02e926: Thu Apr 25 18:48:56 CEST 2024 amd64 or 14-STABLE recently compiled (dmesg/uname not at hand). Hardware: oldish Z77Pro 4 based Asrock mainboard, a Lenovo T560 notebook, Fujitsu Esprimo Q5XX (simple desktop, Pentium

  1   2   3   4   5   6   7   8   9   10   >