kernel build w/o DDB broken after c21bc6f

When a kernel is built without KDB and DDB, it fails with: --- kernel.full --- linking kernel.full ld: error: undefined symbol: db_ctf_lookup_typename >>> referenced by kern_ctf.c:329 (/usr/src/sys/kern/kern_ctf.c:329) >>> link_elf_obj.o:(link_elf_ctf_lookup_typename) >>>

main aarch64: poudriere-devel [UFS context] cpdup stuck in pgnslp state

Note, more recent process creations towards top, older ones towards bottom: PID JID USERNAMEPRI NICE SIZE RES STATEC TIME CPU COMMAND . . 3369319 root 680 6524Ki3252Ki wait 3 0:00 0.00% /usr/bin/make -C /usr/ports/lang/gcc13 build 33692

Re: Problem with make installworld

> On 21. Mar 2024, at 18:12, Dimitry Andric wrote: > > On 21 Mar 2024, at 01:12, tue...@freebsd.org wrote: >> >>> On 21. Mar 2024, at 00:27, Dimitry Andric wrote: >>> >>> On 20 Mar 2024, at 21:44, tue...@freebsd.org wrote: I'm trying to run make buildworld / make installworld on a

Re: Problem with make installworld

On 21 Mar 2024, at 01:12, tue...@freebsd.org wrote: > >> On 21. Mar 2024, at 00:27, Dimitry Andric wrote: >> >> On 20 Mar 2024, at 21:44, tue...@freebsd.org wrote: >>> >>> I'm trying to run make buildworld / make installworld on a recent main >>> branch >>> (some days old). >>> >>> The

Re: Request for Testing: TCP RACK

The entire point is to *NOT* go through the overhead of scheduling something asynchronously, but to take advantage of the fact that a user/kernel transition is going to trash the cache anyway. In the common case of a system which has less than the threshold number of connections , we access

Re: Request for Testing: TCP RACK

On Tue, Mar 19, 2024 at 06:19:52AM -0400, rrs wrote: > Ok I have created > > https://reviews.freebsd.org/D44420 > > > To address the issue. I also attach a short version of the patch that Nuno > can try and validate > > it works. Drew you may want to try this and validate the optimization does

Re: Problem with make installworld

> On 21. Mar 2024, at 00:27, Dimitry Andric wrote: > > On 20 Mar 2024, at 21:44, tue...@freebsd.org wrote: >> >> I'm trying to run make buildworld / make installworld on a recent main branch >> (some days old). >> >> The problem is related to lib/libc/tests/ssp/Makefile >> which contains: >>

Re: Problem with make installworld

On 20 Mar 2024, at 21:44, tue...@freebsd.org wrote: > > I'm trying to run make buildworld / make installworld on a recent main branch > (some days old). > > The problem is related to lib/libc/tests/ssp/Makefile > which contains: > _libclang_rt_ubsan= >

Problem with make installworld

Dear all, I'm trying to run make buildworld / make installworld on a recent main branch (some days old). The problem is related to lib/libc/tests/ssp/Makefile which contains: _libclang_rt_ubsan= ${SYSROOT}${SANITIZER_LIBDIR}/libclang_rt.ubsan_standalone-${CRTARCH}.a if

Re: sysutils/pam_xdg: Cancelled on -CURRENT

On 2024-03-19 16:02, Emmanuel Vadot wrote: > On Tue, 19 Mar 2024 07:55:15 + > Alastair Hogge wrote: > >> On 2024-03-19 15:23, Emmanuel Vadot wrote: >> > Hi, >> >> Hey Emmanuel, >> >> > On Tue, 19 Mar 2024 06:54:27 + >> > Alastair Hogge wrote: >> > >> >> Hello, >> >> >> >> Recently a

Re: sysutils/pam_xdg: Cancelled on -CURRENT

On Tue, 19 Mar 2024 07:55:15 + Alastair Hogge wrote: > On 2024-03-19 15:23, Emmanuel Vadot wrote: > > Hi, > > Hey Emmanuel, > > > On Tue, 19 Mar 2024 06:54:27 + > > Alastair Hogge wrote: > > > >> Hello, > >> > >> Recently a similar module (PAM) mentioned in the subject was committed

Re: sysutils/pam_xdg: Cancelled on -CURRENT

On 2024-03-19 15:23, Emmanuel Vadot wrote: > Hi, Hey Emmanuel, > On Tue, 19 Mar 2024 06:54:27 + > Alastair Hogge wrote: > >> Hello, >> >> Recently a similar module (PAM) mentioned in the subject was committed >> to base[1]. The module in base masks the currently installed Port, the >> man

Re: sysutils/pam_xdg: Cancelled on -CURRENT

Hi, On Tue, 19 Mar 2024 06:54:27 + Alastair Hogge wrote: > Hello, > > Recently a similar module (PAM) mentioned in the subject was committed > to base[1]. The module in base masks the currently installed Port, the > man page can be accessed with man -M /usr/local/share/man 8 pam_xdg, >

sysutils/pam_xdg: Cancelled on -CURRENT

Hello, Recently a similar module (PAM) mentioned in the subject was committed to base[1]. The module in base masks the currently installed Port, the man page can be accessed with man -M /usr/local/share/man 8 pam_xdg, however, I can now no longer build the Port. I noticed that the base module has

Re: git: e34ea0196f44 - main - tcp: clear all TCP timers in tcp_timer_stop() when in callout

Hi! This commit is supposed to fix a problem we do not have a reproducer for. The problem was that sometimes a TCP connection enters tcp_discardcb() with a scheduled timer. A temporary patch 57e27ff07aff was committed to mask the problem. This patch is supposed to fix the root cause.

Re: Request for Testing: TCP RACK

No. The goal is to run on every return to userspace for every thread. Drew On Mon, Mar 18, 2024, at 3:41 PM, Konstantin Belousov wrote: > On Mon, Mar 18, 2024 at 03:13:11PM -0400, Drew Gallatin wrote: > > I got the idea from > >

Re: Request for Testing: TCP RACK

On Mon, Mar 18, 2024 at 03:13:11PM -0400, Drew Gallatin wrote: > I got the idea from > https://people.mpi-sws.org/~druschel/publications/soft-timers-tocs.pdf > The gist is that the TCP pacing stuff needs to run frequently, and > rather than run it out of a clock interrupt, its more efficient to

Re: Request for Testing: TCP RACK

I got the idea from https://people.mpi-sws.org/~druschel/publications/soft-timers-tocs.pdf The gist is that the TCP pacing stuff needs to run frequently, and rather than run it out of a clock interrupt, its more efficient to run it out of a system call context at just the point where we

Re: Request for Testing: TCP RACK

On Mon, Mar 18, 2024 at 07:26:10AM -0500, Mike Karels wrote: > On 18 Mar 2024, at 7:04, tue...@freebsd.org wrote: > > >> On 18. Mar 2024, at 12:42, Nuno Teixeira wrote: > >> > >> Hello all! > >> > >> It works just fine! > >> System performance is OK. > >> Using patch on

kernel= , kern.module_path= , and loader menu selections: how to have it always find the matching, say, nfsd.ko (same directory as the kernel)

I'm using an aarch64 environment as the example context for this note. I have instances of the various PkgBase kernels and one or more personal kernel builds. Currently: # ls -Tlod /boot/kernel*/nfsd* -r--r--r-- 1 root wheel - 401600 Mar 17 18:45:35 2024 /boot/kernel.CA76-NODBG.good/nfsd.ko

Re: Request for Testing: TCP RACK

On Mon, Mar 18, 2024 at 07:26:10AM -0500, Mike Karels wrote: > ... > >> It would be so nice that we can have a sysctl tunnable for this patch > >> so we could do more tests without recompiling kernel. > > Thanks for testing! > > > > @gallatin: can you come up with a patch that is acceptable for

Re: Request for Testing: TCP RACK

On 18 Mar 2024, at 7:04, tue...@freebsd.org wrote: >> On 18. Mar 2024, at 12:42, Nuno Teixeira wrote: >> >> Hello all! >> >> It works just fine! >> System performance is OK. >> Using patch on main-n268841-b0aaf8beb126(-dirty). >> >> --- >> net.inet.tcp.functions_available: >> Stack

Re: Request for Testing: TCP RACK

> On 18. Mar 2024, at 12:42, Nuno Teixeira wrote: > > Hello all! > > It works just fine! > System performance is OK. > Using patch on main-n268841-b0aaf8beb126(-dirty). > > --- > net.inet.tcp.functions_available: > Stack D AliasPCB count >

Re: Request for Testing: TCP RACK

Hello all! It works just fine! System performance is OK. Using patch on main-n268841-b0aaf8beb126(-dirty). --- net.inet.tcp.functions_available: Stack D AliasPCB count freebsd freebsd 0 rack

Re: Request for Testing: TCP RACK

Hello, > I don't have the full context, but it seems like the complaint is a > performance regression in bonnie++ and perhaps other things when tcp_hpts is > loaded, even when it is not used. Is that correct? > > If so, I suspect its because we drive the tcp_hpts_softclock() routine from >

Re: Request for Testing: TCP RACK

> On 17. Mar 2024, at 16:39, Drew Gallatin wrote: > > I don't have the full context, but it seems like the complaint is a > performance regression in bonnie++ and perhaps other things when tcp_hpts is > loaded, even when it is not used. Is that correct? Correct. > > If so, I suspect its

Re: Request for Testing: TCP RACK

On Sun, 17 Mar 2024 11:40:54 -0400 "Drew Gallatin" wrote: > Resending with the patch as an attachment. > > Drew > > On Sun, Mar 17, 2024, at 11:39 AM, Drew Gallatin wrote: > > I don't have the full context, but it seems like the complaint is a > > performance regression in bonnie++ and

Re: Request for Testing: TCP RACK

Resending with the patch as an attachment. Drew On Sun, Mar 17, 2024, at 11:39 AM, Drew Gallatin wrote: > I don't have the full context, but it seems like the complaint is a > performance regression in bonnie++ and perhaps other things when tcp_hpts is > loaded, even when it is not used. Is

Re: Request for Testing: TCP RACK

I don't have the full context, but it seems like the complaint is a performance regression in bonnie++ and perhaps other things when tcp_hpts is loaded, even when it is not used. Is that correct? If so, I suspect its because we drive the tcp_hpts_softclock() routine from userret(), in order

Re: Request for Testing: TCP RACK

Hello, > > - I can't remember better tests to do as I can feel the entire OS is > > being slow, without errors, just slow. > This is interesting. It seems a consequence on loading TCPHPTS, not actually > using it. Exactly, just loading module and not using it by setting sysctl. > I have CCed

Re: Request for Testing: TCP RACK

> On 16. Mar 2024, at 21:29, Nuno Teixeira wrote: > >> Just to double check: you only load the tcp_rack. You don't run >> sysctl net.inet.tcp.functions_default=rack > > I'm not using sysctl, just loading module. And you also don't have net.inet.tcp.functions_default=rack in /etc/sysctl.conf

Re: Request for Testing: TCP RACK

On Sun, 19 Nov 2023 04:01:01 +0900 Tomoaki AOKI wrote: > On Sat, 18 Nov 2023 09:50:43 +0100 > tue...@freebsd.org wrote: > > > > On Nov 18, 2023, at 00:37, Tomoaki AOKI wrote: > > > > > > On Fri, 17 Nov 2023 18:51:05 +0100 > > > tue...@freebsd.org wrote: > > > > > >>> On Nov 17, 2023, at

Re: Request for Testing: TCP RACK

> Just to double check: you only load the tcp_rack. You don't run > sysctl net.inet.tcp.functions_default=rack I'm not using sysctl, just loading module. > What does "poudriere testport net/gitup" do? Only build stuff or does is > also download something? > > What does bonnie++ do? poudriere is

Re: Request for Testing: TCP RACK

> On 16. Mar 2024, at 20:06, Nuno Teixeira wrote: > >>> Will update amd64 laptop to main-n268827-75464941dc17 (Mar 16) and test it. >> Please do so... > > @main-n268827-75464941dc17 GENERIC-NODEBUG amd64 > > Ok, I think I have here some numbers related to disk performance being > affected by

Re: Request for Testing: TCP RACK

> > Will update amd64 laptop to main-n268827-75464941dc17 (Mar 16) and test it. > Please do so... @main-n268827-75464941dc17 GENERIC-NODEBUG amd64 Ok, I think I have here some numbers related to disk performance being affected by tcp_rack that somehow is messing with something. NOTES: - test

Re: Request for Testing: TCP RACK

> On 16. Mar 2024, at 15:00, Nuno Teixeira wrote: > >> If you load tcp_rack via kldload, tcphtps get loaded automatically. >> If you load if via /boot/loader.conf, you need to have >> tcphpts_load="YES" >> in addition to >> tcp_rack_load="YES" > > As of my tests, loader.conf:

Re: Request for Testing: TCP RACK

> If you load tcp_rack via kldload, tcphtps get loaded automatically. > If you load if via /boot/loader.conf, you need to have > tcphpts_load="YES" > in addition to > tcp_rack_load="YES" As of my tests, loader.conf: tcp_rack_load="YES" loads tcphtps.ko auto: 31 0x81f53000545e0

Re: Request for Testing: TCP RACK

> On 16. Mar 2024, at 11:59, Nuno Teixeira wrote: > >>> Resuming I only need to add: >>> >>> options TCPHPTS >>> >>> Is this correct? >>> >> >> Yeah, that will probably fix it. According to a comment in >> /usr/src/sys/netinet/tcp_hpts.c it adds a high precision timer >> system for

Re: Request for Testing: TCP RACK

> > Resuming I only need to add: > > > > options TCPHPTS > > > > Is this correct? > > > > Yeah, that will probably fix it. According to a comment in > /usr/src/sys/netinet/tcp_hpts.c it adds a high precision timer > system for tcp, used by RACK and BBR. As tuexen said, on main,

Re: Request for Testing: TCP RACK

On Sat, 16 Mar 2024 10:11:22 + Nuno Teixeira wrote: > (...) > > > These entries are missing in GENERIC: > > > > makeoptions WITH_EXTRA_TCP_STACKS=1 > > From > https://cgit.freebsd.org/src/commit/?id=3a338c534154164504005beb00a3c6feb03756cc > WITH_EXTRA_TCP_STACKS was dropped. > > >

Re: Request for Testing: TCP RACK

> On 16. Mar 2024, at 11:11, Nuno Teixeira wrote: > > (...) > >> These entries are missing in GENERIC: >> >> makeoptions WITH_EXTRA_TCP_STACKS=1 > > From > https://cgit.freebsd.org/src/commit/?id=3a338c534154164504005beb00a3c6feb03756cc > WITH_EXTRA_TCP_STACKS was dropped. > >> options

Re: Request for Testing: TCP RACK

(...) > These entries are missing in GENERIC: > > makeoptions WITH_EXTRA_TCP_STACKS=1 >From >https://cgit.freebsd.org/src/commit/?id=3a338c534154164504005beb00a3c6feb03756cc WITH_EXTRA_TCP_STACKS was dropped. > options TCPHPTS That's the missing option in GENERIC that could lead

Re: Request for Testing: TCP RACK

On Sat, 16 Mar 2024 09:49:24 + Nuno Teixeira wrote: > Hello Gary, > > Nice that you found this. > > tcp_tack manual doesn't mention that we need extra config in kernel > but it loads module and it is shown in sysctl > net.inet.tcp.functions_available without errors. > > I will add missing

Re: Request for Testing: TCP RACK

Hello Gary, Nice that you found this. tcp_tack manual doesn't mention that we need extra config in kernel but it loads module and it is shown in sysctl net.inet.tcp.functions_available without errors. I will add missing config to GENERIC and see how it goes. Cheers, Gary Jennejohn escreveu

Re: Request for Testing: TCP RACK

Followed man tcp_rack: loader.conf: tcp_rack_load="YES" sysctl.conf: net.inet.tcp.functions_default=rack poudriere have restricted access to network, usually for fetch distfiles. escreveu (sábado, 16/03/2024 à(s) 08:41): > > > On 16. Mar 2024, at 08:57, Nuno Teixeira wrote: > > > > Hello all,

Re: Request for Testing: TCP RACK

On Sat, 16 Mar 2024 09:41:13 +0100 tue...@freebsd.org wrote: > > On 16. Mar 2024, at 08:57, Nuno Teixeira wrote: > > > > Hello all, > > > > On a laptop i7/16MB ram, desktop use and port testing (poudriere) I've > > noticed that all operations on OS was increased by 3 to 5 times > > longer. > >

Re: Request for Testing: TCP RACK

> On 16. Mar 2024, at 08:57, Nuno Teixeira wrote: > > Hello all, > > On a laptop i7/16MB ram, desktop use and port testing (poudriere) I've > noticed that all operations on OS was increased by 3 to 5 times > longer. > examples: > - firefox took way long time to open > - poudriere testport

Re: Request for Testing: TCP RACK

Hello all, On a laptop i7/16MB ram, desktop use and port testing (poudriere) I've noticed that all operations on OS was increased by 3 to 5 times longer. examples: - firefox took way long time to open - poudriere testport tooked up to 3 times longer to finished make.conf:

Re: after trivial update, 15.0 ARM64 system no longer boots

I have no clue. But can you boot in “verbose” mode? And as the last message is usb, can you remove all usb devices and boot again? Regards, Ronald Van: Lexi Winter Datum: 15 maart 2024 16:57 Aan: freebsd-...@freebsd.org, freebsd-current@freebsd.org Onderwerp: after trivial update, 15.0 ARM64

Re: after trivial update, 15.0 ARM64 system no longer boots

Are you sure that the system isn't actually booting or are you saying that because you get no console output after going to userland? It's possible that /etc/ttys is not in sync with your console configuration in loader.conf. If that happened, nothing from /etc/rc would print to console during

after trivial update, 15.0 ARM64 system no longer boots

hi lists, i have a FreeBSD 15.0/arm64 system, an RPi4, which was previously running 15.0 with pkgbase. i rebuilt main on my pkg server and updated the RPi with 'pkg update', which only included ~2 commits neither of which seemed like they had anything to do with booting, but after the update,

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

Dear FreeBSD Community, The deadline for the next FreeBSD Status Report update is March, 31st 2024 for work done since the last round of quarterly reports: January 2024 - March 2024. I would like to remind you that reports are published on a quarterly basis and are usually collected during the

Chromium can't be compiled because a bug with webrtc.

Hello. On FreeBSD 13.3 I'm trying to install Chromium,but the compilation stopped because a bug : . /usr/local/include -c ../../third_party/webrtc/api/candidate.cc -o obj/third_party/webrtc/api/candi date/candidate.o In file included from ../../third_party/webrtc/api/candidate.cc:11: In

Re: Request for Testing: TCP RACK

> On 14. Mar 2024, at 11:04, Dag-Erling Smørgrav wrote: > > tue...@freebsd.org writes: >> Gary Jennejohn writes: >>> In the article we have option TCPHPTS and option TCP_RACK. But in >>> /sys/conf/NOTES we have options TCPHPTS and options TCP_RACK and >>> not option. >> Thanks for reporting,

Re: Request for Testing: TCP RACK

tue...@freebsd.org writes: > Gary Jennejohn writes: > > In the article we have option TCPHPTS and option TCP_RACK. But in > > /sys/conf/NOTES we have options TCPHPTS and options TCP_RACK and > > not option. > Thanks for reporting, that is a typo in the article. It should > always read options

Re: Request for Testing: TCP RACK

> On 13. Mar 2024, at 08:06, Gary Jennejohn wrote: > > On Tue, 12 Mar 2024 20:14:17 +0100 > tue...@freebsd.org wrote: > >>> On 12. Mar 2024, at 14:39, Nuno Teixeira wrote: >>> >>> Hello, >>> >>> I'm curious about tcp RACK. >>> >>> As I do not run on a server background, only a laptop and a

Re: Request for Testing: TCP RACK

On Tue, 12 Mar 2024 20:14:17 +0100 tue...@freebsd.org wrote: > > On 12. Mar 2024, at 14:39, Nuno Teixeira wrote: > > > > Hello, > > > > I'm curious about tcp RACK. > > > > As I do not run on a server background, only a laptop and a rpi4 for > > poudriere, git, browsing, some torrent and ssh/sftp

Re: ZPool on iSCSI storage not available after a reboot

On 3/12/24 15:41, Alan Somers wrote: On Tue, Mar 12, 2024 at 1:28 PM Dennis Clarke wrote: . . . . Yes, this looks exactly like an ordering problem. zpools get imported early in the boot process, under the assumption that most of them are local. Networking comes up later, under the

Re: ZPool on iSCSI storage not available after a reboot

On Tue, Mar 12, 2024 at 1:28 PM Dennis Clarke wrote: > > > This is a somewhat odd problem and may have nothing to do with iSCSI > config at all. Suffice it to say that I have the following in the server > /etc/rc.conf : > > # > # the iSCSI initiator > iscsid_enable="YES" > iscsictl_enable="YES" >

ZPool on iSCSI storage not available after a reboot

This is a somewhat odd problem and may have nothing to do with iSCSI config at all. Suffice it to say that I have the following in the server /etc/rc.conf : # # the iSCSI initiator iscsid_enable="YES" iscsictl_enable="YES" iscsictl_flags="-Aa" # During boot I see this on the console :

Re: Request for Testing: TCP RACK

> On 12. Mar 2024, at 14:39, Nuno Teixeira wrote: > > Hello, > > I'm curious about tcp RACK. > > As I do not run on a server background, only a laptop and a rpi4 for > poudriere, git, browsing, some torrent and ssh/sftp connections, will > I see any difference using RACK? > What tests should I

Re: Request for Testing: TCP RACK

On 3/12/24 6:39 AM, Nuno Teixeira wrote: Hello, I'm curious about tcp RACK. As I do not run on a server background, only a laptop and a rpi4 for poudriere, git, browsing, some torrent and ssh/sftp connections, will I see any difference using RACK? What tests should I do for comparison? I

Re: Request for Testing: TCP RACK

Hello, I'm curious about tcp RACK. As I do not run on a server background, only a laptop and a rpi4 for poudriere, git, browsing, some torrent and ssh/sftp connections, will I see any difference using RACK? What tests should I do for comparison? Thanks, escreveu (quinta, 16/11/2023 à(s)

Re: Reason why "nocache" option is not displayed in "mount"?

On Mon, Mar 11, 2024 at 09:03:38AM +0100, Alexander Leidinger wrote: > Am 2024-03-10 22:57, schrieb Konstantin Belousov: > > > We are already low on the free bits in the flags, even after expanding > > them > > to 64bit. More, there are useful common fs services continuously > > consuming > >

Re: Reason why "nocache" option is not displayed in "mount"?

Am 2024-03-10 22:57, schrieb Konstantin Belousov: We are already low on the free bits in the flags, even after expanding them to 64bit. More, there are useful common fs services continuously consuming that flags, e.g. the recent NFS TLS options. I object against using the flags for

Re: Reason why "nocache" option is not displayed in "mount"?

On Sun, Mar 10, 2024 at 09:50:51PM +, Kirk McKusick wrote: > > Date: Sun, 10 Mar 2024 19:21:54 +0200 > > From: Konstantin Belousov > > To: Kirk McKusick > > Cc: curr...@freebsd.org > > Subject: Re: Reason why "nocache" option is not displayed in "mount"? > > > > On Sun, Mar 10, 2024 at

Re: Reason why "nocache" option is not displayed in "mount"?

> Date: Sun, 10 Mar 2024 19:21:54 +0200 > From: Konstantin Belousov > To: Kirk McKusick > Cc: curr...@freebsd.org > Subject: Re: Reason why "nocache" option is not displayed in "mount"? > > On Sun, Mar 10, 2024 at 01:53:05AM +, Kirk McKusick wrote: >> The issue has to do with how flags are

Re: RFC: should a va_bytes option be added to vn_getsize_locked()?

On Sat, Mar 09, 2024 at 04:59:49PM -0800, Rick Macklem wrote: > Hi, > > I would like to compare va_size to va_bytes in vn_generic_copy_file_range(), > as a heuristic to check for a sparse file (only works for non-compressed > file systems). > > The call to VOP_GETATTR(invp, ..) was replaced by

Re: Reason why "nocache" option is not displayed in "mount"?

On Sun, Mar 10, 2024 at 01:53:05AM +, Kirk McKusick wrote: > The issue has to do with how flags are defined in mount.h. > Specifically there are the flags that are externally visible > (prefixed with MNT_) and those that are for internal use > (prefixed with MNTK_, the K standing for KERNEL).

Re: Reason why "nocache" option is not displayed in "mount"?

Kirk McKusick wrote on Date: Sun, 10 Mar 2024 01:53:05 UTC : > The issue has to do with how flags are defined in mount.h. > Specifically there are the flags that are externally visible > (prefixed with MNT_) and those that are for internal use > (prefixed with MNTK_, the K standing for KERNEL).

Re: Reason why "nocache" option is not displayed in "mount"?

The issue has to do with how flags are defined in mount.h. Specifically there are the flags that are externally visible (prefixed with MNT_) and those that are for internal use (prefixed with MNTK_, the K standing for KERNEL). If it is desirable to have MNTK_NULL_NOCACHE visible, then it should be

RFC: should a va_bytes option be added to vn_getsize_locked()?

Hi, I would like to compare va_size to va_bytes in vn_generic_copy_file_range(), as a heuristic to check for a sparse file (only works for non-compressed file systems). The call to VOP_GETATTR(invp, ..) was replaced by vn_getsize_locked() in vn_generic_copy_file_range(). To get va_bytes I can

Re: Boot failure, amd64 (HP EliteBook 650 G10)

Hi Graham, On 3/9/24 10:52, Graham Perrin wrote: amd64. AFAICT the EliteBook 650 G10 was introduced around May 2023. Does anything in the three photographs tally with a report in Bugzilla? Any overlap with

Re: Reason why "nocache" option is not displayed in "mount"?

Am 2024-03-09 15:27, schrieb Rick Macklem: On Sat, Mar 9, 2024 at 5:08 AM Alexander Leidinger wrote: Am 2024-03-09 06:07, schrieb Warner Losh: > On Thu, Mar 7, 2024 at 1:05 PM Jamie Landeg-Jones > wrote: > >> Alexander Leidinger wrote: >> >>> Hi, >>> >>> what is the reason why "nocache" is

Re: Boot failure, amd64 (HP EliteBook 650 G10)

I'd love to borrow one of these machines fir a week or so. Warner On Sat, Mar 9, 2024, 2:52 AM Graham Perrin wrote: > > > amd64. > > AFAICT the EliteBook 650 G10 was introduced around May 2023. > > Does anything in the three photographs

Re: Reason why "nocache" option is not displayed in "mount"?

On Sat, Mar 9, 2024 at 5:08 AM Alexander Leidinger wrote: > > Am 2024-03-09 06:07, schrieb Warner Losh: > > > On Thu, Mar 7, 2024 at 1:05 PM Jamie Landeg-Jones > > wrote: > > > >> Alexander Leidinger wrote: > >> > >>> Hi, > >>> > >>> what is the reason why "nocache" is not displayed in the

Re: Reason why "nocache" option is not displayed in "mount"?

Am 2024-03-09 06:07, schrieb Warner Losh: On Thu, Mar 7, 2024 at 1:05 PM Jamie Landeg-Jones wrote: Alexander Leidinger wrote: Hi, what is the reason why "nocache" is not displayed in the output of "mount" for nullfs options? Good catch. I also notice that "hidden" is not shown either.

Boot failure, amd64 (HP EliteBook 650 G10)

amd64. AFAICT the EliteBook 650 G10 was introduced around May 2023. Does anything in the three photographs tally with a report in Bugzilla? Any overlap with

Re: Kernel build broken without "options KTRACE"

On Wed, Mar 06, 2024 at 10:51:05AM -0700, John Nielsen wrote: > Getting a set but not used warning for “td” in sys/kern/kern_condvar.c when > doing a buildkernel for a config file without “options KTRACE”. I failed to > copy the full error message/line numbers but I will reproduce this evening

Re: Reason why "nocache" option is not displayed in "mount"?

On Thu, Mar 7, 2024 at 1:05 PM Jamie Landeg-Jones wrote: > Alexander Leidinger wrote: > > > Hi, > > > > what is the reason why "nocache" is not displayed in the output of > > "mount" for nullfs options? > > Good catch. I also notice that "hidden" is not shown either. > > I guess that as for

Re: Unable to boot -CURRENT on Thinkpad P16s G2

On Thu, Mar 7, 2024 at 4:50 PM Doug Ambrisko wrote: > On Thu, Mar 07, 2024 at 07:15:48PM +0100, Philipp Ost wrote: > | On 2/28/24 21:10, Philipp Ost wrote: > | [boot log stripped] > | > Does anyone have any suggestions on how to proceed at this point? [..] > | > | Short follow-up: disabling

Re: Unable to boot -CURRENT on Thinkpad P16s G2

On Thu, Mar 07, 2024 at 07:15:48PM +0100, Philipp Ost wrote: | On 2/28/24 21:10, Philipp Ost wrote: | [boot log stripped] | > Does anyone have any suggestions on how to proceed at this point? [...] | | Short follow-up: disabling uart0 and uart1 at the loader prompt allowed us | to boot and

Re: Reason why "nocache" option is not displayed in "mount"?

Jamie Landeg-Jones wrote: > Good catch. I also notice that "hidden" is not shown either. Sorry, I meant mount option "ignore" not "hidden".

Re: Reason why "nocache" option is not displayed in "mount"?

Alexander Leidinger wrote: > Hi, > > what is the reason why "nocache" is not displayed in the output of > "mount" for nullfs options? Good catch. I also notice that "hidden" is not shown either. I guess that as for some time, "nocache" was a "secret" option, no-one update "mount" to display

Re: Unable to boot -CURRENT on Thinkpad P16s G2

On 2/28/24 21:10, Philipp Ost wrote: [boot log stripped] Does anyone have any suggestions on how to proceed at this point? [...] Short follow-up: disabling uart0 and uart1 at the loader prompt allowed us to boot and install FreeBSD (the -CURRENT snapshot from 2024-02-29 in case it matters).

Re: Reason why "nocache" option is not displayed in "mount"?

Am 2024-03-07 14:59, schrieb Christos Chatzaras: what is the reason why "nocache" is not displayed in the output of "mount" for nullfs options? # grep packages /etc/fstab.commit_leidinger_net /shared/ports/packages /space/jails/commit.leidinger.net/shared/ports/packages

Re: Reason why "nocache" option is not displayed in "mount"?

> what is the reason why "nocache" is not displayed in the output of "mount" > for nullfs options? > > # grep packages /etc/fstab.commit_leidinger_net > /shared/ports/packages > /space/jails/commit.leidinger.net/shared/ports/packages nullfs > rw,noatime,nocache 0 0 >

Reason why "nocache" option is not displayed in "mount"?

Hi, what is the reason why "nocache" is not displayed in the output of "mount" for nullfs options? # grep packages /etc/fstab.commit_leidinger_net /shared/ports/packages /space/jails/commit.leidinger.net/shared/ports/packages nullfs rw,noatime,nocache 0 0 # mount |

Re: FreeBSD panics possibly caused by nfs clients

On Wed, Mar 6, 2024 at 10:56 AM Matthew L. Dailey wrote: > > Posting a few updates on this issue. > > I was able to induce a panic on a CURRENT kernel (20240215), built with > GENERIC-KASAN and running kern.kstack_pages=6 (default) after ~189 > hours. The panic message and backtrace are below -

Re: FreeBSD panics possibly caused by nfs clients

Posting a few updates on this issue. I was able to induce a panic on a CURRENT kernel (20240215), built with GENERIC-KASAN and running kern.kstack_pages=6 (default) after ~189 hours. The panic message and backtrace are below - please reach out directly if you'd like to have a look at the core.

Kernel build broken without "options KTRACE"

Getting a set but not used warning for “td” in sys/kern/kern_condvar.c when doing a buildkernel for a config file without “options KTRACE”. I failed to copy the full error message/line numbers but I will reproduce this evening if needed. JN

Re: main [so: 15] context, 7950X3D and RTL8251/8153 based Ethernet dongle: loss of state, example log information

On 3/4/24 21:39, Alexander Motin wrote: AFAIK it is only a workaround.  I saw it myself on number of different USB dongles and laptops, that USB starting experience some problems with multiple NIC queues and some other factors. IIRC the Realtek driver was much more stable once I limited it

Re: main [so: 15] context, 7950X3D and RTL8251/8153 based Ethernet dongle: loss of state, example log information

Jakob Alvermark writes: > I tried using the cdce driver, it gives me < 100Mb/s, while the ure > driver gets > 500Mb/s I'll take 100 stable Mb/s over 500 unstable Mb/s any day :-) (Back in my days we had only 10 Mb/s, and everybody shared them ) But yes, I agree that it would be nice if this

Re: main [so: 15] context, 7950X3D and RTL8251/8153 based Ethernet dongle: loss of state, example log information

On Mar 4, 2024, at 12:39, Alexander Motin wrote: > On 04.03.2024 15:33, Jakob Alvermark wrote: >> On 3/4/24 21:13, Alexander Motin wrote: >>> On 04.03.2024 15:00, Poul-Henning Kamp wrote: >> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to DOWN >> Nov 30 03:23:18

Re: main [so: 15] context, 7950X3D and RTL8251/8153 based Ethernet dongle: loss of state, example log information

On 04.03.2024 15:33, Jakob Alvermark wrote: On 3/4/24 21:13, Alexander Motin wrote: On 04.03.2024 15:00, Poul-Henning Kamp wrote: Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to DOWN Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to UP Nov 30 03:23:18 7950X3D-UFS

Re: main [so: 15] context, 7950X3D and RTL8251/8153 based Ethernet dongle: loss of state, example log information

On 3/4/24 21:13, Alexander Motin wrote: On 04.03.2024 15:00, Poul-Henning Kamp wrote: Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to DOWN Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to UP Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to DOWN Nov 30

Re: main [so: 15] context, 7950X3D and RTL8251/8153 based Ethernet dongle: loss of state, example log information

On 04.03.2024 15:00, Poul-Henning Kamp wrote: Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to DOWN Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to UP Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to DOWN Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link

Re: main [so: 15] context, 7950X3D and RTL8251/8153 based Ethernet dongle: loss of state, example log information

>> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to DOWN >> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to UP >> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to DOWN >> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to UP >> Nov 30 03:23:18

Re: Buildworld stops for d3befb534b9 in tests

On Mon, Mar 04, 2024 at 09:54:14AM -0800, Mark Millard wrote: > bob prohaska wrote on > Date: Mon, 04 Mar 2024 16:35:52 UTC : > > > An armv7 (Pi2 v1.1) -current system stopped buildworld with > > > > c++: error: linker command failed with exit code 1 (use -v to see > > invocation) > > ***

Re: main [so: 15] context, 7950X3D and RTL8251/8153 based Ethernet dongle: loss of state, example log information

On Mar 3, 2024, at 23:25, Jakob Alvermark wrote: > On 12/4/23 09:16, Mark Millard wrote: >> The following sort of thing is happening a lot: >> >> Ryzen 9 7950X3D using a USB Ethernet dongle that I've historically >> used on occasion, sometimes for long periods . . . >> >> Example contexts for

<    1   2   3   4   5   6   7   8   9   10   >