Matthew Orgass <darkstar@pgh.net> responds to my question:

>>     I tried the manpage for "ifconfig", which suggests that "media
>>     type" might do the trick, but without the "de" manpage, I am
>>     guessing at the types, and not getting too far: "ifconfig de0
>>     media 10baseT" works as expected, and "ifconfig de0 media
>>     autoselect" makes it claim to be autoselecting but it selects
>>     10baseT.  "ifconfig de0 media 100baseT" results in the complaint
>>     "ifconfig: unknown Ethernet media subtype: 100baseT".
> 
>   Try 100baseTX :).  ifconfig -m tells you the supported media.

Right you are on both counts.  I probably deserve to be whacked on the
head a few times for not reading the manpage completely.  :-/

That got me partway there; I could coax (no pun intended!) the interface
into 100MB/s mode -- while a simple "ifconfig de0 media 100baseTX"
killed the communication, following that with "down" and "up" commands
resulted in communication coming back.

However, as soon as I tried to get the 100MB/s happening at boot time,
I had lots of problems.  I have now resolved them so that things work,
but either I am missing something, or else the folks who work on this
driver have a bugfix request. :-)

Here's what happens:

- If I dare to simply put the desired speed into rc.conf like so:
    ifconfig_de0="inet 132.205.121.53 netmask 0xffffff00 media \
       100baseTX mediaopt full-duplex"
  the kernel claims to have set the interface to 100, but in fact the
  machine ends up in a "funny state", where the "fast" light of the
  ethernet card is on, but the "link" light flickers, and meanwhile
  attempts to use the network seem to send packets down a black hole.

  A bit more detail on the order of events during the boot sequence:
    - rc says "setting tty flags".
    - kernel says "de0: enabling 10baseT port", which seems odd at
      that point -- I can only surmise that ttyflags is causing this
      somehow (I put echo and sleep statements into rc to isolate
      exactly when in relation to the rc commands the kernel spouts
      that line).
    - netstart says 'configuring network interfaces: de0', and
      then the kernel claims "de0: enabling Full Duplex 100baseTX
      port".
    - at that point, the network becomes non-functional, xntp
      complains that it cannot resolve my three time servers, and the
      machine finishes its boot sequence, but the network remains
      non-functional.

- I experimented with stuff like 
    ifconfig_de0="inet 132.205.121.53 netmask 0xffffff00 down \
       media 100baseTX mediaopt full-duplex up"
  but saw no improvement.

- I decided to just change the network card's speed in the rc.local
  script, doing first an "ifconfig de0 down media 100baseTX mediaopt
  full-duplex",  then an "ifconfig de0 up", which worked when invoked
  manually.  That plain code still resulted in an unusable network.
  There seems to be a timing problem.

- To my rc.local code, I added a "sleep 2" between the two ifconfig
  calls.  Finally, the right thing happened, and the network came up
  properly!  But there was an unpleasant side effect: during the
  2-second down, xntp timed out trying to resolve the time server
  names, and ended up with no peers.

- In order to get around the above side effect, I turned on named, and
  configured it as a stealth secondary for my domain, where the time
  servers reside.  Of course, I put my machine first in resolv.conf.
  Now it boots without complaining, and all services come up properly.


Summary:  I cannot use the ifconfig_* line in rc.conf to get my de0
          network card to use the 100Mb/s speed -- trying that just
          results in an unusable network state.  However, carefully
          timed code in rc.local will switch it to the faster speed,
          though a workaround is needed to avoid name service problems
          during the 2-second down time.


Anne.
-- 
Ms. Anne Bennett, Senior Analyst, IITS, Concordia University, Montreal H3G 1M8
anne@alcor.concordia.ca                                        +1 514 848-7606