Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 14 May 2002 10:22:21 +0100
From:      Jamie Heckford <jamie@tridentmicrosystems.co.uk>
To:        Matthew Dillon <dillon@apollo.backplane.com>
Cc:        freebsd-stable@freebsd.org, freebsd-hackers@freebsd.org
Subject:   Re: NFS Problems with Quantum Snapserver 4100 (BGE Cards!)
Message-ID:  <20020514102221.A55183@mufuf.trident-uk.co.uk>
In-Reply-To: <200205131808.g4DI8JnE069036@apollo.backplane.com>; from dillon@apollo.backplane.com on Mon, May 13, 2002 at 11:08:19AM -0700
References:  <20020513181756.A53366@mufuf.trident-uk.co.uk> <200205131808.g4DI8JnE069036@apollo.backplane.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Im pretty sure this has to be related to the Broadcom Cards.

I tested it again this morning from the Compaq rack with the bge card
in, same problem. tried doing cp -r /usr/ports /data1-home/ (nfs), copied
about 1.3M and then froze. Even cd'ing to the directory to try and do
an ls caused my shell to freeze, with Ctrl+C failing to provoke a
response.

Just to confirm it wasn't a snap server issue, I mounted the nfs share
on 3 other FreeBSD boxes (4.2-R, 4.3-R and 4.6-PRERELEASE) that have
a variety of 3Com and Intel cards installed, tested copying a 2GB mailbox (!),
worked fine. /usr/ports... worked fine.

Another odd thing i've seen on the box with the broadcom cards is that when
connected via ssh, a simple ls on a large directory (held on a local disk)
will get about halfway,
pause for about a second, then continue. At first I put this down to traffic
on my segment but its happening practically all the time, and this is on
100Mbit connection on the same switch.

Just a reminder of the troublesome card...
bge0: <Broadcom BCM5701 Gigabit Ethernet> mem 0xf7fb0000-0xf7fbffff irq 5 at device 5.0 on pci1

FYI there on Cisco Catalyst 2924 switches, and yes they are properly configured ;)

CC'ed to hackers as its related to a prev. discussion.

Thanks for all your help so far

Jamie

How I wish I went for the other supplier now :)

Thus spake Matthew Dillon (dillon@apollo.backplane.com) :

>     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: <Broadcom BCM5701 Gigabit Ethernet> 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-hackers" in the body of the message




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