On Thu, Oct 08, 1998 at 09:37:43PM +1000, Robert Elz wrote:
>     Date:        Thu, 8 Oct 1998 13:02:09 +0200 (CEST)
>     From:        Urban Boquist <boquist@cs.chalmers.se>
>     Message-ID:  <13852.39857.890982.553568@dogbert.cs.chalmers.se>
> 
>   | This may be related to PR bin/6037.
> 
> I doubt it (or rather, if the two are related, it is more likely that the
> amd problem is a symptom of a basic kernel NFS problem.)
> 
> I see the same, and I don't use amd (on NetBSD) at all, just NFS mounts
> from fstab.

  FWIW, the mount that had problems reading directories was via
amd, while the one that took long to propogate mode changes was
a direct fstab mount.  And if I manually mount the amd-mount on
/mnt, the readdir things all work fine.  So it appears that
either amd is invoking mount in a different way than a
command-line mount which ends up exposing the readdir bug only
for amd-mounts, or maybe there are two bugs (amd/readdir and
weird/slow timeouts)!?!

  My last working kernel was built on Aug 10, and we sup nightly
at 3am.  Does anyone have a later known-working time (or
an earlier broken kernel?)  Between all of us experiencing
problems, we ought to be able to pinpoint the time of breakage to
within a week, hopefully, at which point groveling through CVS or
building test kernels would be pretty simple.  A GENERIC kernel
ought to work on my system, too, so I could test kernels built
by others in this time frame even if they aren't having problems.
Unless the recent signal changes make old kernels incompatible
with new userland....  in which case someone with older userland
would be a better person to do the testing.

  Brian
-- 
"...just take everything you know and shove it up by 12."
  Mark Krentel, COMP 280