Re: nfs got worse

[Thomas Klausner <tk%giga.or.at@localhost>]

I've had no problems with a kernel from
D2014.07.24.14.00.00
but did see the problem quickly with one from
D2014.07.24.16.06.00

The only changes between these are:
"cvs rdiff -u -r1.33 -r1.34 src/sys/arch/luna68k/dev/lunafb.c"

Tyler's "split PRU_BIND and PRU_LISTEN function out of pr_generic()
usrreq" and "cleanup after last commit" commits. So I'm pretty sure
now there must be something wrong here, though I don't see it.
 Thomas



On Fri, Aug 01, 2014 at 12:28:28AM +0200, Thomas Klausner wrote:
> Ok, I was told I'm off due to localtime:
> 
> /Makefile/1.79/Sun Mar  3 15:52:53 2013//D2014.07.23.22.00.00
> 
> However, there were no interesting commits between 23. 22:00 and 24.
> 00:00 and the ones cited below are all before 24. 22:00.
> 
>  Thomas
> 
> On Thu, Jul 31, 2014 at 11:03:01PM +0200, Thomas Klausner wrote:
> > On Tue, Jul 29, 2014 at 11:09:34PM +0200, Thomas Klausner wrote:
> > > I've recently upgraded to 6.99.49 on machine that's NFS mounting from
> > > a Synology NAS via amd.
> > > 
> > > In the last days, files on the NFS shares stopped being accessible
> > > multiple times, hanging accesses to the whole share.
> > > 
> > > I've been able to trigger it like this at least twice:
> > > 
> > > run mplayer on a file on the server
> > > pause
> > > come back later, unpause
> > > 
> > > mplayer currently hangs in
> > >  2933 wiz       85    0   191M   34M nfscn2/8   0:13  0.00%  0.00% mplayer
> > > 
> > > I also saw processes hung in "nfsrcv/5" when accessing the directory
> > > on which mplayer was hanging.
> > > 
> > > Since I saw this the first time, I've made the nfs mounts 'tcp' mounts
> > > (I was using the default before) and even got rid of amd and mounted
> > > them directly with /etc/fstab. Neither of these helped.
> > > 
> > > I currently assume that it's not the server's fault because the server
> > > is right now still accessible via HTTPS, and rebooting NetBSD usually
> > > made the problem disappear -- after a reboot I can access the files
> > > again.
> > > 
> > > I'm not sure where to look for more details.
> > > 
> > > I haven't seen this before at all, so I suspect some recent changes
> > > (after Jun 20) in the NFS or network code. Does anyone have ideas?
> > 
> > I've played:
> > cvs update -D 20140XXX
> > build kernel
> > boot, try to get hang
> > 
> > I got this far:
> > "cvs up -D 20140724" kernel does not show the symptoms
> > "cvs up -D 20140725" kernel *does* show the symptoms
> > 
> > As I understand it, 20140724 means 20140724 00:00.
> > 
> > I browsed the cvs commits from that day. Here are a the IMHO most
> > interesting commits:
> > 
> > Modified Files:
> >         src/sys/arch/amd64/include: vmparam.h
> >         src/sys/arch/i386/include: vmparam.h
> >         src/sys/arch/x86/x86: x86_machdep.c
> > 
> > Log Message:
> > Add a FIRST1G page freelist to x86, for old graphics devices.
> > 
> > 
> > Modified Files:
> >         src/sys/dev/bluetooth: bthidev.c btmagic.c btsco.c
> >         src/sys/kern: uipc_socket.c uipc_usrreq.c
> >         src/sys/net: link_proto.c raw_usrreq.c rtsock.c
> >         src/sys/netatalk: ddp_usrreq.c
> >         src/sys/netbt: hci_socket.c l2cap.h l2cap_socket.c l2cap_upper.c
> >             rfcomm.h rfcomm_session.c rfcomm_socket.c rfcomm_upper.c sco.h
> >             sco_socket.c sco_upper.c
> >         src/sys/netinet: in_pcb.c in_pcb.h raw_ip.c tcp_usrreq.c 
> > udp_usrreq.c
> >         src/sys/netinet6: in6_pcb.c in6_pcb.h raw_ip6.c udp6_usrreq.c
> >         src/sys/netipsec: keysock.c
> >         src/sys/netmpls: mpls_proto.c
> >         src/sys/netnatm: natm.c
> >         src/sys/rump/net/lib/libsockin: sockin.c
> >         src/sys/sys: param.h protosw.h un.h
> > 
> > Log Message:
> > split PRU_BIND and PRU_LISTEN function out of pr_generic() usrreq
> > switches and put into separate functions
> > ...
> > 
> > 
> > Modified Files:
> >         src/sys/netinet: tcp_usrreq.c
> > 
> > Log Message:
> > cleanup after last commit
> > 
> > - add KASSERT(req != PRU_BIND) and KASSERT(req != PRU_LISTEN) inside
> >   tcp_usrreq() as these reqs should no longer reach here.
> > - remove (now unreachable) PRU_LISTEN case in switch.
> > 
> > 
> > Other than that, there were DRM and genfb changes, but I don't think
> > they should affect that.
> > 
> > Any ideas if one of these commits could cause my NFS hang issues?
> >  Thomas
> > 
>