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 > > >
