Re: nfs got worse

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

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
>