Re: MIT KRB5 in 15-CURRENT

In message , Minsoo Choo writes: > On Sunday, June 15th, 2025 at 11:43 PM, Cy Schubert com> wrote: > > > Hi freebsd-current@, > >=20 > > MIT KRB5 has been imported. It is disabled by default. To build and insta= > ll > > MIT KRB5 in 15-CURRENT, > >=20

Re: MIT KRB5 in 15-CURRENT

On Sunday, June 15th, 2025 at 11:43 PM, Cy Schubert wrote: > Hi freebsd-current@, > > MIT KRB5 has been imported. It is disabled by default. To build and install > MIT KRB5 in 15-CURRENT, > > 1. Add WITH_MITKRB5=yes in src.conf. > > 2. Do a buildworld and b

MIT KRB5 in 15-CURRENT

Hi freebsd-current@, MIT KRB5 has been imported. It is disabled by default. To build and install MIT KRB5 in 15-CURRENT, 1. Add WITH_MITKRB5=yes in src.conf. 2. Do a buildworld and buildkernel. 3. Then installworld, run etcupdate to update files in /etc. 4. make delete-old and delete-old

Re: CURRENT: can not add device to bridge: ifconfig: BRDGADD igb0: Invalid argument

Am Tage des Herren Tue, 20 May 2025 23:30:24 +0100 Lexi Winter schrieb: > A FreeBSD User: > > I need a IPv6 prefix on bridge0. With the "wrong/faulty" concept I > > simply used > > > > rtsold_flags="-iu igb0" > > > > within /etc/rc.conf. Changing this line to > > rtsold_flags="-iu bridge0" whi

Re: Failed make installworld on a recent -CURRENT

Hi Herbert, On Sun, Jun 01, 2025 at 11:49:15AM +0200, Herbert J. Skuhra wrote: > On Sun, Jun 01, 2025 at 11:45:38AM +0200, Gordon Bergling wrote: > > Hi, > > > > I am getting a strange error, when trying to update a recent -CURRENT. > > The build happends on 14.2-REL

Re: Failed make installworld on a recent -CURRENT

On Sun, Jun 01, 2025 at 11:45:38AM +0200, Gordon Bergling wrote: > Hi, > > I am getting a strange error, when trying to update a recent -CURRENT. > The build happends on 14.2-RELEASE and the tree is shared of NFS. > The error I get is > > make[1]: warning: /storage/freeb

[Bug 285044] legacy BIOS loader: lua gfx logos on 15-CURRENT are broken

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285044 Warner Losh changed: What|Removed |Added Status|Open|Closed Resolution|---

[Bug 285044] legacy BIOS loader: lua gfx logos on 15-CURRENT are broken

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285044 --- Comment #13 from commit-h...@freebsd.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=9486d6d57d14844972ee63382045e2ed7a300963 commit 9486d6d57d14844972ee63382045e2ed7a300963 Author:

[Bug 285044] legacy BIOS loader: lua gfx logos on 15-CURRENT are broken

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285044 Warner Losh changed: What|Removed |Added CC||d8zne...@aon.at --- Comment #12 from

[Bug 285044] legacy BIOS loader: lua gfx logos on 15-CURRENT are broken

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285044 --- Comment #11 from Warner Losh --- I think that the fix looks good, I'll push it in. But I worry that we'll affect the UEFI loader. I'm guessing we won't affect graphical because it does different things to still look good, which is why I

[Bug 285044] legacy BIOS loader: lua gfx logos on 15-CURRENT are broken

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285044 --- Comment #10 from Marek Zarychta --- Created attachment 260789 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=260789&action=edit 0001-loader-Fix-beastie-and-fbsdbw-logo-positions.patch Three remaining logo images adjusted to

Re: HEADS UP: 15.0-CURRENT, change to bridge(4) might break some network configurations with “Invalid argument”

On Thu, May 22, 2025 at 08:09:13PM +0100, Lexi Winter wrote: as kp said, this is broken, but you can trivially fix it by moving the IP addresses to the bridge interface instead. note that for SLAAC to work on a bridge, you have to set ‘accept_rtadv’ and ‘auto_linklocal’ on the bridge interface

Re: HEADS UP: 15.0-CURRENT, change to bridge(4) might break some network configurations with “Invalid argument”

void: > On Mon, May 19, 2025 at 11:33:50AM +0100, Lexi Winter wrote: > > in short, following this commit... > > > > b61850c4e6f "bridge(4): default net.link.bridge.member_ifaddrs to false" > > https://cgit.freebsd.org/src/commit/?id=b61850c4e6f6b0f21b36da7238db969d9090309e > > > > ...it is now im

Re: HEADS UP: 15.0-CURRENT, change to bridge(4) might break some network configurations with “Invalid argument”

On 21/05/2025 18:01, void wrote: This bhyve host was set up following instructions from the bhyve section of the handbook. I've just checked and no mention is made of the new requirement in section 24.7.1 of the handbook at https://freebsd.org/handbook So, if a lot of people run bhyve guests as

Re: HEADS UP: 15.0-CURRENT, change to bridge(4) might break some network configurations with “Invalid argument”

On Wed, May 21, 2025 at 04:44:46PM +0200, Kristof Provost wrote: [2] because here bge1 has an ip addigned to it and is a bridge member Yes, that is a problem. Assign REDACTED.REAL.IP to bridge1, not to bge1. Oof! Thank you for clarifying. I'm glad I asked. This bhyve host was set up followi

Re: HEADS UP: 15.0-CURRENT, change to bridge(4) might break some network configurations with “Invalid argument”

might also want to look at autobridge* options while you redo that config

Re: HEADS UP: 15.0-CURRENT, change to bridge(4) might break some network configurations with “Invalid argument”

On 21 May 2025, at 16:40, void wrote: On Mon, May 19, 2025 at 11:33:50AM +0100, Lexi Winter wrote: although it's possible everyone who is affected by this is already aware of the change, i thought i should send a heads up anyway, if only to have a single place to discuss this (since there was q

Re: HEADS UP: 15.0-CURRENT, change to bridge(4) might break some network configurations with “Invalid argument”

On Mon, May 19, 2025 at 11:33:50AM +0100, Lexi Winter wrote: although it's possible everyone who is affected by this is already aware of the change, i thought i should send a heads up anyway, if only to have a single place to discuss this (since there was quite a lot of discussion). in short, fo

Re: CURRENT: can not add device to bridge: ifconfig: BRDGADD igb0: Invalid argument

A FreeBSD User: > I need a IPv6 prefix on bridge0. With the "wrong/faulty" concept I > simply used > > rtsold_flags="-iu igb0" > > within /etc/rc.conf. Changing this line to > rtsold_flags="-iu bridge0" while bridge0 is up and running doesn't work, > neither does "rtsol > bridge0" show any resu

Re: CURRENT: can not add device to bridge: ifconfig: BRDGADD igb0: Invalid argument

gt; To get a stable SLAAC address it also helps to have in > > /boot/loader.conf: if_bridge_load="YES" > /etc/sysctl.conf: net.link.bridge.inherit_mac=1 > > This way the bridge IF clones the MAC address of the first member IF and > SLAAC works

Re: CURRENT: can not add device to bridge: ifconfig: BRDGADD igb0: Invalid argument

Am Tage des Herren Tue, 20 May 2025 11:29:24 +0200 "Patrick M. Hausen" schrieb: > Hi all, > > > Am 20.05.2025 um 11:24 schrieb A FreeBSD User : > > I need a IPv6 prefix on bridge0. With the "wrong/faulty" concept I simply > > used > > > > rtsold_flags="-iu igb0" > > > > within /etc/rc.conf.

Re: CURRENT: can not add device to bridge: ifconfig: BRDGADD igb0: Invalid argument

Hi all, > Am 20.05.2025 um 11:24 schrieb A FreeBSD User : > I need a IPv6 prefix on bridge0. With the "wrong/faulty" concept I simply > used > > rtsold_flags="-iu igb0" > > within /etc/rc.conf. Changing this line to > rtsold_flags="-iu bridge0" while bridge0 is up and running doesn't work, >

Re: CURRENT: can not add device to bridge: ifconfig: BRDGADD igb0: Invalid argument

Sorry, missed a detail: > Am 20.05.2025 um 11:29 schrieb Patrick M. Hausen : > > Hi all, > >> Am 20.05.2025 um 11:24 schrieb A FreeBSD User : >> I need a IPv6 prefix on bridge0. With the "wrong/faulty" concept I simply >> used >> >> rtsold_flags="-iu igb0" >> >> within /etc/rc.conf. Changin

Re: CURRENT: can not add device to bridge: ifconfig: BRDGADD igb0: Invalid argument

Am Tage des Herren Mon, 19 May 2025 11:22:31 +0200 "Patrick M. Hausen" schrieb: > Hi all, > > > Am 19.05.2025 um 10:53 schrieb Lexi Winter : > > > > the basic problem here is that putting IP addresses on a bridge member > > is a layering violation and it's just not reasonable (or even possible)

Re: CURRENT: can not add device to bridge: ifconfig: BRDGADD igb0: Invalid argument

Kristof Provost: > On 18 May 2025, at 21:24, Marek Zarychta wrote: > > W dniu 18.05.2025 o 19:48, Alexander Leidinger pisze: > >> You want to make it work without this. Short: use the IP on the > >> bridge itself, not in the member IF. > > I'm not sure we should be dictating to Oliver what he must

Re: CURRENT: can not add device to bridge: ifconfig: BRDGADD igb0: Invalid argument

Hi all, > Am 19.05.2025 um 10:53 schrieb Lexi Winter : > > the basic problem here is that putting IP addresses on a bridge member > is a layering violation and it's just not reasonable (or even possible) > to support this in a sensible way in bridge. this is why most dedicated > network devices

Re: CURRENT: can not add device to bridge: ifconfig: BRDGADD igb0: Invalid argument

W dniu 19.05.2025 o 10:43, Kristof Provost pisze: On 18 May 2025, at 21:24, Marek Zarychta wrote: W dniu 18.05.2025 o 19:48, Alexander Leidinger pisze: You want to make it work without this. Short: use the IP on the bridge itself, not in the member IF. I'm not sure we should be dictating to

Re: CURRENT: can not add device to bridge: ifconfig: BRDGADD igb0: Invalid argument

On 18 May 2025, at 21:24, Marek Zarychta wrote: > W dniu 18.05.2025 o 19:48, Alexander Leidinger pisze: >> You want to make it work without this. Short: use the IP on the bridge >> itself, not in the member IF. > I'm not sure we should be dictating to Oliver what he must do. Oliver is of course f

Re: CURRENT: can not add device to bridge: ifconfig: BRDGADD igb0: Invalid argument

W dniu 18.05.2025 o 19:48, Alexander Leidinger pisze: Am 2025-05-18 18:23, schrieb A FreeBSD User: Am Tage des Herren Sun, 18 May 2025 18:16:43 +0200 Marek Zarychta schrieb: W dniu 18.05.2025 o 18:06, A FreeBSD User pisze: > Hello, > > running recent CURRENT (FreeBSD 15.0-CURRENT

Re: CURRENT: can not add device to bridge: ifconfig: BRDGADD igb0: Invalid argument

Am 2025-05-18 18:23, schrieb A FreeBSD User: Am Tage des Herren Sun, 18 May 2025 18:16:43 +0200 Marek Zarychta schrieb: W dniu 18.05.2025 o 18:06, A FreeBSD User pisze: > Hello, > > running recent CURRENT (FreeBSD 15.0-CURRENT #68 main-n277334-d9900b9ea2b2: Sun May 18 > 16:51:

Re: CURRENT: can not add device to bridge: ifconfig: BRDGADD igb0: Invalid argument

Am Tage des Herren Sun, 18 May 2025 18:16:43 +0200 Marek Zarychta schrieb: > W dniu 18.05.2025 o 18:06, A FreeBSD User pisze: > > Hello, > > > > running recent CURRENT (FreeBSD 15.0-CURRENT #68 main-n277334-d9900b9ea2b2: > > Sun May 18 > > 16:51:02 CEST 2025),

Re: CURRENT: can not add device to bridge: ifconfig: BRDGADD igb0: Invalid argument

W dniu 18.05.2025 o 18:06, A FreeBSD User pisze: Hello, running recent CURRENT (FreeBSD 15.0-CURRENT #68 main-n277334-d9900b9ea2b2: Sun May 18 16:51:02 CEST 2025), I ran into the following problem: Can not add interfaces anymore to a bridge device. Neither existing physical devices, nor epair

[Bug 285044] legacy BIOS loader: lua gfx logos on 15-CURRENT are broken

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285044 --- Comment #9 from Alastair Hogge --- Created attachment 260163 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=260163&action=edit 2025-05-05-15-CURRENT-794ee43e75066bfcbc00545b5bf600b9cda2d5f1-UEFI bootloader with mis

[Bug 285044] legacy BIOS loader: lua gfx logos on 15-CURRENT are broken

I don't run current anymore. Thanks. -- You are receiving this mail because: You are on the CC list for the bug.

[Bug 285044] legacy BIOS loader: lua gfx logos on 15-CURRENT are broken

#7 from Yusuf Yaman --- Created attachment 259903 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=259903&action=edit the wand is closer to menu.webp Hi, I don't know how was it looking before when I use 14.2-RELEASE but i am on 15.0-CURRENT now and the beastie's wand

[Bug 285044] legacy BIOS loader: lua gfx logos on 15-CURRENT are broken

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285044 Marek Zarychta changed: What|Removed |Added See Also||https://bugs.freebsd.org/bu

FreeBSD-15.0-CURRENT-arm64-aarch64-zfs.vhd.xz fails to boot under Hyper-V v2 on Windows 11 Pro; possibly tied to: "stand: add comconsole backwards compatibility shim for aarch64"

In order to try to help test: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285681 I again tried to get main FreeBSD booting on the Windows DevKit 2023 under Windows 11 Pro, this time using: FreeBSD-15.0-CURRENT-arm64-aarch64-zfs.vhd.xz (expanded to .vhd and then the .vhd converted to

Re: Expected OpenSSL versions in 14-stable and 15-current

Van: "Enji Cooper (yaneurabeya)" Datum: maandag, 17 maart 2025 02:34 Aan: Minsoo Choo CC: FreeBSD CURRENT Onderwerp: Re: Expected OpenSSL versions in 14-stable and 15-current > On Mar 12, 2025, at 4:19PM, Minsoo Choo wrote: > > OpenSSL 3.5 LTS alpha has been just release

Re: Expected OpenSSL versions in 14-stable and 15-current

until 14-stable's end-of-life date? > > [1] https://github.com/openssl/openssl/releases/tag/openssl-3.5.0-alpha1 > [2] https://en.wikipedia.org/wiki/OpenSSL#Major_version_releases > [3] https://www.freebsd.org/security/#sup Hi Minsoo, It makes sense to upgrade to 3.5 o

-fstack-clash-protection triggers something in setfstab() (was: Re: Strange file access issue in a recent -current (but not with the previous BE))

Am 2025-02-26 16:20, schrieb Alexander Leidinger: Hi, the working system is from 2025-01-25-141603, the non working system is from 2025-02-21-115311. I'm not sure what the issue is exactly. I have traced down the change of behavior to ---snip--- if not LIBC.setfstab(fstab_file_path.encode()

Expected OpenSSL versions in 14-stable and 15-current

OpenSSL 3.5 LTS alpha has been just released [1]. The expected EOL date of OpenSSL 3.0 LTS is September 7th 2026 [2]. FreeBSD 15 is expected to be release in December 2025, and FreeBSD 14.5 is expected to be released in September 2026. 14-stable will be see its EOL on November 30th, 2028 [3]. W

Inaccuracies in 15.0-CURRENT documentation versus wayland+sway in practice

/run/user/`id -u` OK, so then I execute sway(1) and I get the lovely blue background. When I do a ls /var/run​ there's no user​ directory there. There is​ an xdg​ directory that contains the id -c​ of the user that ran sway. Now, I grant that I'm running 15.0-CURRENT against document

Re: No working interface bce0 after updating to CURRENT of March 1

rst, bce0. I changed the lines now to ifconfig_bce0="inet 192.168.178.5 netmask 255.255.255.0" # ifconfig_bce1="inet 192.168.178.6 netmask 255.255.255.0" defaultrouter="192.168.178.1" plugged in the cable again into the first port and all is fine, but unclear why i

Re: No working interface bce0 after updating to CURRENT of March 1

I had a wild guess and plug'ed in the RJ-45 into the server's 2nd port, modified /etc/rc.conf, booted and all was fine: $ ssh 192.168.178.5 $ uname -a FreeBSD jet 15.0-CURRENT FreeBSD 15.0-CURRENT #0 main-n275738-7ee310c80ea7: Sun Mar 2 01:13:00 CET 2025 guru@jet:/usr/obj/usr

Re: No working interface bce0 after updating to CURRENT of March 1

Hi You wrote : -- # netstat -rn Routing tables Internet: DestinationGatewayFlags Netif Expire default192.168.178.1 UGS*bce0* 127.0.0.1 link#3 UH lo0 192.168.178.0/24 link#2

No working interface bce0 after updating to CURRENT of March 1

Hello, Last night I updated a server from a 14.0-CURRENT amd64 1400094 #2 main-n264568-1d7ffb373c9d-dirty: Wed Sep 6 07:13:22 CEST 2023 to the CURRENT of March 1, 2025. All went fine. # git clone https://git.freebsd.org/src.git /usr/src # cd /usr/src # make -j8 buildworld

[Bug 285044] legacy BIOS loader: lua gfx logos on 15-CURRENT are broken

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285044 Mark Johnston changed: What|Removed |Added Status|New |Open -- You are receiving this ma

[Bug 285044] legacy BIOS loader: lua gfx logos on 15-CURRENT are broken

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285044 --- Comment #6 from Alexander Ziaee --- That color ASCII loader is just so beautiful. If I knew how to make the relevant file, I would add this back as an option, maybe `gfx-ascii.lua`. -- You are receiving this mail because: You are on t

[Bug 285044] legacy BIOS loader: lua gfx logos on 15-CURRENT are broken

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285044 --- Comment #5 from Marek Zarychta --- (In reply to Warner Losh from comment #4) I am booting this machine from BIOS and exceptionally it's drawing beastie, so an error in the text version logo is reported here. -- You are receiving this

[Bug 285044] legacy BIOS loader: lua gfx logos on 15-CURRENT are broken

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285044 --- Comment #4 from Warner Losh --- So this problem is with a BIOS loader, that's been compiled to enable graphics, correct? But the problems aren't present for the text version? cc'd manu since he made the alleged breaking changes. --

[Bug 285044] legacy BIOS loader: lua gfx logos on 15-CURRENT are broken

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285044 Warner Losh changed: What|Removed |Added CC||i...@freebsd.org,

[Bug 285044] legacy BIOS loader: lua gfx logos on 15-CURRENT are broken

|logos gfx logos on |logos on 15-CURRENT are |15-CURRENT are broken |broken -- You are receiving this mail because: You are on the CC list for the bug.

[Bug 285044] legacy BIOS loader: lua logos gfx logos on 15-CURRENT are broken

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285044 Marek Zarychta changed: What|Removed |Added CC||curr...@freebsd.org -- You are r

Strange file access issue in a recent -current (but not with the previous BE)

Hi, the working system is from 2025-01-25-141603, the non working system is from 2025-02-21-115311. I'm not sure what the issue is exactly. I have traced down the change of behavior to ---snip--- if not LIBC.setfstab(fstab_file_path.encode()): ---snip--- In the working case LIBC.setfstab re

Re: Very poor -CURRENT boot performance on AMD

Hi Jung-uk Kim, On Thu, Feb 20, 2025 at 5:22 AM Jung-uk Kim wrote: > On 25. 2. 19., Mohammad Noureldin wrote: > > --snip-- > This happens because UEFI framebuffer access from boot loader is very > slow. Once the kernel is loaded and booted, everything is okay because > we properly set memory a

Re: Very poor -CURRENT boot performance on AMD

Hi Rupesh, On Thu, Feb 20, 2025 at 5:11 AM Rupesh Pilania wrote: > Hi Mohammad, > > I tried the same build on VMware and it came up very fast. I don't have > any AMD Ryzen based hw to confirm the behaviour. > IMO you should raise a PR. > [image: image.png] > > Thanks & Regards > Rupesh Pilania >

Re: Very poor -CURRENT boot performance on AMD

Hi Maku, On Thu, Feb 20, 2025 at 3:47 AM Maku Bex wrote: > Hi Mohammad, > > > > The performance issue(s) have been noted on the UPDATING file. Here is a > snippet: > > > > > > NOTE TO PEOPLE WHO THINK THAT FreeBSD 15.x IS SLOW: > > FreeBSD 15.x has many debugging features turned on, in both

Error messages in 15.0-CURRENT (n275524-8dc0889..)

Folks, I built a GENERIC kernel "hot off the presses" as of the commits cited above. I am surprised that I'm still getting error messages in dmesg​ about: - Firmware errors - i915/skl_dmc_ver1_27.bin: could not load binary firmware /boot/firmware/i915/skl_dmc_ver1_27.bin either (repeats) - drm

Re: Very poor -CURRENT boot performance on AMD

On 25. 2. 19., Mohammad Noureldin wrote: Hi, I've installed -CURRENT using snapshot "FreeBSD-15.0-CURRENT- amd64-20250213-6156da866e7d-275409" on an HP EliteBook 845 G10 with AMD Ryzen 5 7540U. Both when booting from the install media and when booting from disk after insta

Re: Very poor -CURRENT boot performance on AMD

ightbird.com> wrote: > Hi, > > I've installed -CURRENT using snapshot > "FreeBSD-15.0-CURRENT-amd64-20250213-6156da866e7d-275409" on an HP > EliteBook 845 G10 with AMD Ryzen 5 7540U. > > Both when booting from the install media and when booting from disk after &

RE: Very poor -CURRENT boot performance on AMD

Gbnw2KQIJAQu1m9zEP5XdWmFi SvGg1NHW2kzqAvFsG37flbwrGRu5fmTnS/LZ/oPzOCuwU6F+o1q0E7gLwFwnzD93 riKeabdd =iCV+ -END PGP PUBLIC KEY BLOCK- From: owner-freebsd-curr...@freebsd.org On Behalf Of Mohammad Noureldin Sent: Wednesday, February 19, 2025 9:34 PM To: Freebsd current Subject: Very poor -CURREN

Very poor -CURRENT boot performance on AMD

Hi, I've installed -CURRENT using snapshot "FreeBSD-15.0-CURRENT-amd64-20250213-6156da866e7d-275409" on an HP EliteBook 845 G10 with AMD Ryzen 5 7540U. Both when booting from the install media and when booting from disk after installation I get a very poor boot performance up un

Re: HEADS UP: NFS changes coming into CURRENT early February

to be incorrect, so disregard it. I think we should focus on the dead connection leak, where NFS RPC layer doesn't process garbage collecting of a TCP connection unless it actually needs to make a write on it, described here: https://lists.freebsd.org/archives/freebsd-current/2025-January/

Re: HEADS UP: NFS changes coming into CURRENT early February

nd running rpcbind(8)) > are affected. You would need to recompile & reinstall both the world and the > kernel together. Of course this is what you'd normally do when you track > FreeBSD CURRENT, but better be warned. I will post hashes of the specific > revisions that break AP

Re: HEADS UP: NFS changes coming into CURRENT early February

On Tue, Jan 28, 2025 at 09:14:00PM -0800, Gleb Smirnoff wrote: T> Second, with the patch the M_RPC leak count for me is 2. And I found that these T> two items are basically is a clnt_vc that belongs to a closed connection: T> T> f80029614a80 tcp4 0 0 10.6.6.9.772 10.6.6.9.204

Re: HEADS UP: NFS changes coming into CURRENT early February

On Mon, Jan 27, 2025 at 06:10:42PM -0800, Rick Macklem wrote: R> I think I've found a memory leak, but it shouldn't be a show stopper. R> R> What I did on the NFS client side is: R> # vmstat -m | fgrep -i rpc R> # mount -t nfs -o nfsv4,tls nfsv4-server:/ /mnt R> # ls --lR /mnt R> --> Then I networ

Re: HEADS UP: NFS changes coming into CURRENT early February

nd running rpcbind(8)) > are affected. You would need to recompile & reinstall both the world and the > kernel together. Of course this is what you'd normally do when you track > FreeBSD CURRENT, but better be warned. I will post hashes of the specific > revisions that break AP

Re: HEADS UP: NFS changes coming into CURRENT early February

.g. running rpc.tlsclntd(8) or rpc.tlsservd(8)) as well as users of > > network lock manager (e.g. having 'options NFSLOCKD' and running rpcbind(8)) > > are affected. You would need to recompile & reinstall both the world and > > the > > kernel together. Of

Re: HEADS UP: NFS changes coming into CURRENT early February

nd running rpcbind(8)) > are affected. You would need to recompile & reinstall both the world and the > kernel together. Of course this is what you'd normally do when you track > FreeBSD CURRENT, but better be warned. I will post hashes of the specific > revisions that break AP

Re: HEADS UP: NFS changes coming into CURRENT early February

On Thu, Jan 23, 2025 at 02:42:54PM -0800, Rick Macklem wrote: R> > The code is posted on phabricator, reviews D48547 through D48552. R> > Reviewers are very welcome! R> > R> > I share my branch on Github. It is usually rebased on today's CURRENT: R> > R>

Re: HEADS UP: NFS changes coming into CURRENT early February

nd running rpcbind(8)) > are affected. You would need to recompile & reinstall both the world and the > kernel together. Of course this is what you'd normally do when you track > FreeBSD CURRENT, but better be warned. I will post hashes of the specific > revisions that break AP

HEADS UP: NFS changes coming into CURRENT early February

recompile & reinstall both the world and the kernel together. Of course this is what you'd normally do when you track FreeBSD CURRENT, but better be warned. I will post hashes of the specific revisions that break API/ABI when they are pushed. Longer version: last year I tried to check-in a

USB massive disconnections with FreeBSD 15.0-CURRENT

, try to reset the USB stack and finally reboot. I attach part of the log messages uname -a FreeBSD defiant 15.0-CURRENT FreeBSD 15.0-CURRENT main-n273400-5e5e4e1cf0c3 GENERIC amd64 Nov  6 15:23:27 defiant dhclient[10922]: New Routers (em0): 192.168.66.1 Nov  6 18:30:15 defiant kernel: drmn0

[Bug 197921] scheduler: Allow non-migratable threads to bind to their current CPU

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197921 Mark Linimon changed: What|Removed |Added Keywords|needs-patch | -- You are receiving this mail be

Re: Freezes with FreeBSD 15.0-CURRENT since 3 weeks

10:40 *Aan:* freebsd-current@freebsd.org *Onderwerp:* Freezes with FreeBSD 15.0-CURRENT since 3 weeks Hi, Since 2 or 3 weeks I start experiencing system freezes on an and64 Lenovo Thinkbook laptop I'm using as my daily desktop PC. I'm running FreeBSD current using pkg base

Re: Freezes with FreeBSD 15.0-CURRENT since 3 weeks

: dinsdag, 22 oktober 2024 10:40 Aan: freebsd-current@freebsd.org Onderwerp: Freezes with FreeBSD 15.0-CURRENT since 3 weeks Hi, Since 2 or 3 weeks I start experiencing system freezes on an and64 Lenovo Thinkbook laptop I'm using as my daily desktop PC. I'm running FreeBSD current

Freezes with FreeBSD 15.0-CURRENT since 3 weeks

Hi, Since 2 or 3 weeks I start experiencing system freezes on an and64 Lenovo Thinkbook laptop I'm using as my daily desktop PC. I'm running FreeBSD current using pkg base_weekly to grab updates (currently main-n273070-6d42d5dbdd67). The full hardware details are here: https://wiki.f

Re: Problems with FreeBSD-15.0-CURRENT-amd64-20241003

On 09/10/2024 07:35, Paul Floyd wrote: … ld-elf.so.1: Shared object "libmd.so.6" not found, … pkgbase context: |

Re: Problems with FreeBSD-15.0-CURRENT-amd64-20241003

On 10-10-24 11:16, Konstantin Belousov wrote: If you can determine not just the number of taken locks, but also the specific locks that were taken, perhaps you can check that this is the libc exit lock? For the moment I've turned off the check for FreeBSD 15 and above. At present the ExeCo

Re: Problems with FreeBSD-15.0-CURRENT-amd64-20241003

On Wed, Oct 09, 2024 at 07:34:31PM +, Paul Floyd wrote: > > > On 09-10-24 08:50, Konstantin Belousov wrote: > > > Perhaps you can check for the presence of the symbol exit@FBSD_1.0 in the > > backtrace to determine the situation. > > We don't read .gnu.version and the version number hasn't

Re: Problems with FreeBSD-15.0-CURRENT-amd64-20241003

On 09-10-24 08:50, Konstantin Belousov wrote: Perhaps you can check for the presence of the symbol exit@FBSD_1.0 in the backtrace to determine the situation. We don't read .gnu.version and the version number hasn't changed as far as I can see. I can check osreldate to get an idea of the

Re: Problems with FreeBSD-15.0-CURRENT-amd64-20241003

On Wed, Oct 09, 2024 at 10:27:22AM +0200, Paul Floyd wrote: > > > > On Wed, 9 Oct 2024 at 09:08, Konstantin Belousov > > wrote: > > > On Wed, Oct 09, 2024 at 06:35:08AM +, Paul Floyd wrote: > > > The biggest problem is with Helgrind. All apps now generate an extra > > error > > > > > > ==68593

Re: Problems with FreeBSD-15.0-CURRENT-amd64-20241003

> > > I can probably check whether it's the main thread (I assume that this code > doesn't run on subsidiary threads) > No it looks like it can be any thread. A+ Paul

Re: Problems with FreeBSD-15.0-CURRENT-amd64-20241003

> > On Wed, 9 Oct 2024 at 09:08, Konstantin Belousov > wrote: > On Wed, Oct 09, 2024 at 06:35:08AM +, Paul Floyd wrote: > > The biggest problem is with Helgrind. All apps now generate an extra > error > > > > ==68593== Thread #1: Exiting thread still holds 1 lock > > ==68593==at 0x4BBB5DA:

Re: Problems with FreeBSD-15.0-CURRENT-amd64-20241003

On Wed, Oct 09, 2024 at 06:35:08AM +, Paul Floyd wrote: > Hi > > I don't often update my 15-0-CURRENT VM. I did last week and I'm getting > several issues. > > Firstly, a bit annoying, both pkg and ksh93 fail to run, giving. > ld-elf.so.1: Shared object &quo

Problems with FreeBSD-15.0-CURRENT-amd64-20241003

Hi I don't often update my 15-0-CURRENT VM. I did last week and I'm getting several issues. Firstly, a bit annoying, both pkg and ksh93 fail to run, giving. ld-elf.so.1: Shared object "libmd.so.6" not found, required by "ksh93" Next I'm getting a lot of ne

Re: change in /usr/bin/bc with CTRL-d no longer exit [fixed in -CURRENT]

Am 16.09.24 um 17:01 schrieb Cy Schubert: In message , Warner Losh writes: [...] The irony here is that i fixed thus very bug 2 or 3 years ago. Warner It's curious (or maybe not) how some bugs keep returning with a time and time again. Version 7.0.2 has just been committed to -CU

looking for feedback on the CURRENT stabilization cycle

Hi, we've been running the stabilization week of FreeBSD/main aka CURRENT since February. And it has been public since March. So we have had 5 cycles already and 4 were public. I'm eager to get some feedback from people who had been positively or negatively affected by this

random USB detach in CURRENT

Hi, Since a couple of weeks I'm start seeing random USB detach for all my devices once in a while. The issue doesn't occurs so often and there is no other details in the var log. I'm able to recover all my devices by just unplugging and re-plug the devices. I'm runni

Re: Is anyone using libzfs_core on 15-CURRENT?

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

Is anyone using libzfs_core on 15-CURRENT?

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

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

et this error while perfoming "make -jX > buildworld > buildkernel": > > [...] > /usr/src/sys/amd64/amd64/exec_machdep.c:80:2: error: KDB must be enabled in > order for DDB to > work! 80 | #error KDB must be enabled in order for DDB to work! > | ^ > [...]

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

DDB to work! 80 | #error KDB must be enabled in order for DDB to work! | ^ [...] Apart from the recommendation not to disable KDB in CURRENT, is there a way to disable debugging features and mimik a stable branch? Thanks in advance, oh -- O. Hartmann

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

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

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 you

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 you

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 appreciate

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

  1   2   3   4   5   6   7   8   9   10   >