From owner-freebsd-stable Mon May 13 11: 8:37 2002 Delivered-To: freebsd-stable@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 1110C37B400 for ; Mon, 13 May 2002 11:08:24 -0700 (PDT) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.3/8.9.1) with ESMTP id g4DI8KhU069037; Mon, 13 May 2002 11:08:20 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.3/8.12.3/Submit) id g4DI8JnE069036; Mon, 13 May 2002 11:08:19 -0700 (PDT) Date: Mon, 13 May 2002 11:08:19 -0700 (PDT) From: Matthew Dillon Message-Id: <200205131808.g4DI8JnE069036@apollo.backplane.com> To: Jamie Heckford Cc: freebsd-stable@FreeBSD.ORG Subject: Re: NFS Problems with Quantum Snapserver 4100 References: <20020513181756.A53366@mufuf.trident-uk.co.uk> Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This sounds like a classic MTU problem. Small packets are fine but when you copy a large file full-sized packets have to start winging across the network and something doesn't like them. The broadcom NICs can handle large MTUs, but the NFS server and/or network infrastructure may not be able to. Many GigE switches cannot handle large packets, for example. Try setting the MTU on the broadcom interface to 1500 if it isn't there already (you may have to 'route delete' any cached route to the NFS server after making the change). Another possibility is that the broadcom NIC is broken in regards to handling large packets. Certain bit patterns can cause the hardware checksum code to fail. If hardware checksums are turned on, turn them off and see if that helps. -Matt :Hi, : :Im having odd problems with a nfs mount I have which is on a Quantum Snapserver :Model 4100. : :Basically, I have the nfs mount on /data1-home. Small files are fine, but :whenever I try and copy anything fairly "big" (5MB!) the command prompt :just sits there. : :cd'ing to /data1-home just results in the command hanging there, and the only :way to get back to the NFS share is the force an umount and remount. : :Has anyone had any similar problems? : :Im running FreeBSD 4.6-PRERELEASE #1: Thu May 9 12:50:45 BST 2002 : :Only thing i've noticed is :May 13 17:45:13 morrison /kernel: nfs server data1:/home: not responding : :Checked network connections and they are all ok, duplex correct etc and no :firewall rules conflicting. : :Only thing is this box does have a Broadcom BCM5701 NIC in it which I know :has had a few small issues.. :bge0: mem 0xf7fb0000-0xf7fbffff irq 5 at device 5.0 on pci1 : :Any help greatly appreciated. : :thanks, : :-- :Jamie Heckford To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message