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 >
