real world hardware testing ci

. But question is do we have this kind of real world hardware testing in place? :-) Also hints / references on how to setup one-time-use Jails per build and runtime process that would execute untrusted code and scripts are welcome. I know Ports prohibits connectivity after fetch phase.. unfortunately

Re: Panic testing ZFS raidz expansion feature.

Hi Alexander, thank you very much, with your patch it works. -- Maurizio Il giorno ven 10 gen 2025 alle ore 16:08 Alexander Motin ha scritto: > Hi Maurizio, > > I was able to reproduce it on a real hardware. The critical points are > that vdev should have ashift > 9 and it should be a debug bui

Re: Panic testing ZFS raidz expansion feature.

Hi Maurizio, I was able to reproduce it on a real hardware. The critical points are that vdev should have ashift > 9 and it should be a debug build. This patch fixes it for me: https://github.com/openzfs/zfs/pull/16942 . On 10.01.2025 03:33, Maurizio Vairani wrote: I'm using vm-bhyve-1.5.0

Re: IBM ServeRAID M5110e and other mfi/mrsas users - call for testing / request for information

> On 27 Nov 2024, at 19.39, Ed Maste wrote: > > On Tue, 26 Nov 2024 at 14:59, Søren Schmidt wrote: >> >> I have several Dell servers (R640/R740) running 14-stable using mrsas and >> RAID10 volumes, UFS on FreeBSD, and I have experienced corrupted filesystems >> on reboot on 3 out of 14 serve

Re: IBM ServeRAID M5110e and other mfi/mrsas users - call for testing / request for information

On Tue, 26 Nov 2024 at 14:59, Søren Schmidt wrote: > > I have several Dell servers (R640/R740) running 14-stable using mrsas and > RAID10 volumes, UFS on FreeBSD, and I have experienced corrupted filesystems > on reboot on 3 out of 14 servers so its not consistent, its the same servers > that a

Re: [Call for testing] sound(4) races and panics

27.11.24 19:00, Christos Margiolis: Hello, I recently pushed a series of commits [1][2][3][4] to -CURRENT (will MFC to stable/14 soon) that fix several panics and races. If anyone is interested, I would appreciate some testing to make sure I haven't missed anything. Thanks. Christos [1]

[Call for testing] sound(4) races and panics

Hello, I recently pushed a series of commits [1][2][3][4] to -CURRENT (will MFC to stable/14 soon) that fix several panics and races. If anyone is interested, I would appreciate some testing to make sure I haven't missed anything. Thanks. Christos [1] https://cgit.freebsd.org/src/commi

Re: IBM ServeRAID M5110e and other mfi/mrsas users - call for testing / request for information

> On 26 Nov 2024, at 13.31, Johan Hendriks wrote: >> >> To test, set the loader tunable hw.mfi.mrsas_enable=1 in >> /boot/loader.conf. Confirm that mrsas is being used, and that the >> system functions properly. >> > I use Dell servers and i set the loader tuneable hw.mfi.mrsasa_enable=1 on > t

Re: IBM ServeRAID M5110e and other mfi/mrsas users - call for testing / request for information

On 25/11/2024 21:24, Ed Maste wrote: I have a review open to switch to mrsas(4) by default, for devices supported by both it and mfi(4). mrsas(4) should be better supported and more functional. The review: https://reviews.freebsd.org/D45476 mfi: default to using mrsas(4) for newer cards Howev

IBM ServeRAID M5110e and other mfi/mrsas users - call for testing / request for information

I have a review open to switch to mrsas(4) by default, for devices supported by both it and mfi(4). mrsas(4) should be better supported and more functional. The review: https://reviews.freebsd.org/D45476 mfi: default to using mrsas(4) for newer cards However, we have a report of volume corruption

Panic testing ZFS raidz expansion feature.

I want to test the ZFS raidz expansion feature. I have create a VM with vm-bhyve: # vm iso https://download.freebsd.org/snapshots/amd64/amd64/ISO-IMAGES/15.0/FreeBSD-15.0-CURRENT-amd64-20240718-a4469a0d19b6-271237-bootonly.iso # vm create fbsd15-bis I have increased the VM memory to 2G: # cat fbsd1

Re: Request for Testing: TCP RACK

>> 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 return >> to >> >>>>>>> userspace and the cache is trashed anyway. The current >>

Re: Request for Testing: TCP RACK

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

Re: Request for Testing: TCP RACK

ening here? >>>>>> This call would need some AST number added, and then it registers the >>>>>> ast to run on next return to userspace, for the current thread. >>>>>> >>>>>> Is it enough? >>>>>

Re: Request for Testing: TCP RACK

gt;>> > >>>>> Is it enough? > >>>>>> > >>>>>> Drew > >>>>> > >>>>>> > >>>>>> On Mon, Mar 18, 2024, at 2:33 PM, Konstantin Belousov wrote: > >>>>>>&g

Re: Request for Testing: TCP RACK

t;> On Mon, Mar 18, 2024, at 2:33 PM, Konstantin 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: >>>>>>>> >>>&g

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

Re: Request for Testing: TCP RACK

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

Re: Request for Testing: TCP RACK

t; wrote: > > > > > > >> > > > > > > >> Hello all! > > > > > > >> > > > > > > >> It works just fine! > > > > > > >> System performance is OK. > > > > > > >&

Re: Request for Testing: TCP RACK

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

Re: Request for Testing: TCP RACK

count > > > >> freebsd freebsd 0 > > > >> rack* rack 38 > > > >> --- > > > >> > > > >> It would be so nice that we ca

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

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 come

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

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 becau

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 perhaps

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 th

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 to

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 Dre

Re: Request for Testing: TCP RACK

ctions_default=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 i

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

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

Re: Request for Testing: TCP RACK

rt net/gitup" 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 test

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 [1]

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: tcp_rack_load="YES"

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 tcp

Re: Request for Testing: TCP RACK

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

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 t

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 con

Re: Request for Testing: TCP RACK

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

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

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

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 tim

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

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

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 ins

Re: Request for Testing: TCP RACK

o 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 the stack on >> the systems you use with the worklo

Re: Request for Testing: TCP RACK

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

sing 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 the st

Re: Request for Testing: TCP RACK

I 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

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) 15:10)

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

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: https://cgit.

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 +0100,

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

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 1

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 20

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

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

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: >> https://cgit.FreeBSD.org/src/commit

Re: Request for Testing: TCP RACK

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

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 t

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 and

Re: Request for Testing: TCP RACK

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 ex

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. https://klarasy

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 r

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 i

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

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 net.ine

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: >> https://cgit.FreeBSD.org/s

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 rep

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

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: > > https://cgit

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 discuss

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

eeBSD 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

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

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 prompt

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 >> --results-file=usr_obj_DEST

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"

be using OpenSSL 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, in

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

n-CA7-chroot/usr/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)? ar

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

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: /usr/obj/DESTDIRs/

  1   2   3   4   5   6   7   8   9   10   >