From owner-freebsd-stable  Thu Jul 13 16:27:43 2000
Delivered-To: freebsd-stable@freebsd.org
Received: by hub.freebsd.org (Postfix, from userid 618)
	id A64F937BA28; Thu, 13 Jul 2000 16:27:38 -0700 (PDT)
Subject: RX problems with Macronix ethernet cards
To: freebsd-stable@freebsd.org
Date: Thu, 13 Jul 2000 16:27:38 -0700 (PDT)
X-Mailer: ELM [version 2.4ME+ PL54 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-Id: <20000713232738.A64F937BA28@hub.freebsd.org>
From: wpaul@FreeBSD.ORG (Bill Paul)
Sender: owner-freebsd-stable@FreeBSD.ORG
Precedence: bulk
X-Loop: 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


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message