From owner-freebsd-net@FreeBSD.ORG Thu Jul 12 16:41:47 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9F05D16A400 for ; Thu, 12 Jul 2007 16:41:47 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from s200aog11.obsmtp.com (s200aog11.obsmtp.com [207.126.144.125]) by mx1.freebsd.org (Postfix) with SMTP id 33DF213C45B for ; Thu, 12 Jul 2007 16:41:39 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from source ([217.206.187.80]) by eu1sys200aob011.postini.com ([207.126.147.11]) with SMTP; Thu, 12 Jul 2007 16:41:07 UTC Received: from [10.0.0.89] (bill.mintel.co.uk [10.0.0.89]) by rodney.mintel.co.uk (Postfix) with ESMTP id 10D8318141B; Thu, 12 Jul 2007 17:41:07 +0100 (BST) Message-ID: <469657BD.3010204@tomjudge.com> Date: Thu, 12 Jul 2007 17:33:01 +0100 From: Tom Judge User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Doug Ambrisko References: <200707121608.l6CG8Sur002750@ambrisko.com> In-Reply-To: <200707121608.l6CG8Sur002750@ambrisko.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Josh Paetzel , freebsd-net@freebsd.org, Julian Elischer , Paul Schmehl Subject: Re: Question about bce driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2007 16:41:47 -0000 Doug Ambrisko wrote: > Tom Judge writes: > | > | I am very surprised at that. The driver in 6.1 was un-usable in our > | environment. 6.2 makes it usable with standard frames under moderate > | load. However use jumbo frames and it all falls apart, and unfortunately > | the network these systems are plugged into is GigE only with a 8192 > | Jumbo mtu. > > There are several back-ports/patches in our 6.1 image that we are running! > Also we don't do jumbo packets. It wouldn't surprize me if there were > jumbo packets issues. Other drivers have had issues with that at > certain sizes. What Julian is really saying, is that for our work-load > and version of the bce driver things are pretty darn stable. None > of our patches are private and are from various versions that have been > in -current etc. (ie. pre-Serdes support). > > There is one possibility in that our IPMI support might be ahead of > what is in -current. I forget. IPMI WRT to Broadcom can be "tricky" > and cause issues at the PHY level. > > | I have been trying to get some help with the problem for over a month > | now without luck. Firstly I was asked to enable some debugging in the > | driver, this just uncovered what seems to be memory management bug in > | the driver. A patch was suggest for this but it did not solve the > | problem. Next I noticed the NetBSD guys had we written the offending > | parts of code which I then ported to FreeBSD driver. Still no luck, > | although the problem was not as bad as before. Then I took a look at > | the OpenBSD driver, and it seems that they just completely disabled > | jumbo frames as they are just so ropey. > | > | If a patch was released today that fixed the problem then I may be able > | to fully test the driver and not have to replace the NIC's. However I am > | running out of time with deployment deadlines and I need this kit in > | production by the latest mid next week. > > Which is reasonable unless you have the time to try to really dig in > and try to isolate the problem with the firmware or the driver (ie. hack > on the driver). Unfortunately you are blazing into uncharted teritory > with the bce driver. David has done some great work getting it to work > under FreeBSD in what looks to me as his spare time. Things are improving > all of the time. > > Doug A. Firstly I am not trying to slate David's efforts, however there are and have been some big problems with the driver. As for the IPMI integration, our management controllers are set to used the remote access controller NIC (Set as dedicated in the bios) rather than share the host nics. Unfortunately I can not justify spending the time on the driver to management when the problem can be solved by spending a relatively small amount of money on hardware to fix the problem. Tom