Date: Thu, 28 Aug 2003 11:55:13 +0100 From: Pete Bentley <pete@sorted.org> To: freebsd-sparc64@freebsd.org Subject: Re: FreeBSD 5.1-RELEASE on SunFire V100 Message-ID: <20030828105513.GB32941@sorted.org> In-Reply-To: <BAY1-F88hFjp0K59P9O000477eb@hotmail.com> References: <BAY1-F88hFjp0K59P9O000477eb@hotmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030828105513.GB32941>