https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=143666
Michael Tuexen changed:
What|Removed |Added
Status|Open|Closed
Resolution|---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=143666
Mark Linimon changed:
What|Removed |Added
Assignee|b...@freebsd.org|n...@freebsd.org
--
You are receiv
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283450
--- Comment #4 from takahiro.kuros...@gmail.com ---
(In reply to takahiro.kurosawa from comment #3)
I'm sorry, the patch does not work for 14.x branches. Only effective for 13.x
branches.
--
You are receiving this mail because:
You are the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283450
takahiro.kuros...@gmail.com changed:
What|Removed |Added
CC||takahiro.kuros...@gmai
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=117733
--- Comment #7 from Chris Hutchinson ---
(In reply to Chris Hutchinson from comment #6)
Sorry. I see the diff(s) no longer exist. The Wayback
machine has no copies either. What a pity, and kind
of insulting too to the author. :`(
--
You a
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=117733
Chris Hutchinson changed:
What|Removed |Added
CC||portmas...@bsdforge.com
--- Com
] [request] allow to |[request] allow to tee(1)
|tee(1) to sockets, |to sockets, descriptors
|descriptors |
CC||Alexander88207@protonmail.c
||om
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283450
DYM changed:
What|Removed |Added
Summary|ARP problem |ARP problem. Request
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202038
Damjan Jovanovic changed:
What|Removed |Added
CC||damjan@gmail.com
--- Commen
I'll remind everybody that ifconfig has had IFCONFIG_FORMAT since
```
commit 7c2aa744374aa3449ad81f60852e74ad73d823e6
Author: Allan Jude
Date: Tue May 31 17:30:08 2016 +
ifconfig(8) now supports some output formatting options
```
so we've already 7 years into this process. This is nothi
Jessica Clarke:
> On 4 May 2024, at 16:34, Lexi Winter wrote:
> Do we need to care about supporting (/ do we currently support)
> historical non-contiguous netmasks? At a glance the CIDR code doesn’t
> handle that and will stop at the first 0, so changing to that by
> default would break such setu
On 4 May 2024, at 16:34, Lexi Winter wrote:
> hi,
>
> i've just submitted this PR:
>
> https://github.com/freebsd/freebsd-src/pull/1216
>
> which contains this commit:
>
> commit 57d273c90ee1c17446236aba25ed0bd291c4f126 (HEAD -> lf/main,
> hemlock/lf/main)
> Author: Lexi Winter
> Date: Sa
hi,
i've just submitted this PR:
https://github.com/freebsd/freebsd-src/pull/1216
which contains this commit:
commit 57d273c90ee1c17446236aba25ed0bd291c4f126 (HEAD -> lf/main,
hemlock/lf/main)
Author: Lexi Winter
Date: Sat May 4 16:11:21 2024 +0100
ifconfig(8): change default IP addres
hello,
if someone had a chance to review this change to netpfil/pf:
https://github.com/freebsd/freebsd-src/pull/1157
i would appreciate that.
thanks, lexi.
signature.asc
Description: PGP signature
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 equ
or the current thread.
> >>>>>>
> >>>>>> Is it enough?
> >>>>>>>
> >>>>>>> Drew
> >>>>>>
> >>>>>>>
> >>>>>>> On Mon, Mar 18, 2024, at 2:33 P
>>
>>>>>>> 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 wrote:
>>>>>>>>>
t; 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
> >>>&
t;>>>>>> On 18. Mar 2024, at 12:42, Nuno Teixeira
>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Hello all!
>>>>>>>>>>
>>>>>>>>>> It works just fine!
>>&
; > > > > >> ---
> > > > > > > >> net.inet.tcp.functions_available:
> > > > > > > >> Stack D
> > > > AliasPCB count
> > > > > > > >> f
> > > > >> ---
> > > > > > > >> net.inet.tcp.functions_available:
> > > > > > > >> Stack D
> > > > AliasPCB count
> > > > > > > >> f
PCB count
> > > > > > >> freebsd freebsd 0
> > > > > > >> rack *
> > > rack 38
> > > > > > >> ---
> > > > >
Hi everyone,
Don't know where I should ask this, so I'll just try with this mailing
list as a first attempt. I have implemented an IFLIB based network
device driver for a Xilinx FPGA card with a custom firmware,
everything seems to work fine except for the number of RX/TX queues
selected by IFLIB
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!
> > > > >
> > > > > @gallat
n 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
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 regression.
> >
> > Ideally, tcphpts could enable this automaticall
ut recompiling kernel.
> > Thanks for testing!
> >
> > @gallatin: can you come up with a patch that is acceptable for Netflix
> > and allows to mitigate the performance regression.
>
> Ideally, tcphpts could enable this automatically when it starts to be
> used (enough?),
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
> 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
> f
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
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
> 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
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
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
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
> 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
This
> 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
> 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 tc
> > 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]
> 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"
> 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
> 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 t
> > 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, loader.con
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
> 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
(...)
> 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
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
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 (
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,
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.
> > ex
> 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 tooked
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-NODEBUG
> 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
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
> 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 r
> 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
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)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277435
--- Comment #14 from Nikolay Borodin ---
(In reply to Kyle Evans from comment #11)
If I set net.link.tap.user_open to 1 and try to open tap device (e.g.
"/dev/tap"), open returns -1, but the tapN interface still exists. It also
creates devi
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277435
--- Comment #13 from Nikolay Borodin ---
(In reply to Kyle Evans from comment #11)
After applying these changes, everything works as it should.
https://reviews.freebsd.org/D44199
--
You are receiving this mail because:
You are the assign
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277435
--- Comment #12 from Nikolay Borodin ---
(In reply to Kyle Evans from comment #11)
> Is it doing some fork or fork/exec? Any fd passing or anything funky?
I doubt it.
> Interface renaming?
Not yet. :)
Here's the code (minus TAPSTRANSIEN
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277435
--- Comment #11 from Kyle Evans ---
(In reply to Nikolay Borodin from comment #10)
That's fascinating. Can you tell us a little more about your application? Is it
doing some fork or fork/exec? Any fd passing or anything funky? Interface
re
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277435
--- Comment #10 from Nikolay Borodin ---
(In reply to Kyle Evans from comment #8)
(In reply to Nikolay Borodin from comment #9)
To clarify, it's not the ioctl call that hangs, it's the code in the kernel.
--
You are receiving this mail be
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277435
--- Comment #9 from Nikolay Borodin ---
(In reply to Kyle Evans from comment #8)
After this option is set, the system hangs when the application is closed.
i = 1;
if (ioctl(fd, TAPSTRANSIENT, &i) < 0) {
printf("error: ioctl(TAPSTRANSI
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277435
--- Comment #8 from Kyle Evans ---
Something like this should do the trick: https://reviews.freebsd.org/D44200
(tun(4)/tap(4): allow devices to be configured as transient)
--
You are receiving this mail because:
You are the assignee for t
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277435
--- Comment #7 from Kyle Evans ---
(In reply to Nikolay Borodin from comment #6)
Right, but the automatic destroy functionality wouldn't work until the process
closes anyways if you leaked an fd to the tap device somewhere, which may or
ma
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277435
--- Comment #6 from Nikolay Borodin ---
(In reply to Kyle Evans from comment #5)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242841#c0(In reply to Kyle
Evans from comment #5)
I understand, in any case it doesn't apply to the automati
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277435
--- Comment #5 from Kyle Evans ---
(In reply to Nikolay Borodin from comment #4)
That is a bug, then, unless you have a dangling reference that you didn't
expect.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277435
--- Comment #4 from Nikolay Borodin ---
(In reply to Kyle Evans from comment #3)
> though you can destroy it, you just have to close it first
You can't. If you try to do this via SIOCIFDESTROY inside an application which
uses the descripto
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277435
Kyle Evans changed:
What|Removed |Added
CC||kev...@freebsd.org
--- Comment #3 fro
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277435
--- Comment #2 from Nikolay Borodin ---
(In reply to Alan Somers from comment #1)
> On the last close of the data device, the interface is brought down (as if
> with “ifconfig tapN down”)
It's completely different. What I am suggesting re
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277435
Alan Somers changed:
What|Removed |Added
CC||asom...@freebsd.org
--- Comment #1 f
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277435
Mark Linimon changed:
What|Removed |Added
Assignee|standa...@freebsd.org |n...@freebsd.org
--
You are receiv
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
> 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
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255597
Mark Linimon changed:
What|Removed |Added
Assignee|n...@freebsd.org |melif...@freebsd.org
> 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,
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
> 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
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:
> > > >
> > > >
> 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
> 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:
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
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
Summary|Automatically add carp(4) |request: automatically add
|interfaces to interface |carp(4) interfaces to
|group "carp"|interface group "carp"
--
You are receiving this mail because:
You are the assignee for the bug.
> 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
> 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
7946 ack-only packets (2 delayed)
1 control packet
999 packets received
860 acks (for 41681 bytes)
910 packets (118790 bytes) received in-sequence
12 completely duplicate packets (17136 bytes)
1 connection request
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
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,
> 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
> 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
>>>
> 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
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:
> >
> >
>
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
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
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
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
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255597
--- Comment #2 from Alexander V. Chernikov ---
route(8) support landed in
https://cgit.freebsd.org/src/commit/?id=ab4d1b73cbf8980dbe05cde7d822010042db8344
.
Will merge to stable/13 in 2 weeks
--
You are receiving this mail because:
You a
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255597
Alexander V. Chernikov changed:
What|Removed |Added
Assignee|b...@freebsd.org|n...@freebsd.org
--
You
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=117733
Graham Perrin changed:
What|Removed |Added
Keywords||patch
--- Comment #5 from Graham P
1 - 100 of 590 matches
Mail list logo
