At Thu, 25 May 2000 14:52:04 -0700,
Jason R Thorpe <thorpej@zembu.com> wrote:
> The DM9102A has both HomePNA and 10/100 interfaces.  You select the
> HomePNA PHY by clearing OPMODE_PS, and the 10/100 interface by setting
> OPMODE_PS (on older DM9102 chips, you must always set OPMODE_PS).

Is this true? I guessed the meaning of OPMODE_PS the opposite from
FreeBSD's code below (/sys/pci/if_dc.c).
Also, my DM9102 (pass 1.0 as the kernel reports) seems fine with this
bit cleared.

        /*
         * If this is a Davicom DM9102A card with a DM9801 HomePNA
         * PHY and we want HomePNA mode, set the portsel bit to turn
         * on the external MII port.
         */
        if (DC_IS_DAVICOM(sc)) {
                if (IFM_SUBTYPE(media) == IFM_homePNA) {
                        DC_SETBIT(sc, DC_NETCFG, DC_NETCFG_PORTSEL);
                        sc->dc_link = 1;
                } else {
                        DC_CLRBIT(sc, DC_NETCFG, DC_NETCFG_PORTSEL);
                }
        }


>  >    Also, the receive process does not want to stop in tlp_idle while
>  >  waiting for a packet.  This doesn't seem to be a big problem since
>  >  switching between auto (at 100baseTX) and 10baseT still works while it is
>  >  running (but between 10baseT and 100baseTX does not).
> 
> Hm.  Interesting.  I wonder why the halt fails.  That's kind of annoying,
> since you're supposed to halt the receive process to load a new receive
> filter.  Oh well.  I guess I could suppress the warning on the DM9102.

I get several tlp_idle warnings (the below) at the boot time and when
expicitly switching to auto. As I didn't get these warnings when I
first replaced tlp_idle with FreeBSD's code, the idle state check code
in tlp_idle might be suspicious. 

tlp0: receive process failed to idle: state RUNNING - CHECK

--
IWAMOTO Toshihiro