From owner-freebsd-sparc64@FreeBSD.ORG Thu Aug 28 03:55:17 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 19C8D16A4BF for ; Thu, 28 Aug 2003 03:55:17 -0700 (PDT) Received: from radix.sorted.org (radix.sorted.org [194.70.217.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id 940CA43FAF for ; Thu, 28 Aug 2003 03:55:15 -0700 (PDT) (envelope-from pete@sorted.org) Received: by radix.sorted.org (Postfix, from userid 501) id 9A6752BA62; Thu, 28 Aug 2003 11:55:13 +0100 (BST) Date: Thu, 28 Aug 2003 11:55:13 +0100 From: Pete Bentley To: freebsd-sparc64@freebsd.org Message-ID: <20030828105513.GB32941@sorted.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Subject: Re: FreeBSD 5.1-RELEASE on SunFire V100 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: Thu, 28 Aug 2003 10:55:17 -0000 On Thu, Aug 28, 2003 at 09:57:26AM +0000, Rob MacGregor wrote: > My problem is that, now they're available, neither interface reports it's > MAC address (it did when Solaris 9 was installed): Yup, see the "Netra X1" threads recently, they're basically the same hardware. Interestingly, I have another X1 running Solaris 9 and I get the impression these interfaces may not have a MAC address EEPROM at all... Under Solaris, these interfaces appear to ignore the local-mac-address? eeprom setting. Dmfe0 gets the host's MAC address while dmfe1 gets that address plus 1, regardless of the EEPROM setting, ie:- Sun Netra X1 (UltraSPARC-IIe 400MHz), No Keyboard OpenBoot 4.0, 640 MB memory installed, Serial #50737502. Ethernet address 0:3:ba:6:31:5e, Host ID: 8306315e. [...] Aug 27 17:46:40 peach gld: [ID 944156 kern.info] dmfe0: Davicom DM9102 (v1.1): type "ether" mac address 00:03:ba:06:31:5e Aug 27 17:46:40 peach gld: [ID 944156 kern.info] dmfe1: Davicom DM9102 (v1.1): type "ether" mac address 00:03:ba:06:31:5f This is regardless of the OBP version (I just upgraded that box from 1.0.1 to 1.0.18 - not done the FreeBSD box yet). My current workaround is that I explicitly set the MAC address using ifconfig from a script in /etc/rc.d which works fine. There is also a patch to the dc driver that Marius Strobl posted on Aug 22 that should set the MAC address to that of the host... Not tried it yet due to hardware/work issues but should have some results later today or tomorrow. > There is another minor problem in that the interfaces are the "wrong" way > around. Interface 0 is reported as dc1 and interface 1 as dc0. Do you have "options OFW_NEWPCI" in your kernel config? If not, try it as this should make the probing order more like that of Solaris. (Actually, I believe that is the default now so you may just need a newer -current) > dc1: watchdog timeout > dc1: failed to force tx and rx to idle state > dc1: failed to force tx and rx to idle state Ditto, but it seems like a harmless timeout when configuring the interface. > Finally, a strange one: > > warning: no time-of-day clock registered, system time will not be set > accurately Yup, there's no driver for the time-of-day clock in these beasties. Even Solaris 8 needed a patch to add one. End result, the machine has no idea about the passage of time when it's not running an OS. Workaround: Set the time at boot time with ntpdate or rdate and then run NTP. When I get a moment (ha), I'll go see if there's a driver we can crib from in the other BSDs or Lin*x. > Now, I've got a few days to play with this system before I have to lock it > down and put it live. If anybody has anything they think is worth trying > I'll give it a go. Depends what you mean by "live". FreeBSD/sparc64 is definitely getting there but (at least on this low-end hardware) I don't think it's production quality yet... I had one IOMMU-related panic last night, but unfortunately lost the details (unexpectedly short xterm scrollback, sorry) about an hour *after* it completed a cvsup+make world... And then there was the vfork()/perl weirdness just recently. I'd say hammer on it and track down/report/fix bugs but don't use it for an application where crashes are unacceptable. Pete. PS Anyone know a source for drive sleds and cooling fans for the X1 in the UK? Cheap and cheerful 3rd party stuff is fine, otherwise I guess I'll have to go through the Sun VAR we use at work and pay their prices.