From owner-freebsd-stable Tue May 14 11:54: 8 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 2A0A737B403; Tue, 14 May 2002 11:54:01 -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 g4EIrxhU075306; Tue, 14 May 2002 11:53:59 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.3/8.12.3/Submit) id g4EIrxN8075305; Tue, 14 May 2002 11:53:59 -0700 (PDT) Date: Tue, 14 May 2002 11:53:59 -0700 (PDT) From: Matthew Dillon Message-Id: <200205141853.g4EIrxN8075305@apollo.backplane.com> To: Jamie Heckford Cc: freebsd-stable@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: NFS Problems with Quantum Snapserver 4100 (BGE Cards!) References: <20020513181756.A53366@mufuf.trident-uk.co.uk> <200205131808.g4DI8JnE069036@apollo.backplane.com> <20020514102221.A55183@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 :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: 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 :) It should also work if you force the GigE card into 100BaseTX mode, assuming the switch can deal with it. Though of course then you are not getting GigE speeds. Your description is very similar to a problem I had on my 2550's that Bill Paul finally solved. It turned out that my 2550's (BCM5700) were not initializing the polynomial functions properly and this resulted in packet loss. Whenever you get bit stuffing packet loss like that, certain bit patterns will *always* fail. But I'm sure this issue has already been dealt with on the 5701 so the problem you are having is probably different. The result is the appearance of hicups and delays on a TCP connection, and repeatable hangs when just the wrong data pattern is transmitted (because that packet winds up failing every time rather then just some of the time). Another possibility in regards to packet loss is simply a bad cable (if you are running GigE over copper). GigE is very sensitive to cable issues and a bad crimp will screw things up easily. In anycase, my feeling about GigE in general is that it's a great cheap way to aggregate data on an uplink, or to an NFS server that needs it, but the incremental cost and hassle factor are still too high to extend the benefit to generic servers. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message