Re: NFS problems (was Re: how to diagnose persistent hangs in rpc_recv?)

Dan Stromberg (
Thu, 30 Jan 1997 16:33:22 -0800

I'm not sure what's different, but I have three linux machines set up
with amd over NFS (have considered strapping amd over smb in case it
helps performance).

It's slow, but it seems to work reliably.

One possibility: we use a patched amd binary. sources and/or binary
available upon request. The patches originally came from Richard

For what it's worth, we used to have some VERY mysterious amd problems
on SunOS 4.1.x. It's a weird program.

BTW, I use amd on linux in conjunction with a small python script that
converts a hierarchy of sun automounter maps (out of the NIS) to amd
maps. This allows amd on linux to behave very much like a commercial
unix equipped with a sun-derived automounter. Just slower.

Nelson Minar wrote:
> (John E. Davis) writes:
> > On 27 Jan 1997 20:09:05 -0500, Nelson Minar <> wrote:
> > >For the past few months my Linux box has had persistent, occasional
> > >problems of processes hanging in rpc_recv.
> > I am also having this problem with 2.0.28 and amd (amd920824upl90).
> > In addition to hanging in rpc_revc, I also have process that hang in
> > wait_on_page.
> I see this as well, but wasn't sure it was NFS related. Is that call
> used when mapping in a non-cached part of the text image of a program?
> I see this bug most often in netscape. The netscape binary is not NFS
> mounted, but god knows what other files it uses.
> > I do not recall having any of these problems in the early 1.3.X series
> > and I certainly did not have them with 1.2.13. Something is definitely
> > wrong with the 2.0.XX NFS implementation.
> That's my impression too. Can anyone at least confirm these problems?
> No suggestions on what to fix?
> (I saw Adam Neat's suggestion to check the configuration of the
> loopback device, as well as hosts.allow/deny. I think those are
> correct for me. In any event, problems in those configurations would
> presumably cause catastrophic failure, not the occasional outage we're
> seeing.)