bs> dy> Looking at src/sys/arch/macppc/dev/if_mc.c, it seems that the author
bs> dy> (Dave Huang) had intended to let me set media 10base5 or media 10baseT
bs> dy> with ifconfig, but only media manual is available.  (If there are switches
bs> dy> inside the S900 to select the media, I have not found them.)
bs>
bs> Sounds like there might be a negotiation issue. I know that ethernet in=20
bs> general can get crap performance if one side has full-duplex turned on and=
bs> 20
bs> the other doesn't.

I'll be among the first to state that nearly every Mac I've ever worked with 
has issues with autonegotiation (ask me about G5's and Catalysts sometime... 
:-p), but here's the rub as I understand the problem: the interface driver 
doesn't seem to be accepting any speed or duplex options. Not having worked 
with an mc0 driver before (outside of MacOS), I would nonetheless make sure 
that 
	ifconfig mc0 -media 10baseT
doesn't get the job done (but I think this is exactly what you tried). 

Oh, one point of order on the MACE: if there is no link status on the
interface, it may fail to initialize properly. A plague of a problem in
MacOS, where Apple consistently coded the adev to fail the networking prefs
back to LocalTalk (you can imagine the havoc when a switch would go 
offline and everyone would reboot... :-o).

Of course, <net/if_media.h> suggests that MANUAL means find the dip switches,
but this whole thing makes me suspicious that the driver was originally
coded for a different version of MACE chip (namely, one that had dip
switches :-).  It appears to my highly *un*trained eye that what the driver
is doing is setting PORTSEL_GPSI | ENPLSIO. A cursory search for MACE
specs on the Net suggests only that GPSI is a port type (why not 10BT is
the question of the moment) and that ENPLSIO enables additional I/O pins
on the chip.

So, it looks to me that at no time is the driver coming anywhere near
using the PORTSEL_10BT that I would expect to be invoked *somewhere* in the
code. In point of fact, in mc_attach() there is a totally suspicious
situation at lines 182 and 183 where PORTSEL_10BT is commented out in favor
of PORTSEL_GPSI.

Were I you, since I'd be willing to risk a kernel meltdown to shotgun
the problem, I'd put the 10BT back in and take the GPSI out. I'd also 
change mc_select_utp() at line 361 to use PORTSEL_10BT instead of PORTSEL_GPSI.
Trying both PORTSEL_10BT and PORTSEL_10BT | ENPLSIO if the first doesn't
work is probably in order for such barbaric driver coding. ;-)
You may also want to have a look at the am79c950.c driver code, since
that is where the MANUAL setting gets invoked. And you can always try
removing ENPLSIO from the existing PORTSEL_GPSI configuration.

Of course, the way to bet is that It's Not That Simple, but hopefully some
of the Higher Authorities on the list who actually know how this stuff works
can offer more substantive analyses. :-)

FWIW,
	Paul

Paul Frommeyer            Work: Senior Network Engineer  pfrommeyer@deskey.com
Internet Engineer, CCIE   Play: Network Sorcerer At Large     corwin@palas.com