From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 23:43:42 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC3B816A41F; Thu, 17 Nov 2005 23:43:42 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9104443D5F; Thu, 17 Nov 2005 23:43:40 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.13.4/8.13.4) with ESMTP id jAHNhENS007569; Thu, 17 Nov 2005 15:43:14 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.13.4/8.13.4/Submit) id jAHNhEMV007568; Thu, 17 Nov 2005 15:43:14 -0800 (PST) Date: Thu, 17 Nov 2005 15:43:14 -0800 (PST) From: Matthew Dillon Message-Id: <200511172343.jAHNhEMV007568@apollo.backplane.com> To: Andrew Gallatin References: <20051117010651.97608.qmail@web50303.mail.yahoo.com> <20051117143322.lvz347pzkcg480co@netchild.homeip.net> <200511171135.53903.jhb@freebsd.org> <200511171858.jAHIwOoc006061@apollo.backplane.com> <17276.60450.831340.357584@grasshopper.cs.duke.edu> Cc: alan bryan , FreeBSD current mailing list , freebsd-current@freebsd.org, "Bjoern A. Zeeb" , Alexander Leidinger Subject: Re: [PATCH] nve(4) locking cleanup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2005 23:43:43 -0000 : : :I have a pair of DFI Nforce-4 based "NF4 ultra" boards, where the :FreeBSD driver will never pass any traffic at all (and never has). : :Matthew Dillon writes: : > At this point I believe that the remaining problems are entirely within : > Nvidia's nvnet object module. I don't think there is anything we can do : > about it short of NVidia coming out with an update (which isn't likely). : :At least on my boards, the Solaris "nfo" driver from :http://homepage2.nifty.com/mrym3/taiyodo/eng works flawlessly. :The object file they use has the same checksum as the one used :by the FreeBSD driver. : :Note that this is at 100Mb/s speeds, and is used for NFS (client), :and ssh sessions only. I haven't tried really hard to beat the :snot out of it, but it has worked for months without me seeing :a problem in daily use. All my testing and comments are at GiGE speeds. I haven't actually tried 100BaseT speeds with all the most recent fixes in place. I will do that to see if I get the same hardware death issue. p.s. The MII interface will support GigE speeds if you use the extra speed selector bit that a number of manufacturers are now using to extend the MII specification. : > Now, linux *has* a native implementation of this driver that does not : > use the Nvidia module, and I have gotten reports that it does not suffer : > from the same problems. : :I'm working on a linux driver right now, and have enabled the the :linux slab debugging stuff (similar to the type of malloc debugging we :get with INVARIANTS). At boot (before I even load my driver), the :forcedeth driver from 2.6.13.1 will receive corrupted frames. Anybody :porting that driver should look out for buffer over/under flow issues :in it... : :Drew I recall there being a comment in the linux source code regarding the corrupt frame issue. The main issue for me with nvnet is this hardware lockup I am getting that requires physically pulling the power cord to fix. That reaks of a 'hardware bug' or 'BIOS misprogramming' issue. A corrupt frame problem could be a latency or FIFO issue, or another hypertransport issue. I also suspect that the nvnet driver has an interrupt race somewhere in its blackboxed object module. I've gone over the driver tooth and nail and can't come up with any reason why after successfully transfering gigabytes and gigabytes of data it would suddenly stop generating transmit interrupts. I'm gonna play with it a bit more... the only thing left that I haven't investigated is the transmit and receive ring management. -Matt Matthew Dillon