Bug 3102

I have a similar situation with 6.0. I have 2 machines, one is small
and old and ue to a small disk does not have a full server
installation. The other is less old and has the disk space, so I did a
full server installation. Both machines have identical network cards,
my old trusty Netgear FA310TX.

I want to the larger, newer machine (say host1) to serve to the other
(host2). host2 can mount properly and even ls the newly mounted
directory ok. But that is about all. If I try to more a file or copy a
file from the mounted directory, host 2 hangs. I can unhang it by
killing the nfs daemon.

I thought the problem might be w/ knfsd. On both hosts I removed the
knfsd rpm and installed nfs-server-2.2beta37-1 downloaded from
ftp.cdrom.com (redhat mirror). Unfortunately, the behaviour is the
same.

Am I to believe that this is actually a kernel problem?

Red Hat 6.0 uses kernel NFS to improve performance. If you wish
to use your own kernel and the user space nfs-server, you will
have to (at the minimum) recompile and install the nfs-server
package.

2nd problem:
When your "machine hangs", what does netstat -a show? How abou ps axl?
   Is the machine ping-able while hung?
      After killing nfsd?

Can you copy a 0 byte file? A 10 byte file? A 512 byte file? etc ...

Have you tried replacing your "trusty FA310TX" card to see if it
is not so trusty with a 2.2.x kernel? NFS is notorious for execising
cards to the max and the kernel nfsd is better able to exercise the
card ...

Please reopen this bug if you have additional information.

------- Additional Comments From   06/08/99 12:15 -------
I enclose the help text from a 2.2.7 kernel:

  CONFIG_NFSD:

  If you want your Linux box to act as a NFS *server*, so that other
  computers on your local network which support NFS can access certain
  directories on your box transparently, you have two options: you can
  use the self-contained user space program nfsd, in which case you
  should say N here, or you can say Y and use this new experimental
  kernel based NFS server. The advantage of the kernel based solution
  is that it is faster; it might not be completely stable yet, though.
  You will need the support software from the linux-nfs package
  available at ftp://ftp.mathematik.th-darmstadt.de/pub/linux/okir/.
  Please read the NFS-HOWTO, available via FTP (user: anonymous) from
  ftp://metalab.unc.edu:/pub/Linux/docs/HOWTO.

  The NFS server is also available as a module ( = code which can be
  inserted in and removed from the running kernel whenever you want).
  The module is called nfsd.o. If you want to compile it as a module,
  say M here and read Documentation/modules.txt. If unsure, say N.

I feel a need to draw attention to "it might not be completely stable
yet".  Until the kernel maintainers see fit to declare kernel-space
NFSD the ONLY OPTION instead of being one of two options,
distributions should make a clear distinction between the two.
Therefore, the kernel-space NFSD binary must be named rpc.knfsd, not
rpc.nfsd .

  Also, until the kernel maintainers remove the stability warning,
distributions should provide the user-space NFSD as an option.

  I hope to see an errata to address at least the nfsd -vs- knfsd
issue.  If you could include a user-level NFSD I would be completely
mollified.

I have also had a problem with this error.  I was previously running
RH 6.0 (fresh install), kernel 2.2.5-15 (Or whatever it was that came
with RH 6.0.) After updating to kernel version 2.2.10, I have found
that my NFSd fails with the same error message:
nfssvc: Function not implemented

I'm fairly sure that this is a kernel problem, and not one of RH's,
but I have not seen a fix for it.  I am not attempting to use RH to
server NFS, but rather only to read from UNiX mounts.  Obviously that
no longer works! :-)

Machine Specs:
iNtel P2-233, 64 RAM, Intel EtherExpress Pro

Has anyone seen a fix for this? (Am I building the kernel improperly?)
 I also disabled EXPERIMENTAL kernel settings at the beginning of
'make  xconfig'.  Perhaps this has something to do with it?

I have also had a problem with this error.  I was previously running
RH 6.0 (fresh install), kernel 2.2.5-15 (Or whatever it was that came
with RH 6.0.) After updating to kernel version 2.2.10, I have found
that my NFSd fails with the same error message:
nfssvc: Function not implemented

I'm fairly sure that this is a kernel problem, and not one of RH's,
but I have not seen a fix for it.  I am not attempting to use RH to
server NFS, but rather only to read from UNiX mounts.  Obviously that
no longer works! :-)

Machine Specs:
iNtel P2-233, 64 RAM, Intel EtherExpress Pro

Has anyone seen a fix for this? (Am I building the kernel improperly?)
 I also disabled EXPERIMENTAL kernel settings at the beginning of
'make  xconfig'.  Perhaps this has something to do with it?

I saw this error message when I upgraded to 2.2.10 from the default
Redhat 6.0 kernel.  It seemed to be cleared up when I compiled (the
experiemental) nfs server support directly into the kernel and not as
a module.

OK - I recompiled my kernel with Experimental options turned *ON* (I
discovered that my epic100 is an "Experimental" driver anyway...
*sigh*)

and I still get this error.  I *have* enabled the knfs stuff in
menuconfig, as far as I can tell.  As modules.  My ".config" file
contains:
#
# Network File Systems
#
CONFIG_CODA_FS=m
CONFIG_NFS_FS=m
CONFIG_NFSD=m
CONFIG_NFSD_SUN=y
CONFIG_SUNRPC=m
CONFIG_LOCKD=m
[...]

Now, when I try to do a "modprobe nfs", I get:
/lib/modules/2.2.5-22/misc/sunrpc.o: unresolved symbol global_bh_lock
/lib/modules/2.2.5-22/misc/sunrpc.o: unresolved symbol __global_cli
/lib/modules/2.2.5-22/misc/sunrpc.o: unresolved symbol kernel_flag
/lib/modules/2.2.5-22/misc/sunrpc.o: unresolved symbol
__global_save_flags
/lib/modules/2.2.5-22/misc/sunrpc.o: unresolved symbol waitqueue_lock
/lib/modules/2.2.5-22/misc/sunrpc.o: unresolved symbol
__global_restore_flags
/lib/modules/2.2.5-22/misc/sunrpc.o: unresolved symbol synchronize_bh
sunrpc: No such file or directory
sunrpc: No such file or directory

This appears to be related to the SMP code.  If I compile a
uniprocessor kernel, I don't get this error ?!?!?!

In *either* case, when I try to start NFS, I see:
Starting NFS services:                                     [  OK  ]
Starting NFS statd:                                        [  OK  ]
Starting NFS quotas:                                       [  OK  ]
Starting NFS mountd:                                       [  OK  ]
Starting NFS daemon:
nfssvc: Function not implemented
                                                           [FAILED]

No matter what I have turned on or off, it seems...

Equally puzzling is that if I check /proc/ksyms, I *do* seem to have
c0212098 global_bh_lock_R__ver_global_bh_lock
c010ac84 __global_cli_R__ver___global_cli
c01d5480 kernel_flag_R__ver_kernel_flag
c010ae00 __global_save_flags_R__ver___global_save_flags
c01dde6c waitqueue_lock_R__ver_waitqueue_lock
c010ae44 __global_restore_flags_R__ver___global_restore_flags
c010ac20 synchronize_bh_R__ver_synchronize_bh

However, I do not, in fact have anything resembling nfssvc in the
running kernel.

Any help here would be greatly appreciated.
-Adam Thompson <athompso>

After reviewing this page and spending some time with RH technical
support, I found the following work around for this problem:

  In configuring your kernel, make sure to enable the prompt for
  alpha code (the first question in the configuration dialog).
  Then under File Systems -> Network File Systems select the kernel
  based (experimental) nfs setup.

I have tried this on two machines that previously failed and now NFS
starts properly and appears to work.

There should be a better work around for this bug - the 'help' message
for the kernel based nfs server specifically says it may not be
completely stable.  It appears to me that RH has only provided the
kernel based nfs programs (knfs and knfs-clients) with RH 6.0.

You can also work around this problem by installing the old
user-land NFS server from RedHat 5.2.  See bug #5689 for more
details.  I won't guarantee that it works for everyone but it
works for me.