Commit Graph

3 Commits

Author SHA1 Message Date
Bill Paul
1851594ca0 Remove the code that manually pads frames to at least 60 bytes;
the ASIX chip supports auto-padding.
1999-01-16 20:40:52 +00:00
Bill Paul
51b875b355 Fix some stability problems:
- Normally, the driver allocates an mbuf cluster for each receive
  descriptor. This is because we have to be prepared to accomodate up to
  1500 bytes (a cluster buffer can hold up to 2K). However, using up a
  whole cluster buffer for a tiny packet is a bit of a waste. Also,
  it seems to me that sometimes mbufs will linger in the kernel for
  a while after being passed out of the driver, which means we might
  drain the mbuf cluster pool. The cluster pool is smaller than the
  mbuf pool in general, so we do the following: if the packet is less
  that MINCLSIZE bytes, then we copy it into a small mbuf chain and
  leave the mbuf cluster in place for another go-round. This saves
  mbuf clusters in some cases while still allowing them to be used
  for heavy traffic exchanges with lots of full-sized frames.

- The transmit descriptor has a bit in the control word which allows
  the driver to request that a 'TX OK' interrupt be generated when
  a frame has been completed. Sometimes, a frame can be fragmented
  across several descriptors. The manual for the real DEC 21140A says
  that if this happens, the 'TX interrupt request' bit is only valid
  in the descriptor of the last fragment. With the ASIX chip, it seems
  the 'TX interrupt request' bit is only valid in the descriptor of
  the _first_ fragment. Actually, the manual contains conflicting
  information, but I think it's supposed to be the first fragment.
  To play it safe, set the bit in both the first and last fragment to
  be sure that we get a TX OK interrupt. Without this fix, the driver
  can sometimes be late in releasing mbufs from the transmit queue
  after transmission.
1999-01-16 06:19:38 +00:00
Bill Paul
31188d61c1 Add driver support (and man page) for PCI fast ethernet cards based
on the ASIX AX88140A chip. Update /sys/conf/files, RELNOTES.TXT,
/sys/i388/i386/userconfig.c, sysinstall/devices.c, GENERIC and LINT
accordingly.

For now, the only board that I know of that uses this chip is the
Alfa Inc. GFC2204. (Its predecessor, the GFC2202, was a DEC tulip card.)
Thanks again to Ulf for obtaining the board for me. If anyone runs
across another, please feel free to update the man page and/or the
release notes. (The same applies for the other drivers.)

FreeBSD should now have support for all of the DEC tulip workalike
chipsets currently on the market (Macronix, Lite-On, Winbond, ASIX).
And unless I'm mistaken, it should also have support for all PCI fast
ethernet chipsets in general (except maybe the SMC FEAST chip, which
nobody seems to ever use, including SMC). Now if only we could convince
3Com, Intel or whoever to cough up some documentation for gigabit
ethernet hardware.

Also updated RELNOTEX.TXT to mention that the SVEC PN102TX is supported
by the Macronix driver (assuming you actually have an SVEC PN102TX with
a Macronix chip on it; I tried to order a PN102TX once and got a box
labeled 'Hawking Technology PN102TX' that had a VIA Rhine board inside
it).
1999-01-09 18:12:08 +00:00