Re: Request for Testing: TCP RACK

terrupt, its more efficient >> to run >> >>>>>>> it out of a system call context at just the point where we return >> to >> >>>>>>> userspace and the cache is trashed anyway. The current >> implementation >> >>>>>

Re: Request for Testing: TCP RACK

>>>> Ast's could be the right tool for this, but I'm super unfamiliar > with > >>>>>>> them, and I can't find any docs on them. > >>>>>>> > >>>>>>> Would ast_register(0, ASTR_UNCOND, 0, func) be roughly eq

Re: Request for Testing: TCP RACK

T number added, and then it registers the >>>>>> ast to run on next return to userspace, for the current thread. >>>>>> >>>>>> Is it enough? >>>>>>> >>>>>>> Drew >>>>>&

Re: Request for Testing: TCP RACK

;>>>>> > >>>>>> Drew > >>>>> > >>>>>> > >>>>>> On Mon, Mar 18, 2024, at 2:33 PM, Konstantin Belousov wrote: > >>>>>>> On Mon, Mar 18, 2024 at 07:26:10AM -0500, Mike Karels wro

Re: Request for Testing: TCP RACK

tin Belousov wrote: >>>>>>> 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:

Re: Request for Testing: TCP RACK

..@freebsd.org wrote: > > > > > > > > > > > > > > >> On 18. Mar 2024, at 12:42, Nuno Teixeira > > > > wrote: > > > > > > > >> > > > > > > > >> Hello all! > > > > > > > >> > > > >

Re: Request for Testing: TCP RACK

gt; > > > > > > > > > > > >> On 18. Mar 2024, at 12:42, Nuno Teixeira > > > > wrote: > > > > > > > >> > > > > > > > >> Hello all! > > > > > > > >> > > > > > > &g

Re: Request for Testing: TCP RACK

> > > >> > > > > > > >> Hello all! > > > > > > >> > > > > > > >> It works just fine! > > > > > > >> System performance is OK. > > > > > > >> Using patch on main-n

Re: Request for Testing: TCP RACK

; > >> PCB count > > > > >> freebsd freebsd 0 > > > > >> rack* rack 38 > > > > >> --- > > > > >> > > > > &g

Re: Request for Testing: TCP RACK

>> freebsd freebsd 0 > > > >> rack* rack 38 > > > >> --- > > > >> > > > >> It would be so nice that we can have a sysctl tunn

Re: Request for Testing: TCP RACK

0 > > >> rack* rack 38 > > >> --- > > >> > > >> It would be so nice that we can have a sysctl tunnable for this patch > > >> so we could do more tests without recompiling

Re: Request for Testing: TCP RACK

freebsd 0 > >> rack* rack 38 > >> --- > >> > >> It would be so nice that we can have a sysctl tunnable for this patch > >> so we could do more tests witho

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

Re: Request for Testing: TCP RACK

t; >> 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 Netflix > and allows to mitigate the performance reg

Re: Request for Testing: TCP RACK

PCB count > freebsd freebsd 0 > rack* rack 38 > --- > > It would be so nice that we can have a sysctl tunnable for this patch > so we could do more t

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

rack in /etc/sysctl.conf This means that no TCP connection will actually use the RACK stack. > >> What does "poudriere testport net/gitup" do? Only build stuff or does is >> also download something? >> >> What does bonnie++ do? > > poudriere is for testin

Re: Request for Testing: TCP RACK

gt; >>> Also use pf. This is a test machine so not a lot happening on it. > > >>> > > >>> Are there any thing we can test? Do we have some test scripts we can > > >>> run? > > >> We are actually interested in feedback a

Re: Request for Testing: TCP RACK

does bonnie++ do? poudriere is for testing ports and it uses jails to build stuff. It have restrict access to net to fetch distfiles (not the case as distfile is present on disk) bonnie++ is a disk benchmark > Could you reboot the system, run the test, do kldload tcphpts, run > the test a

Re: Request for Testing: TCP RACK

up" do? Only build stuff or does is also download something? What does bonnie++ do? Could you reboot the system, run the test, do kldload tcphpts, run the test again, do kldload tcp_rack, and run it again. I'm wondering if tcphpts is affecting the measurements... Thanks for testing. Best rega

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

htps 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" Best regards Michael > I'm testing it and check its performance. > > I will test again on my amd64 laptop and run more tests too. > > > -- > Nuno Teixeira > FreeBSD Committer (ports)

Re: Request for Testing: TCP RACK

, used by RACK and BBR. As tuexen said, on main, loader.conf: tcp_rack_load="YES" will load tcphpts.ko as I am seing in my rpi4 right now. I'm testing it and check its performance. I will test again on my amd64 laptop and run more tests too. -- Nuno Teixeira FreeBSD Committer (ports)

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

(sábado, 16/03/2024 à(s) 09:40): > > 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 t

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

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

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

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: KERNCONF=GENERIC

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

d the following article in the FreeBSD Journal: >> https://freebsdfoundation.org/our-work/journal/browser-based-edition/rack-and-alternate-tcp-stacks-for-freebsd/ >> >> There is no specific area for testing. Just test the stack on >> the systems you use with the workload yo

Re: Request for Testing: TCP RACK

al/browser-based-edition/rack-and-alternate-tcp-stacks-for-freebsd/ > > There is no specific area for testing. Just test the stack on > the systems you use with the workload you use and report back > any issues... > 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. -- Gary Jennejohn

Re: Request for Testing: TCP RACK

RACK? > What tests should I do for comparison? You might want to read the following article in the FreeBSD Journal: https://freebsdfoundation.org/our-work/journal/browser-based-edition/rack-and-alternate-tcp-stacks-for-freebsd/ There is no specific area for testing. Just test th

Re: Request for Testing: TCP RACK

found this blog post from Klara was a good backgrounder to get my comfortable with testing out RACK: https://klarasystems.com/articles/using-the-freebsd-rack-tcp-stack/ I've been using it on a busy'ish server and a workstation without any issues, but I'll defer to others as to what areas

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: Request for Testing: TCP RACK

On Tue, 06 Feb 2024 23:05:27 +0100, tue...@freebsd.org wrote: > > > On Jan 5, 2024, at 08:48, tue...@freebsd.org wrote: > > > >> On Jan 4, 2024, at 21:39, Herbert J. Skuhra wrote: > >> > >> On Thu, 04 Jan 2024 21:22:22 +0100, tue...@freebsd.org wrote: > >>> > On Jan 4, 2024, at 18:52,

Re: Request for Testing: TCP RACK

> On Jan 5, 2024, at 08:48, tue...@freebsd.org wrote: > >> On Jan 4, 2024, at 21:39, Herbert J. Skuhra wrote: >> >> On Thu, 04 Jan 2024 21:22:22 +0100, tue...@freebsd.org wrote: >>> On Jan 4, 2024, at 18:52, Herbert J. Skuhra wrote: On Thu, 04 Jan 2024 11:40:35 +0100, "Herbert

Re: Request for Testing: TCP RACK

W dniu 17.11.2023 o 00:13, tue...@fh-muenster.de pisze: On Nov 16, 2023, at 17:50, Marek Zarychta wrote: W dniu 16.11.2023 o 10:13, tue...@freebsd.org pisze: Dear all, recently the main branch was changed to build the TCP RACK stack which is a loadable kernel module, by default:

Re: Request for Testing: TCP RACK

> On Jan 4, 2024, at 21:39, Herbert J. Skuhra wrote: > > On Thu, 04 Jan 2024 21:22:22 +0100, tue...@freebsd.org wrote: >> >>> On Jan 4, 2024, at 18:52, Herbert J. Skuhra wrote: >>> >>> On Thu, 04 Jan 2024 11:40:35 +0100, "Herbert J. Skuhra" wrote: On Fri, 17 Nov 2023 14:31:02

Re: Request for Testing: TCP RACK

On Thu, 04 Jan 2024 21:22:22 +0100, tue...@freebsd.org wrote: > > > On Jan 4, 2024, at 18:52, Herbert J. Skuhra wrote: > > > > On Thu, 04 Jan 2024 11:40:35 +0100, "Herbert J. Skuhra" wrote: > >> > >> On Fri, 17 Nov 2023 14:31:02 +0100, "Herbert J. Skuhra" wrote: > >>> > >>> Hi, > >>> > >>>

Re: Request for Testing: TCP RACK

> On Jan 4, 2024, at 18:52, Herbert J. Skuhra wrote: > > On Thu, 04 Jan 2024 11:40:35 +0100, "Herbert J. Skuhra" wrote: >> >> On Fri, 17 Nov 2023 14:31:02 +0100, "Herbert J. Skuhra" wrote: >>> >>> Hi, >>> >>> On Fri, 17 Nov 2023 00:15:13 +0100, tue...@freebsd.org wrote: > On Nov

Re: Request for Testing: TCP RACK

On Thu, 04 Jan 2024 11:40:35 +0100, "Herbert J. Skuhra" wrote: > > On Fri, 17 Nov 2023 14:31:02 +0100, "Herbert J. Skuhra" wrote: > > > > Hi, > > > > On Fri, 17 Nov 2023 00:15:13 +0100, tue...@freebsd.org wrote: > > > > > > > On Nov 16, 2023, at 20:06, Herbert J. Skuhra wrote: > > > > > > >

Re: Request for Testing: TCP RACK

> On Jan 4, 2024, at 15:22, Herbert J. Skuhra wrote: > > On Thu, 04 Jan 2024 14:57:59 +0100, tue...@fh-muenster.de wrote: >> >>> On Jan 4, 2024, at 11:40, Herbert J. Skuhra wrote: >>> >>> On Fri, 17 Nov 2023 14:31:02 +0100, "Herbert J. Skuhra" wrote: Hi, On Fri, 17 Nov

Re: Request for Testing: TCP RACK

> On Jan 4, 2024, at 11:40, Herbert J. Skuhra wrote: > > On Fri, 17 Nov 2023 14:31:02 +0100, "Herbert J. Skuhra" wrote: >> >> Hi, >> >> On Fri, 17 Nov 2023 00:15:13 +0100, tue...@freebsd.org wrote: >>> On Nov 16, 2023, at 20:06, Herbert J. Skuhra wrote: On Thu, 16 Nov 2023

Re: Request for Testing: TCP RACK

On Thu, 04 Jan 2024 14:57:59 +0100, tue...@fh-muenster.de wrote: > > > On Jan 4, 2024, at 11:40, Herbert J. Skuhra wrote: > > > > On Fri, 17 Nov 2023 14:31:02 +0100, "Herbert J. Skuhra" wrote: > >> > >> Hi, > >> > >> On Fri, 17 Nov 2023 00:15:13 +0100, tue...@freebsd.org wrote: > >>> >

Re: Request for Testing: TCP RACK

On Fri, 17 Nov 2023 14:31:02 +0100, "Herbert J. Skuhra" wrote: > > Hi, > > On Fri, 17 Nov 2023 00:15:13 +0100, tue...@freebsd.org wrote: > > > > > On Nov 16, 2023, at 20:06, Herbert J. Skuhra wrote: > > > > > > On Thu, 16 Nov 2023 19:07:29 +0100, Olivier Cochard-Labbé wrote: > > >> > > >> On

Re: Request for Testing: TCP RACK

> On Nov 19, 2023, at 2:35 AM, Zhenlei Huang wrote: > > > >> On Nov 16, 2023, at 5:13 PM, tue...@freebsd.org wrote: >> >> Dear all, >> >> recently the main branch was changed to build the TCP RACK stack >> which is a loadable kernel module, by default: >>

Re: Request for Testing: TCP RACK

n test? Do we have some test scripts we can run? > >> We are actually interested in feedback about using the stack in whatever > >> use case you use TCP for. The stack has been tested with the Netflix use > >> case, but not so much with others. That is why we ask for broa

Re: Request for Testing: TCP RACK

> On Nov 16, 2023, at 5:13 PM, tue...@freebsd.org wrote: > > Dear all, > > recently the main branch was changed to build the TCP RACK stack > which is a loadable kernel module, by default: > https://cgit.FreeBSD.org/src/commit/?id=3a338c534154164504005beb00a3c6feb03756cc > > As discussed on

Re: Request for Testing: TCP RACK

whatever >> use case you use TCP for. The stack has been tested with the Netflix use >> case, but not so much with others. That is why we ask for broader testing. >> >> Best regards >> Michael > > Are there any difference regarding with performance between main

Re: Request for Testing: TCP RACK

se, but not so much with others. That is why we ask for broader testing. > > Best regards > Michael Are there any difference regarding with performance between main and stable/14? If so, please ignore below. I have stable/14 environment which is configured to be able to switch to TCP RACK and

Re: Request for Testing: TCP RACK

some test scripts we can run? We are actually interested in feedback about using the stack in whatever use case you use TCP for. The stack has been tested with the Netflix use case, but not so much with others. That is why we ask for broader testing. Best regards Michael > > > >

Re: Request for Testing: TCP RACK

I am running the rack stack for quiet some time now on a baremetal machiene and never had problems. Also use pf.  This is a test machine so not a lot happening on it. Are there any thing we can test? Do we have some test scripts we can run?

Re: Request for Testing: TCP RACK

Am 2023-11-17 14:29, schrieb void: On Thu, Nov 16, 2023 at 10:13:05AM +0100, tue...@freebsd.org wrote: You can load the kernel module using kldload tcp_rack You can make the RACK stack the default stack using sysctl net.inet.tcp.functions_default=rack Hi, thank you for this.

Re: Request for Testing: TCP RACK

Hi, On Fri, Nov 17, 2023 at 02:46:52PM +0100, Olivier Cochard-Labbé wrote: > On Fri, Nov 17, 2023 at 2:31 PM Herbert J. Skuhra wrote: > > > > > 1. It even fails with a simple pf.conf: > >pass in all > >pass out all > > > > 2. Fetching port distfiles also failed. > > > > 3. If I disable

Re: Request for Testing: TCP RACK

On Fri, Nov 17, 2023 at 2:31 PM Herbert J. Skuhra wrote: > > 1. It even fails with a simple pf.conf: >pass in all >pass out all > > 2. Fetching port distfiles also failed. > > 3. If I disable rxcsum on the ethernet adapter (igb0) it works. > > > I can't reproduce it with pfctl too (same

Re: Request for Testing: TCP RACK

Hi, On Fri, 17 Nov 2023 00:15:13 +0100, tue...@freebsd.org wrote: > > > On Nov 16, 2023, at 20:06, Herbert J. Skuhra wrote: > > > > On Thu, 16 Nov 2023 19:07:29 +0100, Olivier Cochard-Labbé wrote: > >> > >> On Thu, Nov 16, 2023 at 5:10 PM Herbert J. Skuhra > >> wrote: > >> > >>> > >>> OK,

Re: Request for Testing: TCP RACK

in various -RELENG maybe where one can compile in a vm built for that purpose, then transferring to the production vm? Would it be expected to work on arm64? What testing would you like doing? --

Re: Request for Testing: TCP RACK

> On Nov 16, 2023, at 20:06, Herbert J. Skuhra wrote: > > On Thu, 16 Nov 2023 19:07:29 +0100, Olivier Cochard-Labbé wrote: >> >> On Thu, Nov 16, 2023 at 5:10 PM Herbert J. Skuhra wrote: >> >>> >>> OK, I am now running GENERIC-NODEBUG + "options TCPHPTS". >>> >>> After setting "sysctl

Re: Request for Testing: TCP RACK

> On Nov 16, 2023, at 14:05, Herbert J. Skuhra wrote: > > On Thu, 16 Nov 2023 13:06:03 +0100, "Herbert J. Skuhra" wrote: >> >> Hi, >> >> On Thu, 16 Nov 2023 10:13:05 +0100, tue...@freebsd.org wrote: >>> >>> Dear all, >>> >>> recently the main branch was changed to build the TCP RACK stack

Re: Request for Testing: TCP RACK

> On Nov 16, 2023, at 13:06, Herbert J. Skuhra wrote: > > Hi, > > On Thu, 16 Nov 2023 10:13:05 +0100, tue...@freebsd.org wrote: >> >> Dear all, >> >> recently the main branch was changed to build the TCP RACK stack >> which is a loadable kernel module, by default: >>

Re: Request for Testing: TCP RACK

On Thu, 16 Nov 2023 19:07:29 +0100, Olivier Cochard-Labbé wrote: > > On Thu, Nov 16, 2023 at 5:10 PM Herbert J. Skuhra wrote: > > > > > OK, I am now running GENERIC-NODEBUG + "options TCPHPTS". > > > > After setting "sysctl net.inet.tcp.functions_default=rack" git no > > longer works: > > > > >

Re: Request for Testing: TCP RACK

On Thu, Nov 16, 2023 at 5:10 PM Herbert J. Skuhra wrote: > > OK, I am now running GENERIC-NODEBUG + "options TCPHPTS". > > After setting "sysctl net.inet.tcp.functions_default=rack" git no > longer works: > > Are you using a fresh 15 head or a specific network setup ? Because I'm not able to

Re: Request for Testing: TCP RACK

W dniu 16.11.2023 o 10:13, tue...@freebsd.org pisze: Dear all, recently the main branch was changed to build the TCP RACK stack which is a loadable kernel module, by default: https://cgit.FreeBSD.org/src/commit/?id=3a338c534154164504005beb00a3c6feb03756cc That's really good news and

Re: Request for Testing: TCP RACK

On Thu, 16 Nov 2023 13:06:03 +0100, "Herbert J. Skuhra" wrote: > > Hi, > > On Thu, 16 Nov 2023 10:13:05 +0100, tue...@freebsd.org wrote: > > > > Dear all, > > > > recently the main branch was changed to build the TCP RACK stack > > which is a loadable kernel module, by default: > >

Re: Request for Testing: TCP RACK

Hi, On Thu, 16 Nov 2023 10:13:05 +0100, tue...@freebsd.org wrote: > > Dear all, > > recently the main branch was changed to build the TCP RACK stack > which is a loadable kernel module, by default: > https://cgit.FreeBSD.org/src/commit/?id=3a338c534154164504005beb00a3c6feb03756cc > > As

Request for Testing: TCP RACK

Dear all, recently the main branch was changed to build the TCP RACK stack which is a loadable kernel module, by default: https://cgit.FreeBSD.org/src/commit/?id=3a338c534154164504005beb00a3c6feb03756cc As discussed on the bi-weekly transport call, it would be great if people could test the RACK

I've shown the following 3 items via kyua testing with the latest snapshot of armv7 14 on a OrangePi+2Ed (Cortex-A7), a panic included

servers and are for kyua activity's use, other than gdb. The presence of panic and large count of hours waiting for timeouts explain why this report only covers specific issues and no a full kyua run at this point. [I'll note that this activity has been driven by attempted testing of lib32, where I

FYI for aarch64/armv7 lib32: armv7 kyua test sys/net/if_bridge_test:gif with preloaded if_bridge.ko still panics in my style of testing

I finally got around to testing lib32 some more, first trying the panic case that I'd gotten in early testing. The below is without any special lib32 patching for testing, just my normal non-debug environment updated to a lib32-present aarch64 FreeBSD vintage. Reminder: /usr/obj/DESTDIRs/main-CA7

Re: Does kyua based testing need some hazmat/bindings/_openssl.abi3.so related updating?: Undefined symbol "ERR_GET_FUNC"

> On Jul 10, 2023, at 3:27 PM, Mark Millard wrote: > > On Jul 10, 2023, at 15:03, Mark Millard > wrote: > >> On Jul 10, 2023, at 11:42, The Doctor wrote: >> >>> On Mon, Jul 10, 2023 at 08:56:22AM -0700, Mark Millard wrote: The subject line's question was

Re: Does kyua based testing need some hazmat/bindings/_openssl.abi3.so related updating?: Undefined symbol "ERR_GET_FUNC"

On Jul 10, 2023, at 15:03, Mark Millard wrote: > On Jul 10, 2023, at 11:42, The Doctor wrote: > >> On Mon, Jul 10, 2023 at 08:56:22AM -0700, Mark Millard wrote: >>> The subject line's question was prompted by >>> . . ./hazmat/bindings/_openssl.abi3.so related notices >>> in a kyua report: >>>

Re: Does kyua based testing need some hazmat/bindings/_openssl.abi3.so related updating?: Undefined symbol "ERR_GET_FUNC"

On Jul 10, 2023, at 11:42, The Doctor wrote: > On Mon, Jul 10, 2023 at 08:56:22AM -0700, Mark Millard wrote: >> The subject line's question was prompted by >> . . ./hazmat/bindings/_openssl.abi3.so related notices >> in a kyua report: >> >> # kyua report --verbose >>

Re: Does kyua based testing need some hazmat/bindings/_openssl.abi3.so related updating?: Undefined symbol "ERR_GET_FUNC"

On Mon, Jul 10, 2023 at 08:56:22AM -0700, Mark Millard wrote: > The subject line's question was prompted by > . . ./hazmat/bindings/_openssl.abi3.so related notices > in a kyua report: > > # kyua report --verbose > --results-file=usr_obj_DESTDIRs_main-CA7-chroot_usr_tests.20230710-064632-752785

Re: Does kyua based testing need some hazmat/bindings/_openssl.abi3.so related updating?: Undefined symbol "ERR_GET_FUNC"

SL 3.0. > > But is the phython3 use by kyua of aarch64 code? armv7 code? > > # file /usr/obj/DESTDIRs/main-CA7-chroot/usr/bin/kyua > /usr/obj/DESTDIRs/main-CA7-chroot/usr/bin/kyua: ELF 32-bit LSB executable, > ARM, EABI5 version 1 (FreeBSD), dynamically linked, interpreter >

Re: Does kyua based testing need some hazmat/bindings/_openssl.abi3.so related updating?: Undefined symbol "ERR_GET_FUNC"

r/bin/kyua: ELF 32-bit LSB executable, ARM, EABI5 version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, FreeBSD-style, for FreeBSD 14.0 (1400092), not stripped So: armv7 for my lib32 testing activity. > Which version of kyua is this running (32 or 64 bit)? armv7 (so: 32-bit

Re: Does kyua based testing need some hazmat/bindings/_openssl.abi3.so related updating?: Undefined symbol "ERR_GET_FUNC"

On 10 Jul 2023, at 10:56, Mark Millard wrote: > The subject line's question was prompted by > . . ./hazmat/bindings/_openssl.abi3.so related notices > in a kyua report: > > # kyua report --verbose > --results-file=usr_obj_DESTDIRs_main-CA7-chroot_usr_tests.20230710-064632-752785 > 2>&1 | grep

Does kyua based testing need some hazmat/bindings/_openssl.abi3.so related updating?: Undefined symbol "ERR_GET_FUNC"

The subject line's question was prompted by . . ./hazmat/bindings/_openssl.abi3.so related notices in a kyua report: # kyua report --verbose --results-file=usr_obj_DESTDIRs_main-CA7-chroot_usr_tests.20230710-064632-752785 2>&1 | grep "Undefined symbol" | sort -u +ImportError:

Options for production testing under current(samba slow)

cd /usr/src/sys/amd64/conf cp GENERIC-NODEBUG MYKERNEL; (add: options BHYVE_SNAPSHOT) cd /usr/src make -j12 buildworld -DWITH_BHYVE_SNAPSHOT -DWITH_MALLOC_PRODUCTION make -j12 buildkernel KERNCONF=MYKERNEL make installkernel KERNCONF=MYKERNEL etc Been playing with current lately

Re: Testing 14-CURRENT-f44280bf5fb on aarch64

On 5/10/22 09:37, Daniel Morante wrote: Updated to the latest (14.0-CURRENT #2 main-n255521-10f44229dcd: Tue May 10 02:52:27 EDT 2022) and removed the sysctl option (hw.usb.disable_enumeration=1). Still seeing the problem.  The below just endlessly prints out on the console: ```

Re: Testing 14-CURRENT-f44280bf5fb on aarch64

Updated to the latest (14.0-CURRENT #2 main-n255521-10f44229dcd: Tue May 10 02:52:27 EDT 2022) and removed the sysctl option (hw.usb.disable_enumeration=1). Still seeing the problem.  The below just endlessly prints out on the console: ``` FreeBSD/arm64 (mars.morante.com) (ttyu0) login:

Re: Testing 14-CURRENT-f44280bf5fb on aarch64

On 5/4/22 09:49, Daniel Morante wrote: I'm still using the sysctl option "hw.usb.disable_enumeration=1" to prevent the USB devices from disconnecting/reconnecting every few seconds.  Other than that the improvement in stability with 14-CURRENT on aarach64 on this hardware is much better since

Testing 14-CURRENT-f44280bf5fb on aarch64

I have been testing 14-CURRENT-f44280bf5fb for the last few days and so far it's been okay on my hardware (Cavium ThunderX2). Most of the details of the system are saved in http://venus.morante.net/downloads/unibia/screenshots/freebsd/R281-T91/14-CURRENT-f44280bf5fb. I've only had one kernel

Testing needed:)

Hi! Can someone with arm media file path type of storage device and someone with apple UEFI 1.10 test https://reviews.freebsd.org/D22553 please:) Other tests are also very welcome:) thanks, toomas ___ freebsd-current@freebsd.org mailing list

[CALL FOR TESTING][PATCH]: Intel Comet Lake and Ice Lake HD Audio Support

Hi freebsd-current@ mailing list, I have a patch which adds support for the HD Audio Codecs for the Intel Comet Lake and Ice Lake PCHs. This is similar to my now-committed Cannon Lake HD Audio patch. Please find below the Bugzilla and Phabricator links (both have the patch): Bugzilla:

Re: FUSE Call for Testing

On Fri, 9 Aug 2019 15:38:06 +0200 Gary Jennejohn wrote: > On Fri, 9 Aug 2019 06:49:36 -0600 > Alan Somers wrote: > > [snip test results] > > > Thanks for the report, Gary. BTW, fusefs mounts are only > > interruptible when mounted with "-o intr". If you didn't use that > > option, then the

Re: FUSE Call for Testing

On Fri, Aug 9, 2019 at 7:38 AM Gary Jennejohn wrote: > > On Fri, 9 Aug 2019 06:49:36 -0600 > Alan Somers wrote: > > [snip test results] > > > Thanks for the report, Gary. BTW, fusefs mounts are only > > interruptible when mounted with "-o intr". If you didn't use that > > option, then the

Re: FUSE Call for Testing

On Fri, 9 Aug 2019 06:49:36 -0600 Alan Somers wrote: [snip test results] > Thanks for the report, Gary. BTW, fusefs mounts are only > interruptible when mounted with "-o intr". If you didn't use that > option, then the signal would only interrupt cp after the write to > fusefs was done.

Re: FUSE Call for Testing

On Fri, Aug 9, 2019 at 3:02 AM Gary Jennejohn wrote: > > On Thu, 8 Aug 2019 12:34:52 -0600 > Alan Somers wrote: > > [snip] > > > VM images: > > http://ftp0.nyi.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/13.0-CURRENT/amd64/20190808/ > > ISOs:

  1   2   3   4   5   6   7   8   9   10   >