You are seeing the exact same behavior we are seeing with our 3com
cards.  The problem, as you suggest, seems to be a change in revision from
3com on the 100-bt-xx cards.  We have three different cards, a 100-tx,
100-tx-m, and a 100-tx-nm.  The 100-tx card is recognized, and the phy is
properly probed and initialized.  The 100-tx-m and 100-tx-nm cards do the
same thing your card does, except that if you select autoselect with 
Windows for which media to use, the card actually does work, though you
can't control things like full or half duplex negotiation.  Like you, I
tried looking for the relevant differences between the FreeBSD `driver and
the NetBSD one, and like you, had a lot of trouble reconciling them
together.  I believe there might be a timing issue involved, but the 3com
documentation suggests that the phys are completely different in these
three cards and my understanding of what those differences are is where I'm
currently sitting.
-Brian
On Aug 26, 11:48pm, Robert Elz wrote:
} Subject: Re: 3com 3c905B-tx strange behaviour
}     Date:        Wed, 25 Aug 1999 11:47:40 -0400
}     From:        Tony Hernandez <tony.hernandez@intellon.com>
}     Message-ID:  <4405E0B28BB5D111B596006097B1A22F3B6B7F@COMMUNICATIONS>
} 
}   | Okay, now I'm having a similar problem at work.
} 
} I suspect that you will find that is some completely different problem.
} 
} I think I am seeing the same problem that you are on your home system,
} here's the relevant section of my dmesg output for anyone who cares...
} 
} ex1 at pci0 dev 15 function 0: 3Com 3c905B-TX 10/100 Ethernet
} ex1: interrupting at irq 5
} ex1: MAC address 00:10:5a:76:e9:b4
} ex: val=a ex_conf was 7 is 7  
} ex: mii icfg val=a icfg=0->600000 
} 
} The last two lines are some debug I added in the area where the
} driver is attempting to find the phy (fake phy in this case).
} 
} The relevant source lines are ...
} 
}         val = bus_space_read_2(iot, ioh, ELINK_W3_RESET_OPTIONS);
} /*ZZZ*/printf("ex: val=%x ex_conf was %x is %x\n", val, sc->ex_conf, val & ELINK
} _MEDIACAP_MII ? sc->ex_conf | EX_CONF_MII : sc->ex_conf);
}         if (val & ELINK_MEDIACAP_MII)
}                 sc->ex_conf |= EX_CONF_MII;
} 
} and
} 
}         if (sc->ex_conf & EX_CONF_MII) {
}                 /* 
}                  * Find PHY, extract media information from it.
}                  */
}                 u_int32_t icfg;
} 
}                 /* stolen from FreeBSD xl driver */
}                 GO_WINDOW(3);
}                 icfg = bus_space_read_4(iot,ioh,0);
} /*ZZ*/printf("ex: mii icfg val=%x icfg=%x",val, icfg);
}                 icfg &= ~(0xF << 20);
}                 icfg |= (6 << 20);
}                 bus_space_write_4(iot,ioh,0,icfg);
} /*ZZ*/printf("->%x\n", icfg);
} 
} (excuse the ugly formatting of the debug additions, it is a convention I
} have grown into over meany years to make sure I find and clean up that
} ugly stuff).
} 
} That last piece of code is (as the comment indicates) stolen ("borrowed" --
} it disn't help, so will be returned) from the FreeBSD xl driver.
} It makes no difference to anything (needless to say, the FreeBSD version
} had more symbolic constants and less magic numbers - but that is what it
} boils down to).
} 
} When the driver gets into mii_phy_probe() (just after the last of those
} printfs), and executes ...
} 
}                 bmsr = (*mii->mii_readreg)(parent, ma.mii_phyno, MII_BMSR);
} 
} it always gets 0 for bmsr.  Consequently no phy is found.
} 
} ifconfig -a prints ...
} 
} ex0: flags=8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST> mtu 1500
}         address: 00:10:4b:11:37:d9
}         media: Ethernet 10base2
}         status: active
}         inet 128.250.1.202 netmask 0xffffffc0 broadcast 128.250.1.255
}         inet6 fe80:1::210:4bff:fe11:37d9 prefixlen 64
}         inet6 3ffe:8001:2:100:210:4bff:fe11:37d9 prefixlen 64
} ex1: flags=8822<BROADCAST,NOTRAILERS,SIMPLEX,MULTICAST> mtu 1500
}         address: 00:10:5a:76:e9:b4
}         media: Ethernet none (none)
} 
} (plus lo0, ppp0 ... none of which are relevant).
} 
} ex0 is a 3c900B-TPC which works fine.   I didn't accidentally forget
} any lines for ex1, that's it.
} 
} ifconfig -m ex1 reports ...
} 
} ex1: flags=8822<BROADCAST,NOTRAILERS,SIMPLEX,MULTICAST> mtu 1500
}         media: Ethernet none (none)
}         supported Ethernet media:
}                 media none
} 
} 
} The fake phy isn't being located.    All this debug has been from an i386.
} I have an identical card in an alpha, which behaves identically there.
} On the alpha, it is (currently) the only ethernet card I have installed
} (the only net card of any kind), so I currently have that running FreeBSD
} (which is truly flaky on an alpha - but does recognise the ethernet card
} properly, so I have a way to move data to and from the NetBSD which boots
} there when I am looking for the problems).
} 
} On FreeBSD/alpha the dmesg output is ...
} 
} xl0: <3Com 3c905B-TX Fast Etherlink XL> rev 0x64 int a irq 3 on pci0.9.0
} xl0: Ethernet address: 00:10:5a:76:5f:06
} xl0: autoneg complete, link status good (half-duplex, 10Mbps)
} 
} and ifconfig -m ...
} 
} xl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
}         inet 128.250.26.150 netmask 0xffffffc0 broadcast 128.250.26.191
}         ether 00:10:5a:76:5f:06 
}         media: 10baseT/UTP <half-duplex>
}         supported media: autoselect 100baseTX <full-duplex> 100baseTX <half-duplex> 100baseTX 10baseT/UTP <full-duplex> 10baseT/UTP <half-duplex> 10baseT/UTP
} 
} It is truly a pity that the FreeBSD xl and NetBSD ex drivers are so
} wildly different, it makes attempting to work out what the difference is
} between the two of them painful indeed.   I have been looking, and have
} tried a few things, but nothing which has achieved any results so far.
} 
} It may be that there's a new breed of 3c905B-TX's around which aren't
} quite the same as some earlier revisions.
} 
} Or it may be host cpu related - there is a comment in FreeBSD's xl
} driver about extreme care being required to get the phy detection correct
} or that changes of processor/bus/... can cause it to fail.  I do notice
} some extra DELAY(1) calls in sections of their driver that the NetBSD
} one lacks - though those don't seem to be in sections that should matter
} here (the code is never getting that far I don't think).
} 
} The i386 above is a 450MHz PIII, the alpha is a 500MHz PC164.   One day
} these two cards will be used for a back to back fdx private 100Mbps link
} between the two of them (that's what I acquired them for).  Once I find
} a suitable (almost certainly yanked from some other ancient box) other
} 10Mbps ether card for the alpha, isa probably, it will get that as well.
} 
} I am using 1.4, but I have compared -current sources of a few days ago,
} (maybe a week) and found no differences that could matter.
} 
} kre
} 
>-- End of excerpt from Robert Elz