https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254303
--- Comment #6 from Zhenlei Huang ---
CC Alexander V. Chernikov
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.f
We are using the Intel Ethernet Network Adapter X722.
Jason Breitman
On Mar 17, 2021, at 6:48 PM, Peter Eriksson wrote:
CLOSE_WAIT on the server side usually indicates that the kernel has sent the
ACK to the clients FIN (start of a shutdown) packet but hasn’t sent it’s own
FIN packet - somet
CLOSE_WAIT on the server side usually indicates that the kernel has sent the
ACK to the clients FIN (start of a shutdown) packet but hasn’t sent it’s own
FIN packet - something that usually happens when the server has read all data
queued up from the client and taken what actions it need to shut
Thank you for the responses.
The NFS Client does properly negotiate down to 128K for the rsize and wsize.
The client port should be changing as we are using the noresvport option.
On the NFS Client
cat /proc/mounts
nfs-server.domain.com:/data /mnt/data nfs4
rw,relatime,vers=4.1,rsize=131072,wsiz
Alan Somers wrote:
[stuff snipped]
>Is the 128K limit related to MAXPHYS? If so, it should be greater in 13.0.
For the client, yes. For the server, no.
For the server, it is just a compile time constant NFS_SRVMAXIO.
It's mainly related to the fact that I haven't gotten around to testing larger
s
On Wed, Mar 17, 2021 at 3:37 PM Rick Macklem wrote:
> Jason Breitman wrote:
> >Please review the details below and let me know if there is a setting
> that I should >apply to my FreeBSD NFS Server or if there is a bug fix that
> I can apply to resolve my >issue.
> >I shared this information with
Jason Breitman wrote:
>Please review the details below and let me know if there is a setting that I
>should >apply to my FreeBSD NFS Server or if there is a bug fix that I can
>apply to resolve my >issue.
>I shared this information with the linux-nfs mailing list and they believe the
>issue is >
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254244
--- Comment #28 from commit-h...@freebsd.org ---
A commit in branch stable/13 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=703419774f86525a2441d615733993a6fddcd047
commit 703419774f86525a2441d615733993a6fddcd047
Author
Please review the details below and let me know if there is a setting that I
should apply to my FreeBSD NFS Server or if there is a bug fix that I can apply
to resolve my issue.
I shared this information with the linux-nfs mailing list and they believe the
issue is on the server side.
Issue
NFS
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254244
--- Comment #27 from commit-h...@freebsd.org ---
A commit in branch main references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=e9f029831fa5747ae1b405f5716c52cb4ebf1e04
commit e9f029831fa5747ae1b405f5716c52cb4ebf1e04
Author:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254244
--- Comment #26 from Richard Scheffenegger ---
Not so sure if this really is due to Rescue Retransmissions;
The linked dump (
http://freebsd.1045724.x6.nabble.com/13-0-CURRENT-r368448-panic-td6443146.html
) is from Jan 20, but SACK rescue
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254244
--- Comment #25 from Marek Zarychta ---
(In reply to Richard Scheffenegger from comment #24)
Hans, Richard, thank you for the deep insight into this.
Yes, net.inet.tcp.rfc6675_pipe=1 is set on this machine probably since early
FreeBSD 11.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=250922
Stéphane D'Alu changed:
What|Removed |Added
Resolution|--- |Overcome By Events
St
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254244
Richard Scheffenegger changed:
What|Removed |Added
CC||rsch...@freebsd.org
--- Co
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254309
Richard Scheffenegger changed:
What|Removed |Added
Assignee|n...@freebsd.org |rsch...@freebsd.org
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254309
Richard Scheffenegger changed:
What|Removed |Added
CC||rsch...@freebsd.org
--- Co
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254333
--- Comment #1 from Michael Tuexen ---
What is the output of procstat -kk PID, where PID is the PID of a hanging
sysctl process?
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254309
Hans Petter Selasky changed:
What|Removed |Added
CC||hsela...@freebsd.org
--- Com
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254303
--- Comment #5 from Aleks ---
(In reply to Marek Zarychta from comment #4)
So, I took kernel src from
https://download.freebsd.org/ftp/releases/amd64/13.0-RC2/src.txz
Build with "options FIB_ALGO"
FreeBSD 13.0-RC2 FreeBSD 13.0-RC2 #0: W
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254309
--- Comment #8 from rozhuk...@gmail.com ---
I try kernel without:
options RATELIMIT #o TX rate limiting support
options TCP_OFFLOAD #o TCP offload
options TCP_BLACKBOX#o Enhanced
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254303
--- Comment #4 from Marek Zarychta ---
(In reply to Aleks from comment #3)
If you can build a custom kernel with "options FIB_ALGO", install it and after
reboot load the module dpdk_lpm4 (and dpdk_lpm6 if appropriate), then please
give it
21 matches
Mail list logo
