>> I've got 3 NetBSD boxes in my office at work: a SPARCstation 20/71 running
>> NetBSD 1.2.1, a Mac IIci running NetBSD 1.2, and a Pentium 133 server box
>> running NetBSD 1.2.
>> 
>> The SPARCstation and the Mac are doing fine, but the PC has started to get
>> a problem with processes getting wedged in "D" state that do NFS accesses.
> 
> There were a few bugs that could cause this sort of thing to happen.  They
> have been fixed in -current, but were not in 1.2.1.  Unfortunately, the
> -current NFS code will not just drop into 1.2.1 and compile, because
> of other changes (lookup and mbuf changes, for example).

Hi Frank,
	I looked into it a bit more and discovered that the main progenitor
of the NFS hangs was running "calendar -a".  So I've disabled that on the
PC in /etc/daily as a (hopeful) workaround.
	I'm still troubled a bit by this behavior though, for several reasons.
One being that I recall "calendar -a" working on the SPARCstation before I
ended up commenting it out there as well.  My /etc/daily output would show
oodles and oodles of NFS mounts in the "df" output from the "calendar -a" run,
but it was working nonetheless.  Also, the "calendar -a" on the 1.2 PC seemed
to have always stopped at the 2nd entry in the NIS password map - i.e., the
"calendar" process was running as user "wjm" at the time of the hang, and a
"ypcat passwd | egrep -n wjm" revealed it to be only the 2nd record in the
NIS map.  So it seems "calendar" doesn't get very far before causing the hangs.
	Well, like I said, I'm going to disable "calendar" as a workaround for
the moment and see how that affects things.  Nonetheless, this sort of thing
would seem to me to be a prime candidate for some sort of 1.2.2 patch, since
I can't be the only person using NetBSD with an NIS passwd map and possibly
extensive NFS mounts.  (Although I'd imagine most people in my situation would
have wisely disabled "calendar -a" by now, especially if the users in the
NIS passwd map didn't use the NetBSD machines much!)

Thanks,

	- Greg