https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253888
--- Comment #10 from Jose Luis Duran ---
(In reply to Zhenlei Huang from comment #9)
Thank you!
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279850
--- Comment #6 from Lexi Winter ---
update!
this is caused by having IPv4 addresses in wireguard AllowedIPs while the
kernel does not have "options INET".
e.g. this will panic:
AllowedIPs = 0.0.0.0/0, ::/0
while this works fine:
Allowe
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253888
Zhenlei Huang changed:
What|Removed |Added
URL||https://reviews.freebsd.org
On Fri, Oct 11, 2024 at 3:56 PM John Nielsen wrote:
> Hi-
>
> I’m running a FreeBSD 14-STABLE host with a Chelstio T520. I have a bhyve
> VM (also running 14-STABLE) to which I have assigned a VF of the NIC. That
> is all working as expected; the host can pass traffic using the PF cxl0 and
> the
Hi-
I’m running a FreeBSD 14-STABLE host with a Chelstio T520. I have a bhyve VM
(also running 14-STABLE) to which I have assigned a VF of the NIC. That is all
working as expected; the host can pass traffic using the PF cxl0 and the guest
can pass traffic using the VF cxlv0. However the host ca
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=165059
Ed Maste changed:
What|Removed |Added
See Also||https://bugs.freebsd.org/bu
The Ultra Ethernet Consortium (UEC) has delayed release of the version
1.0 of specification from Q3 2024 to Q1 2025, but it looks like AMD is
ready to announce an actual network interface card for AI datacenters
that is ready to be deployed into Ultra Ethernet datacenters. The new
unit is the AMD P
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253888
--- Comment #8 from Jose Luis Duran ---
Created attachment 254168
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=254168&action=edit
if_vtnet: Drop the rxq lock around if_input()
I can confirm that the suggested fix clears the LO
> On 11. Oct 2024, at 14:55, Alan Somers wrote:
>
> On Fri, Oct 11, 2024 at 1:05 AM Michael Tuexen
> wrote:
>>
>>> On 11. Oct 2024, at 01:07, Alan Somers wrote:
>>>
>>> Can somebody please explain to me how the TCP measurement period
>>> works? When does h_ertt decide to take a new measureme
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281938
Michael Tuexen changed:
What|Removed |Added
CC||n...@freebsd.org
--
You are rece
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281938
Michael Tuexen changed:
What|Removed |Added
Assignee|n...@freebsd.org |tue...@freebsd.org
--
You are r
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281990
--- Comment #5 from Mark Johnston ---
(In reply to Konstantin Belousov from comment #4)
In general, our generic system calls do not require userspace to fill out
sa_len. Consumers should use getsockaddr(), which fills it in.
The kernel's
On Fri, Oct 11, 2024 at 1:05 AM Michael Tuexen
wrote:
>
> > On 11. Oct 2024, at 01:07, Alan Somers wrote:
> >
> > Can somebody please explain to me how the TCP measurement period
> > works? When does h_ertt decide to take a new measurement?
> >
> > Motivation:
> > I recently saw a long-distance
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281938
--- Comment #6 from Mark Johnston ---
(In reply to Michael Tuexen from comment #5)
Sure, I don't see any reason not to, if you're already looking at it. Thanks
in advance.
--
You are receiving this mail because:
You are the assignee for
Hi folks,
For the past three weeks on a Friday I have been writing some commentary
on what has been happening in the FreeBSD Network Stack. The commentary
is primarily based on main branch commits, but also includes some other
stuff from the community I gather via mailing lists, phab reviews and
b
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281990
--- Comment #4 from Konstantin Belousov ---
Besides ABI issue already pointed out.
I suspect that such change is very complex and not limited to recompilation and
dso versions bump. We need to ensure that len field is filled, and perhaps
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281938
--- Comment #5 from Michael Tuexen ---
(In reply to Michael Tuexen from comment #4)
Should I assign the report to myself?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281938
--- Comment #4 from Michael Tuexen ---
I can double check the usage of t_maxseg.
--
You are receiving this mail because:
You are the assignee for the bug.
On 8. Oct 2024, at 14:25, Mark Johnston wrote:
Maybe the firmware / hardware happens to been ( wrongly ) set to promisc mode
already ?
Maybe, or the driver is missing some initialization step.
That would be the likeliest case although I'm not sure why exiting
promisc mode doesn't turn it off
> On 11. Oct 2024, at 01:07, Alan Somers wrote:
>
> Can somebody please explain to me how the TCP measurement period
> works? When does h_ertt decide to take a new measurement?
>
> Motivation:
> I recently saw a long-distance connection that should've been capable
> of 80+ MBps suddenly drop to
20 matches
Mail list logo
