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.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 reproduce your problem on my system: >> >> $ uname -a >> FreeBSD bigone 15.0-CURRENT FreeBSD 15.0-CURRENT #0 >> main-n266452-070d9e3540e6: Thu Nov 16 17:53:15 CET 2023 >> root@bigone:/usr/obj/usr/src/amd64.amd64/sys/TCPHPTS >> amd64 >> $ cat /usr/src/sys/amd64/conf/TCPHPTS >> include GENERIC-NODEBUG >> ident TCPHPTS >> options TCPHPTS >> $ sysctl net.inet.tcp.functions_default >> net.inet.tcp.functions_default: rack >> $ git clone -q g...@github.com:freebsd/freebsd-src.git && echo working >> working >> $ > > OK, (g)it works if I disable pf. Do you use pf? Can you share your pf config such that I can reproduce the problem locally? Best regards Michael > > -- > Herbert
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 >>> 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 stack for their workload. Please report any problems to >>> the >>> net@ mailing list or open an issue in the bug tracker and drop me a note >>> via email. >>> This includes regressions in CPU usage, regressions in performance or any >>> other >>> unexpected change you observe. >>> >>> 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 >>> >>> Based on the feedback we get, the default stack might be switched to the >>> RACK stack. >>> >>> Please let me know if you have any questions. >> >> I am running main-n266450-a592812327de with a GENERIC-NODEBUG kernel. >> >> # kldload tcp_rack >> kldload: an error occurred while loading module tcp_rack. Please check >> dmesg(8) for more details. >> >> In dmesg: >> KLD tcp_rack.ko: depends on tcphpts - not available or version mismatch >> linker_load_file: /boot/kernel/tcp_rack.ko - unsupported file type >> >> So you have to build a kernel with "options TCPHPTS" first? > > OK, I am now running GENERIC-NODEBUG + "options TCPHPTS". > > After setting "sysctl net.inet.tcp.functions_default=rack" git no > longer works: > > # sysctl net.inet.tcp.functions_default=rack > $ git pull > client_loop: send disconnect: Broken pipe > fatal: the remote end hung up upon initial contact > # sysctl net.inet.tcp.functions_default=freebsd > $ git pull > Already up to date. Interesting. It works on my development system: tuexen@head:~/freebsd-src % sysctl net.inet.tcp.functions_default net.inet.tcp.functions_default: rack tuexen@head:~/freebsd-src % git pull Already up to date. tuexen@head:~/freebsd-src % Could you provide a .pcapng file covering the `git pull` command? Best regards Michael > > -- > Herbert
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/src/commit/?id=3a338c534154164504005beb00a3c6feb03756cc >> >> As discussed on the bi-weekly transport call, it would be great if people >> could test the RACK stack for their workload. Please report any problems to >> the >> net@ mailing list or open an issue in the bug tracker and drop me a note via >> email. >> This includes regressions in CPU usage, regressions in performance or any >> other >> unexpected change you observe. >> >> 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 >> >> Based on the feedback we get, the default stack might be switched to the >> RACK stack. >> >> Please let me know if you have any questions. > > I am running main-n266450-a592812327de with a GENERIC-NODEBUG kernel. > > # kldload tcp_rack > kldload: an error occurred while loading module tcp_rack. Please check > dmesg(8) for more details. > > In dmesg: > KLD tcp_rack.ko: depends on tcphpts - not available or version mismatch > linker_load_file: /boot/kernel/tcp_rack.ko - unsupported file type > > So you have to build a kernel with "options TCPHPTS" first? Hi Herbert, yes this is correct. For whatever reason I was assuming the TCPHPTS is already enabled in all configs, but this is not correct. Will put up an review to do this tomorrow. Thanks for reporting. Best regards Michael > > -- > Herbert
Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule
On Thu, Nov 16, 2023 at 09:22:52PM +, Jamie Landeg-Jones wrote: > > Ok. I do not know what exactly is your point, but releases are never > > official until there is a PGP-signed email sent. The email is intended > > for the general public of consumers of official releases, not "yeah, > > but"s. > > Foe a recent new build, I just went to the ftp site to grab the latest rc, > only to see 14.0-release there, so I grabbed and installed that, many > hours before your original mail went out. > > No biggy, I generally track stable, but does this mean we can't rely > on the download sites without checking out the lists first? It's not > like I was plaing sneaky by doing "guess the URL" or anything like that. > No. It merely suggests the release is not officially official yet. Glen signature.asc Description: PGP signature
db> reset -> panic: acquiring blockable sleep lock with spinlock or critical section held ...
Hi, I seem to remember changes related to that a while ago but my cache is miss for the actual change. Are we suppoed to handle this case? It would be nice if "reset" would reset again the first time ... KDB: enter: Break to debugger [ thread pid 11 tid 15 ] Stopped at kdb_alt_break_internal+0x180: str xzr, [x19, #896] db> reset panic: acquiring blockable sleep lock with spinlock or critical section held (sleep mutex) eventhandler @ /usr/src/sys/kern/subr_eventhandler.c:269 cpuid = 2 time = 307 KDB: stack backtrace: db_trace_self() at db_trace_self db_trace_self_wrapper() at db_trace_self_wrapper+0x38 vpanic() at vpanic+0x1a0 panic() at panic+0x48 witness_checkorder() at witness_checkorder+0xb4c __mtx_lock_flags() at __mtx_lock_flags+0xac eventhandler_find_list() at eventhandler_find_list+0x44 kern_reboot() at kern_reboot+0x284 db_reset() at db_reset+0xd8 db_command() at db_command+0x2e4 db_command_loop() at db_command_loop+0x58 db_trap() at db_trap+0x100 kdb_trap() at kdb_trap+0x364 handle_el1h_sync() at handle_el1h_sync+0x18 --- exception, esr 0xf200 kdb_alt_break_internal() at kdb_alt_break_internal+0x180 kdb_alt_break() at kdb_alt_break+0x10 uart_intr_rxready() at uart_intr_rxready+0x8c uart_intr() at uart_intr+0x120 intr_event_handle() at intr_event_handle+0xf4 intr_isrc_dispatch() at intr_isrc_dispatch+0x78 arm_gic_v3_intr() at arm_gic_v3_intr+0x120 intr_irq_handler() at intr_irq_handler+0x88 handle_el1h_irq() at handle_el1h_irq+0x14 --- interrupt cpu_idle() at cpu_idle+0x78 sched_idletd() at sched_idletd+0x4a0 fork_exit() at fork_exit+0x78 fork_trampoline() at fork_trampoline+0x18 KDB: enter: panic [ thread pid 11 tid 15 ] Stopped at kdb_enter+0x48: str xzr, [x19, #896] db> reset Uptime: 5m7s INFO:PSCI Power Domain Map: -- Bjoern A. Zeeb r15:7
Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule
> Ok. I do not know what exactly is your point, but releases are never > official until there is a PGP-signed email sent. The email is intended > for the general public of consumers of official releases, not "yeah, > but"s. Foe a recent new build, I just went to the ftp site to grab the latest rc, only to see 14.0-release there, so I grabbed and installed that, many hours before your original mail went out. No biggy, I generally track stable, but does this mean we can't rely on the download sites without checking out the lists first? It's not like I was plaing sneaky by doing "guess the URL" or anything like that. Jamie
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: > > > > > Are you using a fresh 15 head or a specific network setup ? > > Because I'm not able to reproduce your problem on my system: > > $ uname -a > FreeBSD bigone 15.0-CURRENT FreeBSD 15.0-CURRENT #0 > main-n266452-070d9e3540e6: Thu Nov 16 17:53:15 CET 2023 > root@bigone:/usr/obj/usr/src/amd64.amd64/sys/TCPHPTS > amd64 > $ cat /usr/src/sys/amd64/conf/TCPHPTS > include GENERIC-NODEBUG > ident TCPHPTS > options TCPHPTS > $ sysctl net.inet.tcp.functions_default > net.inet.tcp.functions_default: rack > $ git clone -q g...@github.com:freebsd/freebsd-src.git && echo working > working > $ OK, (g)it works if I disable pf. Do you use pf? -- Herbert
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 reproduce your problem on my system: $ uname -a FreeBSD bigone 15.0-CURRENT FreeBSD 15.0-CURRENT #0 main-n266452-070d9e3540e6: Thu Nov 16 17:53:15 CET 2023 root@bigone:/usr/obj/usr/src/amd64.amd64/sys/TCPHPTS amd64 $ cat /usr/src/sys/amd64/conf/TCPHPTS include GENERIC-NODEBUG ident TCPHPTS options TCPHPTS $ sysctl net.inet.tcp.functions_default net.inet.tcp.functions_default: rack $ git clone -q g...@github.com:freebsd/freebsd-src.git && echo working working $
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-awaited change. Thank you. As discussed on the bi-weekly transport call, it would be great if people could test the RACK stack for their workload. Please report any problems to the net@ mailing list or open an issue in the bug tracker and drop me a note via email. This includes regressions in CPU usage, regressions in performance or any other unexpected change you observe. 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 Based on the feedback we get, the default stack might be switched to the RACK stack. Yes, please do it, at least for CURRENT. Last problem I have spotted with RACK was fixed in June: it was missing support TCP-MD5: https://cgit.freebsd.org/src/commit/?id=02b885b09d1e90574162a1442b9ede06cef2b13a We switched to RACK since upgrading to early stable/13 and genuinely appreciate this gift from Netflix. The performance improvement is invaluable, both in a lossy LAN and on a long-haul overseas TCP connection. Please let me know if you have any questions. Are any MFCs planned, especially to stable/14 ? Now, when stable/14 is almost in sync with main aka CURRENT it's an optimal time for such a MFC. When the change hits stable/14, it would be possible to test it extensively and have it fully functional in 14.1-RELEASE. Best regards -- Marek Zarychta
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.FreeBSD.org/src/commit/?id=3a338c534154164504005beb00a3c6feb03756cc > > > > As discussed on the bi-weekly transport call, it would be great if people > > could test the RACK stack for their workload. Please report any problems to > > the > > net@ mailing list or open an issue in the bug tracker and drop me a note > > via email. > > This includes regressions in CPU usage, regressions in performance or any > > other > > unexpected change you observe. > > > > 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 > > > > Based on the feedback we get, the default stack might be switched to the > > RACK stack. > > > > Please let me know if you have any questions. > > I am running main-n266450-a592812327de with a GENERIC-NODEBUG kernel. > > # kldload tcp_rack > kldload: an error occurred while loading module tcp_rack. Please check > dmesg(8) for more details. > > In dmesg: > KLD tcp_rack.ko: depends on tcphpts - not available or version mismatch > linker_load_file: /boot/kernel/tcp_rack.ko - unsupported file type > > So you have to build a kernel with "options TCPHPTS" first? OK, I am now running GENERIC-NODEBUG + "options TCPHPTS". After setting "sysctl net.inet.tcp.functions_default=rack" git no longer works: # sysctl net.inet.tcp.functions_default=rack $ git pull client_loop: send disconnect: Broken pipe fatal: the remote end hung up upon initial contact # sysctl net.inet.tcp.functions_default=freebsd $ git pull Already up to date. -- Herbert
Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule
On Thu, Nov 16, 2023 at 12:07:36AM -0500, Glen Barber wrote: > And if there is a reason to reissue a release, the update will reflect such. > > So to answer your latter question, yes. Unless it needs to be replaced. > > Glen > Sent from my phone. > Please excuse my brevity and/or typos. > > > On Nov 15, 2023, at 11:38 PM, The Doctor wrote: > > > > ???On Thu, Nov 16, 2023 at 12:30:30AM +, Glen Barber wrote: > >>> On Wed, Nov 15, 2023 at 08:39:39AM -0800, John Baldwin wrote: > >>> On 11/14/23 8:52 PM, Glen Barber wrote: > On Tue, Nov 14, 2023 at 08:10:23PM -0700, The Doctor wrote: > > On Wed, Nov 15, 2023 at 02:27:01AM +, Glen Barber wrote: > >> On Tue, Nov 14, 2023 at 05:15:48PM -0700, The Doctor wrote: > >>> On Tue, Nov 14, 2023 at 08:36:54PM +, Glen Barber wrote: > We are still waiting for a few (non-critical) things to complete > before > the announcement of 14.0-RELEASE will be ready. > > It should only be another day or so before these things complete. > > Thank you for your understanding. > > >>> > >>> I always just installed my copy. > >>> > >> > >> Ok. I do not know what exactly is your point, but releases are never > >> official until there is a PGP-signed email sent. The email is intended > >> for the general public of consumers of official releases, not "yeah, > >> but"s. > >> > > > > Howver if you do a freebsd-update upgrade, you can upgrade. > > > > Is that suppose to happen? > > > > That does not say that the freebsd-update bits will not change *until* > the official release announcement has been sent. > > In my past 15 years involved in the Project, I think we have been very > clear on that. > > A RELEASE IS NOT FINAL UNTIL THE PGP-SIGNED ANNOUNCEMENT IS SENT. > > I mean, c'mon, dude. > > We really, seriously, for all intents and purposes, cannot be any more > clear than that. > > So, yes, *IF* an update necessitates a new freebsd-update build, what > you are running is *NOT* official. > > For at least 15 years, we have all said the same entire thing. > >>> > >>> Yes, but, if at this point we had to rebuild, it would have to be 14.0.1 > >>> or something (which we have done a few times in the past). It would be > >>> too confusing otherwise once the bits are built and published (where > >>> published means "uploaded to our CDN"). It is the 14.0 release bits, > >>> the only question is if for some reason we had a dire emergency that > >>> meant we had to pull it at the last minute and publish different bits > >>> (under a different release name). > >>> > >>> Realistically, once the bits are available, we can't prevent people from > >>> using them, it's just at their own risk to do so until the project says > >>> "yes, we believe these are good". Granted, they are under the same risk > >>> if they are still running the last RC. The best way to minimize that > >>> risk going forward is to add more automation of testing/CI to go along > >>> with the process of building release bits so that the build artifacts > >>> from the release build run through CI and are only published if the CI > >>> is green as that would give us greater confidence of "we believe these > >>> are good" before they are uploaded for publishing. > >>> > >> > >> You are correct on all points. If there were a need to re-roll 14.0, it > >> would indeed necessitate a release/14.0.1 tag. Note, release/14.0.0 has > >> not yet been tagged, and I find it extremely unlikely that it will be > >> necessary to rebuild from a release/14.0.1 tag. > >> > >> I also agree we cannot prevent people from downloading the images, > >> installers, whatever before the announcement. That is the lovely race > >> condition with which we have to live at the moment. > >> > >> My email was intended to be informative. Period. > >> > >> There were no suggestions that 14.0-RELEASE was not yet final. And to > >> be fair, I had to personally deal with the fallout of a release "too > >> soon", notably 11.0-RELEASE, where I thought a critical issue had been > >> addressed, but I was wrong. > >> > >> My only point, in being overly open to the public on the delay, is that > >> we (the Release Engineering Team) are not yet ready to rubber-stamp this > >> as complete, as there are some outstanding items that are pending that > >> have not yet completed. > >> > >> The alternative would be to say nothing at all. > >> > >> Either way, it is a productivity, communication drain. It is > >> a lose-lose situation no matter how one looks at it given the above > >> context. We either get chastised for being "too open" into insights > >> delaying an official announcement, or for being "not open enough" when > >> there is silence from RE when a release does not meet its scheduled > >>
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 discussed on the bi-weekly transport call, it would be great if people > could test the RACK stack for their workload. Please report any problems to > the > net@ mailing list or open an issue in the bug tracker and drop me a note via > email. > This includes regressions in CPU usage, regressions in performance or any > other > unexpected change you observe. > > 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 > > Based on the feedback we get, the default stack might be switched to the > RACK stack. > > Please let me know if you have any questions. I am running main-n266450-a592812327de with a GENERIC-NODEBUG kernel. # kldload tcp_rack kldload: an error occurred while loading module tcp_rack. Please check dmesg(8) for more details. In dmesg: KLD tcp_rack.ko: depends on tcphpts - not available or version mismatch linker_load_file: /boot/kernel/tcp_rack.ko - unsupported file type So you have to build a kernel with "options TCPHPTS" first? -- Herbert
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 stack for their workload. Please report any problems to the net@ mailing list or open an issue in the bug tracker and drop me a note via email. This includes regressions in CPU usage, regressions in performance or any other unexpected change you observe. 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 Based on the feedback we get, the default stack might be switched to the RACK stack. Please let me know if you have any questions. Best regards Michael
something got wrong with 32bit ld between 1500002 and 1500003
Moin-moin! After upgrade to recent -current (153) I've got a ld error for 32bit an aarch64 machine:( ELF binary type "9" not known. eval: /libexec/ld-elf32.so.1: Exec format error Snapshot from 2023-10-13 was fine, no errors 15.0-CURRENT #0 main-6f38d2e7b0: Thu Nov 16 03:29:03 MSK 2023 is still broken -- Sincerely, Dima (flu...@freebsd.org, https://t.me/FluffyBSD) (desktop, kde, x11, office, ports-secteam)@FreeBSD team OpenPGP_signature.asc Description: OpenPGP digital signature
