From owner-freebsd-sparc64@FreeBSD.ORG Tue Dec 2 10:48:46 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 9D86216A4CE; Tue, 2 Dec 2003 10:48:46 -0800 (PST) Received: from newtrinity.zeist.de (newtrinity.zeist.de [217.24.217.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id A609A43F3F; Tue, 2 Dec 2003 10:48:42 -0800 (PST) (envelope-from marius@newtrinity.zeist.de) Received: from newtrinity.zeist.de (localhost [127.0.0.1]) hB2ImfI2054829; Tue, 2 Dec 2003 19:48:41 +0100 (CET) (envelope-from marius@newtrinity.zeist.de) Received: (from marius@localhost) by newtrinity.zeist.de (8.12.10/8.12.10/Submit) id hB2ImaDn054828; Tue, 2 Dec 2003 19:48:36 +0100 (CET) (envelope-from marius) Date: Tue, 2 Dec 2003 19:48:36 +0100 From: Marius Strobl To: Maxime Henrion Message-ID: <20031202194836.E73910@newtrinity.zeist.de> References: <1508164067.20031202154142@inar.ru> <20031202152116.GN8404@elvis.mu.org> <20031202171304.A51744@newtrinity.zeist.de> <20031202163319.GP8404@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20031202163319.GP8404@elvis.mu.org>; from mux@freebsd.org on Tue, Dec 02, 2003 at 05:33:19PM +0100 X-AntiVirus: checked by AntiVir Milter 1.0.6; AVE 6.22.0.1; VDF 6.22.0.53 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: Tue, 02 Dec 2003 18:48:46 -0000 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)"? 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. > > + /* > > + * If this is an onboard dc(4) the station address read from > > + * the EEPROM is all zero and we have to get it from the fcode. > > + */ > > + for (i = 0; i < ETHER_ADDR_LEN; i++) > > + if (eaddr[i] != 0x00) > > + break; > > AFAICT, the "break" here breaks out of the for loop, not out of the case > statement, which is what you probably wanted. So, whether or not the > MAC address is all zeros, you'll try to get the MAC address from > OpenFirmware. Indeed. I had this right in the first version of that patch but broke it when merging with updated sources recently.