[Bug 276674] [panic] [htcp] sysctl net.inet.tcp.cc.algorithm=htcp produces kernel panic
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276674 --- Comment #10 from Vladyslav V. Prodan --- (In reply to Richard Scheffenegger from comment #8) New link: https://support.org.ua/crashdump/vmcore.9.xz -- You are receiving this mail because: You are the assignee for the bug.
Re: Problem with Ethernet port BCM57416 NetXtreme-E Dual-Media 10G
> Hello, I have a problem with the installation of OPNSense 24.1. I am unable > to activate the Ethernet port BCM57416 NetXtreme-E Dual-Media 10G RDMA > Ethernet Controller. > > He doesn't recognize them, does anyone have a solution? > > The same problem with Realtek Semi conductor co. RTL8125 2.5GbE controller > Ethernet Controller. For this one you need to install the "port" of the re driver, pkg install realtek-re-kmod > Thanks > Marcos Lage -- Rod Grimes rgri...@freebsd.org
[Bug 276890] Getting fq_codel correct on inbound shaping
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276890 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|n...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276674] [panic] [htcp] sysctl net.inet.tcp.cc.algorithm=htcp produces kernel panic
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276674 --- Comment #9 from Richard Scheffenegger --- Looking at the code in question, a div/0 could happen when cwnd < t_maxseg. While it's not clear why and how that may happen, addressing the div/0 should be easy by max(maxseg, cwnd)/maxseg so that this term will be at least 1, and a div/0 is avoided. HTCP is not actively maintained, so tracking why cwnd could end up smaller than maxseg would be more involved (running with active BBLog and extracting the relevant data once another crash happens; running BBlog continously will probably cost some performance. diff --git a/sys/netinet/cc/cc_htcp.c b/sys/netinet/cc/cc_htcp.c index d31720d0099f..a858558d7aa5 100644 --- a/sys/netinet/cc/cc_htcp.c +++ b/sys/netinet/cc/cc_htcp.c @@ -229,9 +229,9 @@ htcp_ack_received(struct cc_var *ccv, uint16_t type) * per RTT. */ CCV(ccv, snd_cwnd) += (((htcp_data->alpha << - HTCP_SHIFT) / (CCV(ccv, snd_cwnd) / - CCV(ccv, t_maxseg))) * CCV(ccv, t_maxseg)) - >> HTCP_SHIFT; + HTCP_SHIFT) / (max(CCV(ccv, t_maxseg), + CCV(ccv, snd_cwnd)) / CCV(ccv, t_maxseg))) * + CCV(ccv, t_maxseg)) >> HTCP_SHIFT; } } } -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276674] [panic] [htcp] sysctl net.inet.tcp.cc.algorithm=htcp produces kernel panic
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276674 --- Comment #8 from Richard Scheffenegger --- can not find the vmcore.9.xz upload. Also, that hoster appears to require html5 and doesn't serve plain http objects without much fanfare... (curl/wget are incompatible). -- You are receiving this mail because: You are the assignee for the bug.
[Bug 258732] [tcp] TCP_MAXSEG does not work
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258732 Arthur Kiyanovski changed: What|Removed |Added CC||akiy...@amazon.com --- Comment #12 from Arthur Kiyanovski --- (In reply to Michael Tuexen from comment #5) Just adding a usage example: A popular way to sanity test network performance is the iperf tool. With this tool, the way to control the size of packets sent is with the -M parameter, which according to the documentation: -M, --mss n set TCP maximum segment size using TCP_MAXSEG For example, to get a quick look at pps, what one may like to do is to set the -M parameter to some small number and run the BW test. This gives a good feel for pps. There may be other ways to achieve this, but this is the popular quick and dirty one I know. -- You are receiving this mail because: You are the assignee for the bug.
