Date: Tue, 6 Jul 2021 22:49:09 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: Adam Stylinski <kungfujesus06@gmail.com> Cc: "rscheff@freebsd.org" <rscheff@freebsd.org>, "freebsd-fs@freebsd.org" <freebsd-fs@freebsd.org> Subject: Re: Issues with NFS RPC Message-ID: <YQXPR0101MB09683F9171AD70C36F87289EDD1B9@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <CAJwHY9XTHwUCki_24U0=CcBV9uExDGkrFpMVDrU6P0_skeE41A@mail.gmail.com> References: <CAJwHY9W3x825usjnbhoC7whvNCwS_Sfc2Quf2ayuqvivavD8nQ@mail.gmail.com> <YQXPR0101MB0968EE16EE78467A70A0F47BDD1B9@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM> <CAJwHY9WgXMUffvYfffBY89TrmezbCCMqmJeBh73hm4nTEkJnwg@mail.gmail.com> <YQXPR0101MB096878CF69F7868BCFF7284FDD1B9@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>,<CAJwHY9XTHwUCki_24U0=CcBV9uExDGkrFpMVDrU6P0_skeE41A@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Adam Stylinski wrote:=0A= >Well, I put in a plea in that PR for something to trickle into RELENG, but= , if not possible, does that patch you posted >in there for -STABLE apply c= leanly to the RELENG branch? It looks like it calls some helper functions = but from what I >can tell they are fully present in the 13.0 releng branch = (CC'ing the list and rscheff on this as well).=0A= Just to clarify...the patch in the PR reverts r367492 (the commit that caus= ed the breakage). It should=0A= apply cleanly to a releng13.0 kernel.=0A= =0A= It is not the patch that fixes the problem that is in stable/13. That one i= s on phabricator in D29690. I do=0A= not know if this patch can be safely applied to a releng13.0 kernel. Presum= ably rscheff@ will know if it does.=0A= =0A= >I used gmail for all of this correspondence so hopefully the mutt or other= mail users don't lose their mind with all >the top posting. Sorry in adva= nce for the poor ML etiquette.=0A= Personally, I don't care and, personally, sometimes it makes sense, if the = reply is not addressing individual=0A= comments within a post. Not to mention, Outlook is what I use and top posti= ng is certainly easy (and expected)=0A= by it.=0A= =0A= You should do "netstat -a" on the server the next time you see the hang.=0A= The connection will be in ESTABLISHED state with the Recv-Q value non-zero = and increasing=0A= over time, if this is the cause of your problem.=0A= =0A= rick=0A= =0A= =0A= On Tue, Jul 6, 2021 at 10:59 AM Rick Macklem <rmacklem@uoguelph.ca<mailto:r= macklem@uoguelph.ca>> wrote:=0A= Adam Stylinski wrote:=0A= >Yes, I'm using 13.0-RELEASE, with the latest security updates from freebsd= -update. If this is that issue, I'm glad it's >known and fixed, but I'd re= ally hoped it'd get backported to -RELEASE :(.=0A= At this time, you need to build a kernel from patched sources. You can eith= er use stable/13 kernel=0A= sources (which, of course, pulls in other changes) or apply the patch that = reverts r367492 that is=0A= an attachment on the PR to releng13.0 kernel sources.=0A= =0A= You could ask rscheff@freebsd.org<mailto:rscheff@freebsd.org> (who is the a= uthor of r367492 and the patch that is in stable/13=0A= and is believed to have fixed this problem if he has considered asking re@f= reebsd.org<mailto:re@freebsd.org> w.r.t. doing=0A= the patch as an errata for releng13.0.=0A= =0A= >Other info I forgot to include: the firmware on both adapters is the same = and the latest for the ConnectX-3 series. >The ring size, channels, offloa= d, and all other settings are the driver defaults. This issue is not limit= ed to just this >workload, it occurs on other files as well.=0A= If you look at r367492, it changed the timing and lock semantics related to= TCP socket upcalls.=0A= As such, it probably doesn't matter what network interface, etc, that you a= re using.=0A= --> Although I would not recommend it, you could use NFSv3 over UDP, since = this is a TCP specific issue.=0A= =0A= rick=0A= =0A=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YQXPR0101MB09683F9171AD70C36F87289EDD1B9>