From owner-freebsd-hackers  Mon Apr 14 12:20:55 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id MAA07944
          for hackers-outgoing; Mon, 14 Apr 1997 12:20:55 -0700 (PDT)
Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2])
          by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA07939
          for <freebsd-hackers@freefall.FreeBSD.org>; Mon, 14 Apr 1997 12:20:49 -0700 (PDT)
Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02)
	id AA04000; Mon, 14 Apr 1997 15:20:06 -0400
Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Mon, 14 Apr 1997 15:20 EDT
Received: from lakes.water.net (lakes [10.0.0.3]) by ponds.water.net (8.8.3/8.7.3) with ESMTP id OAA21223 for <freebsd-hackers@freefall.cdrom.com>; Mon, 14 Apr 1997 14:51:27 -0400 (EDT)
Received: (from rivers@localhost) by lakes.water.net (8.8.3/8.6.9) id OAA25971 for freebsd-hackers@freefall.cdrom.com; Mon, 14 Apr 1997 14:57:56 -0400 (EDT)
Date: Mon, 14 Apr 1997 14:57:56 -0400 (EDT)
From: Thomas David Rivers <ponds!rivers@dg-rtp.dg.com>
Message-Id: <199704141857.OAA25971@lakes.water.net>
To: ponds!freefall.cdrom.com!freebsd-hackers
Subject: update on 2.2.1 NFS problems... (my debugging...)
Content-Type: text
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk


I've been putting printf()s in my kernel to try and determine
where my NFS is locking up.

Well - it has wound it's way all the way down to soreceive().

Apparently, it's going like this:

  1) nfs_readdirrpc() calls nfsm_request() [toward the top of nfs_readdirrpc().

  2) nfs_request calls nfs_send() to send the request, and then
     calls nfs_reply to wait on the reply.

  3) nfs_reply calls nfs_receive() which, since this is simply
     a "normal" NFS (not TCP), jumps down to do an soreceive().

  4) soreceive() locks up.

This, of course, explains why the "ls -l" process that causes
this is handing in "sbwait"...

[On another note, eventually, of course, the kernel times out this request 
and you get "nfs server XXX:/filesystem: not responding" - but that
time out seems to take a *lot* longer than the -t option would indicate...]

This would seem to be a rather generic socket issue - has anyone
got any ideas?  

	- Dave Rivers -