From owner-freebsd-sparc64@FreeBSD.ORG Wed Dec 3 02:11:19 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6EA4716A4CE for ; Wed, 3 Dec 2003 02:11:19 -0800 (PST) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id C304243FF2 for ; Wed, 3 Dec 2003 02:11:17 -0800 (PST) (envelope-from mux@freebsd.org) Received: by elvis.mu.org (Postfix, from userid 1920) id 9F85D2ED435; Wed, 3 Dec 2003 02:11:17 -0800 (PST) Date: Wed, 3 Dec 2003 11:11:17 +0100 From: Maxime Henrion To: Marius Strobl Message-ID: <20031203101117.GQ8404@elvis.mu.org> References: <1508164067.20031202154142@inar.ru> <20031202152116.GN8404@elvis.mu.org> <20031202171304.A51744@newtrinity.zeist.de> <20031202163319.GP8404@elvis.mu.org> <20031202194836.E73910@newtrinity.zeist.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031202194836.E73910@newtrinity.zeist.de> User-Agent: Mutt/1.4.1i cc: Aditya cc: freebsd-sparc64@freebsd.org Subject: Re: FreeBSD-5.2 BETA & Davicom ethernet X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2003 10:11:19 -0000 Marius Strobl wrote: > On Tue, Dec 02, 2003 at 05:33:19PM +0100, Maxime Henrion wrote: > > Marius Strobl wrote: > > > On Tue, Dec 02, 2003 at 04:21:16PM +0100, Maxime Henrion wrote: > > > > > > > > This is expected for now. I coudln't find the time to add support for > > > > getting the MAC address from the OpenFirmware in dc(4) yet. With a bit > > > > of luck, this will be working soon, though probably not before > > > > 5.3-RELEASE, unless someone else tackles this issue. > > > > > > > > > > A while ago I already sent you a patch similar to the attached one which > > > gets the MAC address for Sun onboard NICs via OpenFirmware in dc(4). But > > > you didn't like the MD ifdefs in if_dc.c and wanted to implement it some > > > layers above. > > > > Yes, I remember it. But as I said, it's an ugly hack, and needs to be > > done better. If people really need a MAC address they could use an > > "ifconfig dc0 ether xx:xx:xx:xx:xx:xx" command. Besides, there have > > I agree that this is not the best way to do it, on the other hand what > did you have in mind when you wrote "via OpenFirmware in dc(4)"? My formulation wasn't appropriate, I didn't mean that I intend to add that code to dc(4) itself. > One could leave the check for local-mac-address out for now and just > call OF_getetheraddr(), dc(4) then should compile as a module and > people would get a working MAC address, also the same on all interfaces, > until the proper way is implemented. > > > been reports of crashes with dc(4) cards under sparc64 at high load. So > > I'm really reluctant to commit this. Which makes me wonder : do you > > experience these crashes? > > No. When they were reported shortly after you commited the busdma > conversion of dc(4) I tried to reproduce them by transfering large > files and running buildworld via NFS but had no problems. > As a side note, from the reports I read it was never clear to me if > those crashes happend with onboard Davicom NICs or with other dc(4) > NICs. There now also seem to be several people that use onboard > Davicom NICs with FreeBSD/sparc64 and there where no new reports of > such crashes. In if_dc.c revision 1.122 and 1.123 mbr@ fixed a > Davicom-related bug, maybe it was also the cause for those crashes. That's definitely good news. The reports I had about crashes were with other dc(4) NICs plugged into a PCI slot, not with onboard Davicom NICs if I remember correctly, but I could be wrong. This changes the deal quite a bit, it may make sense to add this code so that users of Sun boxes with integrated Davicom cards are happy with 5.2-RELEASE. I was reluctant because I thought the problem was with all cards. I'll talk to re@ about that. Cheers, Maxime