FreeBSD 5.1-RELEASE on SunFire V100

Pete Bentley pete at
Thu Aug 28 03:55:17 PDT 2003

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

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] dmfe0: Davicom DM9102 (v1.1): type "ether" mac address 00:03:ba:06:31:5e
Aug 27 17:46:40 peach gld: [ID 944156] 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.

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.

More information about the freebsd-sparc64 mailing list