Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 8 May 2003 10:28:02 -0700 (PDT)
From:      Don Lewis <truckman@FreeBSD.org>
To:        hrs@eos.ocn.ne.jp
Cc:        stable@FreeBSD.org
Subject:   Re: NFS problem?
Message-ID:  <200305081728.h48HS2M7035782@gw.catspoiler.org>
In-Reply-To: <20030508.235820.41649159.hrs@eos.ocn.ne.jp>

next in thread | previous in thread | raw e-mail | index | archive | help
On  8 May, Hiroki Sato wrote:
> Hi,
> 
>  I noticed that my 4.8R box seems to have a NFS problem.
>  I use a FreeBSD/i386 4.8R box as a NFS server, and 
>  a FreeBSD/i386 5-CURRENT (as of today) as the NFS client.
> 
>  On the client, /a (on the server) can be mounted successfully
>  with -o rw,bg,intr,mntudp options.  However, when a large amount
>  of write operations such as "cp -r /home/ncvs /a" are performed
>  on the client, the transfer is unexpectedly stalled and
>  "nfs server xxx:/a: not responding" is reported.
>  A long time (about 10-20 minutes) later, the operations
>  are finished.
> 
>  During the stall, tcpdump on the server says repeatedly
>  the following:
> 
>   23:44:43.050494 nfsclient.1731995803 > nfsserver.nfs: 1472 write [|nfs] (frag 33263:1480@0+)
>   23:44:43.050506 truncated-ip - 2 bytes missing! nfsserver > nfsclient: udp (frag 33263:224@1480)
> 
>  Did anyone experience this symptom?  I tried NetBSD/sparc64
>  as a NFS client, but got the same result.

I've run into this exact problem.  I bet your client box has an Intel
Pro 100/S fxp card or something similar.  The problem isn't in NFS, but
rather a possible bug in the Ethernet chip used in your fxp and how the
driver in -current attempts to use some new features in this chip.

If possible, find the exact part number of the chip on your fxp card,
and also run "pciconf -l | grep fxp" on your -current box.

The problem is that certain-sized fragmented packets get truncated by
the card when the card is programmed in a mode to use some new features
that this particular Ethernet chip has available.  In the short term,
the solution to your problem is to patch your copy of the fxp driver so
that this chip is treated like an older model.  If you can't do that,
then change your NFS mount options to use TCP, which will avoid the
packet fragmentation.


Index: sys/dev/fxp/if_fxp.c
===================================================================
RCS file: /home/ncvs/src/sys/dev/fxp/if_fxp.c,v
retrieving revision 1.178
diff -u -r1.178 if_fxp.c
--- sys/dev/fxp/if_fxp.c	30 Apr 2003 04:14:56 -0000	1.178
+++ sys/dev/fxp/if_fxp.c	3 May 2003 20:35:56 -0000
@@ -580,7 +580,11 @@
 	 * Be careful to do this only on the right devices.
 	 */
 
+#if 0
 	if (sc->revision == FXP_REV_82550 || sc->revision == FXP_REV_82550_C) {
+#else
+	if (0) {
+#endif
 		sc->rfa_size = sizeof (struct fxp_rfa);
 		sc->tx_cmd = FXP_CB_COMMAND_IPCBXMIT;
 		sc->flags |= FXP_FLAG_EXT_RFA;
 



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200305081728.h48HS2M7035782>