Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: nfs got worse

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?

Home | Main Index | Thread Index | Old Index