Commit Graph

13 Commits

Author SHA1 Message Date
Bill Paul
74e5e304a4 Fix support for the PNIC II. Earlier I had assumed that the PNIC II was
similar to the PNIC I (supported by the pn driver). In fact, it's really
a Macronix 98715A with wake on LAN support added. According to LinkSys,
the PNIC II was jointly developed by Lite-On and Macronis. I get the
feeling Macronix did most of the work. (The datasheet has the Macronix
logo on it, and is in fact nearly identical to the 98715 datasheet, except
for the extra wake on LAN registers.) In any case, the PNIC II works just
fine with the Macronix driver.

The changes are:

- Move PCI ID for the PNIC II from the pn driver to the mx driver.
- Mention PNIC II support in mx.4.
- Mention PNIC II support in RELNOTES.TXT and HARDWARE.TXT.
1999-05-28 18:43:25 +00:00
Andrew Gallatin
50b8d1cce4 Allow chipset drivers to specify the direct-mapped DMA window's mask in
preparation for tsunami support.  Previous chipsets' direct-mapped DMA
mask was always 1024*1024*1024.  The Tsunami chipset needs it to be
2*1024*1024*1024

These changes should not affect the i386 port

Reviewed by:	Doug Rabson <dfr@nlsystems.com>
1999-05-26 23:01:57 +00:00
Bill Paul
727c88e9da Tweak the Macronix driver to hopefully make it more reliable:
- Change to the same transmit scheme as the PNIC driver.
- Dynamically set the cache alignment, and set burst size the same as
  the PNIC driver in mx_init().
- Enable 'store and forward' mode by default. This is the slowest option
  and it does reduce 100Mbps performance somewhat, but it's the most
  reliable setting I can find. I'm more interested in having the driver
  work reliably than trying to squeeze the best performance out of it.
  The reason I'm doing this is that on *some* systems you may see a lot
  of transmit underruns (which I can't explain: these are *fast* test
  systems) and these errors seem to cause unusual and decidedly
  non-tulip-like behavior. In normal 10Mbps mode, performance is fine
  (you can easily saturate a 10Mbps link).

Also tweak some of the other drivers:

- Increase the size of the TX ring for the Winbond, ASIX, VIA Rhine
  and PNIC drivers.
- Set a larger value for ifq_maxlen in the ThunderLAN driver. The setting
  of TL_TX_LIST_CNT - 1 is too low (the ThunderLAN driver only allocates
  20 transmit descriptors, and I don't want to fiddle with that now
  because the ThunderLAN's descriptor structure is an oddball size
  compared to the others).
1999-05-06 15:32:52 +00:00
Bill Paul
bd43efdba2 Grrr. Make all modes work properly with the 82c168 chip and built-in
transceiver. Note in the manual page that autoselection doesn't
work on the 82c168 because the built-in NWAY support is horribly
broken. Manual mode selection works fine, but autoneg is broken for
everything except maybe 10Mbps half-duplex. There's no simple way
to fix this at the moment, so I have to settle for documenting the
bug for now. Fortunately, there aren't anywhere near as many 82c168
boards around as there are 82c169s.
1999-04-14 19:40:08 +00:00
Bill Paul
ca31683853 Some more fixes:
- It turns out that the 'promiscuous mode' bug what I discovered with the
  PNIC is not restricted to promiscuous mode. I've been doing some remote
  debugging for someone with a P75 system, and at 100Mbps, the receiver
  screws up even when the NIC is in normal mode. Thus, enable the workaround
  for this bug all the time. Note that the workaround is still not enabled
  for the PNIC II, since I haven't tested one yet.

- Set the 'arbitration' bit in the bus configuration register and set the
  maximum burst size to 16 longwords. This seems to fix problems with
  transmit corruption on the P75 system mentioned above. (It probably hurts
  performance a bit too, but I've given up trying to make the PNIC perform
  well.)
1999-04-13 17:29:55 +00:00
Bill Paul
41e70f38d2 Enable the promiscuous mode workaround for the PNIC 82c168 chip, which
appears to need it.
1999-04-11 05:15:26 +00:00
Bill Paul
326acf4d96 Finally add support for the older 82c168 PNIC chip with the built-in
transceiver. Thanks to Brian Walenze for donating a NIC with this chip
on it (LinkSys didn't really sell that many of them and they're not
in production anymore). The driver now distinguishes between the
82c168 and 82c169 when probing. If no MII transceiver is detected,
it switches over to using the internal one.
1999-04-10 18:44:53 +00:00
Bill Paul
8fe2c75e31 Make the xl and pn drivers work on FreeBSD/alpha and add them to
sys/alpha/conf/GENERIC.

Note: the PNIC ignores the lower few bits of the RX buffer DMA address,
which means we have to add yet another kludge to make it happy. Since
we can't offset the packet data, we copy the first few bytes of the
received data into a separate mbuf with proper alignment. This puts
the IP header where it needs to be to prevent unaligned accesses.

Also modified the PNIC driver to use a non-interrupt driven TX
strategy. This improves performance somewhat on x86/SMP systems where
interrupt delivery doesn't seem to be as fast with an SMP kernel as
with a UP kernel.
1999-03-27 20:41:25 +00:00
Bill Paul
46d13fc612 Add PCI device ID for the PNIC II. 1999-02-26 07:50:53 +00:00
Bill Paul
6985d23298 GRRRR! Apparently, the promiscuous mode chip bug which I thought was
isolated to revision 33 PNIC chips is also present in revision 32 chips.
Cards with rev. 32 chips include the LinkSys LNE100TX and the Matrox
FastNIC 10/100. This accounts for all the cards that I have to test
with.

(I was never able to personally trip the bug on this chip rev, but today
one of the guys in the lab did it with the software they're working on
for their cellular IP project, which uses BPF and promiscuous mode
extensively.)

This commit enables the promiscuous mode software workaround code for
both revison 32 and revision 33 chips. It's possible all of the PNIC
chips suffer from this bug, but these are the only two revs where I
know for a fact it exists.
1999-01-05 00:59:08 +00:00
Bill Paul
d1b5b058f7 This commit adds a software workaround for a hardware bug in certain PNIC
chip revisions. (A buggy taiwanese chip? I'm just shocked; shocked I tell
you.) So far I have only observed the anomalous behavior on board with
PCI revision 33 chips. At the moment, this seems to include only the
Netgear FA310-TX rev D1 boards with chips labeled NGMC169B. (Possibly this
means it's an 82c169B part from Lite-On.)

The bug only manifests itself in promiscuous mode, and usually only at
10Mbps half-duplex. (I have not observed the problem in full-duplex mode,
and I don't think it ever happens at 100Mbps.) The bug appears to be in
the receiver DMA engine. Normally, the chip is programmed with a linked
list of receiver descriptors, each with a receive buffer capable of holding
a complete full-sized ethernet frame. During periods of heavy traffic
(i.e. ping -c 100 -f 8100 <otherhost>), the receiver will sometimes appear
to upload its entire FIFO memory contents instead of just uploading the
desired received frame. The uploaded data will span several receive
buffers, in spite of the fact that the chip has been told to only use
one descriptor per frame, and appears to consist of previously transmitted
frames with the correct received frame appended to the end.

Unfortunately, there is no way to determine exactly how much data is
uploaded when this happens; the chip doesn't tell you anything except the
size of the desired received frame, and the amount of bogus data varies.
Sometimes, the desired frame is also split across multiple buffers.

The workaround is ugly and nasty. The driver assembles all of the data
from the bogus frames into a single buffer. The receive buffers are always
zeroed out, and we program the chip to always include the receive CRC
at the end of each frame. We therefore know that we can start from the
end of the buffer and scan back until we encounter a non-zero data byte,
and say conclusively that this is the end of the desired frame. We can
then subtract the frame length from this address to determine the real
start of the frame, and copy it into an mbuf and pass it on.

This is kludgy and time consuming, but it's better than dropping frames.
It's not too bad since the problem only happens at 10Mbps.

The workaround is only enabled for chips with PCI revision == 33. The
LinkSys LNE100TX and Matrox FastNIC 10/100 cards use a revision 32 chip
and work fine in promiscuous mode. Netgear support has confirmed that
they "have some previous knowledge of problems in promiscuous mode" but
didn't have a workaround. The people at Lite-On who would be able to
suggest a possible fix are on vacation. So, I decided to implement a
workaround of my own until I hear from them. I suppose this problem made
it through Netgear's QA department since Windows doesn't normally use
promiscuous mode, and if Windows doesn't need the feature than it can't
possibly be important, right? Grrr.
1998-12-31 17:19:21 +00:00
Bill Paul
f52393a257 Correct the definition for PN_NETCFG_NO_RXCRC: it's 0x20000000, not
0x02000000. This error was causing the chip to always include the
ethernet CRC along with every received frame (the driver turns on
PN_NETCFG_NO_RXCRC, but it was frobbing the wrong bit).
1998-12-18 18:31:34 +00:00
Bill Paul
726ff6a158 An early Christmas present: add driver support for a whole bunch of
PCI fast ethernet adapters, plus man pages.

if_pn.c: Netgear FA310TX model D1, LinkSys LNE100TX, Matrox FastNIC 10/100,
         various other PNIC devices

if_mx.c: NDC Communications SOHOware SFA100 (Macronix 98713A), various
         other boards based on the Macronix 98713, 98713A, 98715, 98715A
         and 98725 chips

if_vr.c: D-Link DFE530-TX, other boards based on the VIA Rhine and
         Rhine II chips (note: the D-Link and certain other cards
         that actually use a Rhine II chip still return the PCI
         device ID of the Rhine I. I don't know why, and it doesn't
         really matter since the driver treats both chips the same
         anyway.)

if_wb.c: Trendware TE100-PCIE and various other cards based on the
         Winbond W89C840F chip (the Trendware card is identical to
         the sample boards Winbond sent me, so who knows how many
         clones there are running around)

All drivers include support for ifmedia, BPF and hardware multicast
filtering.

Also updated GENERIC, LINT, RELNOTES.TXT, userconfig and
sysinstall device list.

I also have a driver for the ASIX AX88140A in the works.
1998-12-04 18:01:24 +00:00