[tulip] Macronix tulip chip MX98715 and hash table size reduction

[Stephen Gutknecht (vw)]

In researching my selection of network cards, I came across some info from
the FreeBSD guys that might be of interest to this list.  I am sending it so
that it is at least stored in the archives....

The outcome of this message was that the July 14 2000 and later version of
the FreeBSD driver now has code to properly detect the various Macronix
chipset versions.


===========================================
From: Bill Paul <wpaul@FreeBSD.ORG> 

Ok, some of you have been reporting problems with Macronix ethernet cards
which, whether you realize it or not, are due to the chip not bring being
programmed correctly to receive broadcast packets. Normally the chip *would*
be programmed correctly, except that Macronix has come out with some new
chip revs that are slightly different from the chips on the sample cards I
have here. This is why I haven't been able to duplicate this problem
locally.
 
The real DEC 21143 tulip chip and *some* of its clones use a receive filter
programming mechanism that involves DMAing a setup frame via the transmit
DMA engine. There's more than one way to program the filter: I do it using
the "one perfect entry for the station address and multicast hash table"
method. Real DEC 21143 chips have a 512-bit hash table. Most clones have a
512-bit hash table. The older Macronix chips that I have use a 512-bit hash
table. However, the MX98715AEC-C, D and E chips have a 128-bit table, and
the MX98715BEC 3.3volt chip has only a 64-bit hash table.
 
The reason this is important is that enabling reception of broadcast frames
is done by setting the bit in the multicast hash table that corresponds to
the broadcast address. With chips that have a too-small hash table, the
correct bit is never set, and hence frames destined for the broadcast
address -- such as ARP requests -- are never received. 
 
Joy. Bliss. Down, not across.
 
Now. I already have some special-case code in if_dc in order to deal with
this issue for the LC82C115 PNIC-II chip, which has the same problem (also
only a 128-bit table). So what I need is to expand this slightly in order to
handle this newer 98715 chips. *However*, Macronix. in its infinite wisdom
(hah!) has decided to differentiate these chips based only on the stepping
bits in the PCI revision register. Even worse, the datasheets on their site
do not specify the stepping values, so I have no idea what they are.
 
This means that in order for me to fix this problem, I will need all of you
-- yes *you* -- who have Macronix 98715 cards that don't work correctly to
perform the following steps:
 
- Step 1: Make a note of the actual vendor/model number of this card.   Look
at the box/manual/windoze driver diskette/etc that came with   the card; the
information should be there somewhere. If it's a cheap   no-name card of
some kind, just say so, but if it's LinkSys, D-Link   or whatever, please
tell me.
 
- Step 2: Actually *look* at the card, with your eyeballs, and make note
of the part number on the controller chip. Macronix chips typically   say MX
or MXIC on them, and the model number will contain the string   "98715" in
it somewhere. Note however that I don't want you to tell   me that it says
98715: I already *know* that. I want to know the whole   part number, i.e.
MX98715AEC or MX98715AEC-C. DO NOT just write back   to me and say "uh...
it's a 98715" or I will hunt you down, drain the   fat from your body, make
expensive soap out of it and sell it upper   class department stores.
 
- The 3rd rule of fight club...
 
  Uhm, no. Let me try that again.
 
- Step 3: With the card(s) installed in your machine, type the following
command:
 
# pciconf -l > /tmp/pciconf.out
 
  Then send the contents of the pciconf.out file to me so I can see PCI
revision codes. If you have more than one Macronix card in your system,   be
sure and describe which card is which, i.e. if dc0 is an MX98715AEC   and
dc1 is an MX98715AEC-D, be sure to state this fact clearly. 
 
Once you have all of this information collected and formatted nicely, e-mail
it to me at wpaul@freebsd.org and I will generate a patch to if_dc so that I
can special-case these chips correctly. In the meantime, if you can't resist
the urge to fiddle a bit, try the following: 
 
- Look in /sys/pci/if_dc.c for the following code in the dc_crc_le()
function:
 
        /* The hash table on the PNIC II is only 128 bits wide. */
if (DC_IS_PNICII(sc))
                return (crc & ((1 << DC_BITS_PNIC_II) - 1)); 
 
- Comment out the test for the PNIC II, e.g.:
 
        /* The hash table on the PNIC II is only 128 bits wide. */
/* if (DC_IS_PNICII(sc)) */
                return (crc & ((1 << DC_BITS_PNIC_II) - 1)); 
 
This will force the driver to calculate the CRC value for a 128-bit hash
table.
 
Lastly, the quicker I get this information, the better, since I would like
to merge the fix into the stable branch before 4.1 goes out the door.
 
-Bill