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
|
|
|
/*
|
|
|
|
* Copyright (c) 1997, 1998
|
|
|
|
* Bill Paul <wpaul@ctr.columbia.edu>. All rights reserved.
|
|
|
|
*
|
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
* modification, are permitted provided that the following conditions
|
|
|
|
* are met:
|
|
|
|
* 1. Redistributions of source code must retain the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer.
|
|
|
|
* 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer in the
|
|
|
|
* documentation and/or other materials provided with the distribution.
|
|
|
|
* 3. All advertising materials mentioning features or use of this software
|
|
|
|
* must display the following acknowledgement:
|
|
|
|
* This product includes software developed by Bill Paul.
|
|
|
|
* 4. Neither the name of the author nor the names of any co-contributors
|
|
|
|
* may be used to endorse or promote products derived from this software
|
|
|
|
* without specific prior written permission.
|
|
|
|
*
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY Bill Paul AND CONTRIBUTORS ``AS IS'' AND
|
|
|
|
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
|
|
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
|
|
|
* ARE DISCLAIMED. IN NO EVENT SHALL Bill Paul OR THE VOICES IN HIS HEAD
|
|
|
|
* BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
|
|
|
|
* CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
|
|
|
|
* SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
|
|
|
|
* INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
|
|
|
|
* CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
|
|
|
|
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
|
|
|
|
* THE POSSIBILITY OF SUCH DAMAGE.
|
|
|
|
*
|
1999-08-28 01:08:13 +00:00
|
|
|
* $FreeBSD$
|
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
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* 82c168/82c169 PNIC fast ethernet PCI NIC driver
|
|
|
|
*
|
|
|
|
* Supports various network adapters based on the Lite-On PNIC
|
|
|
|
* PCI network controller chip including the LinkSys LNE100TX.
|
|
|
|
*
|
|
|
|
* Written by Bill Paul <wpaul@ctr.columbia.edu>
|
|
|
|
* Electrical Engineering Department
|
|
|
|
* Columbia University, New York City
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The PNIC chip is a DEC tulip clone. This driver uses much of the
|
|
|
|
* same code from the driver for the Winbond chip (which is also a
|
|
|
|
* tulip clone) except for the MII, EEPROM and filter programming.
|
|
|
|
*
|
|
|
|
* Technically we could merge support for this chip into the 'de'
|
|
|
|
* driver, but it's such a mess that I'm afraid to go near it.
|
|
|
|
*
|
|
|
|
* The PNIC appears to support both an external MII and an internal
|
|
|
|
* transceiver. I think most 100Mbps implementations use a PHY attached
|
|
|
|
* the the MII. The LinkSys board that I have uses a Myson MTD972
|
|
|
|
* 100BaseTX PHY.
|
|
|
|
*/
|
|
|
|
|
1999-07-06 19:23:32 +00:00
|
|
|
#include "bpf.h"
|
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
|
|
|
|
|
|
|
#include <sys/param.h>
|
|
|
|
#include <sys/systm.h>
|
|
|
|
#include <sys/sockio.h>
|
|
|
|
#include <sys/mbuf.h>
|
|
|
|
#include <sys/malloc.h>
|
|
|
|
#include <sys/kernel.h>
|
|
|
|
#include <sys/socket.h>
|
|
|
|
|
|
|
|
#include <net/if.h>
|
|
|
|
#include <net/if_arp.h>
|
|
|
|
#include <net/ethernet.h>
|
|
|
|
#include <net/if_dl.h>
|
|
|
|
#include <net/if_media.h>
|
|
|
|
|
1999-07-06 19:23:32 +00:00
|
|
|
#if NBPF > 0
|
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
|
|
|
#include <net/bpf.h>
|
|
|
|
#endif
|
|
|
|
|
1999-07-28 02:19:52 +00:00
|
|
|
#include "opt_bdg.h"
|
|
|
|
#ifdef BRIDGE
|
|
|
|
#include <net/bridge.h>
|
|
|
|
#endif
|
|
|
|
|
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
|
|
|
#include <vm/vm.h> /* for vtophys */
|
|
|
|
#include <vm/pmap.h> /* for vtophys */
|
|
|
|
#include <machine/clock.h> /* for DELAY */
|
|
|
|
#include <machine/bus_pio.h>
|
|
|
|
#include <machine/bus_memio.h>
|
|
|
|
#include <machine/bus.h>
|
1999-07-28 02:19:52 +00:00
|
|
|
#include <machine/resource.h>
|
|
|
|
#include <sys/bus.h>
|
|
|
|
#include <sys/rman.h>
|
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
|
|
|
|
|
|
|
#include <pci/pcireg.h>
|
|
|
|
#include <pci/pcivar.h>
|
|
|
|
|
|
|
|
#define PN_USEIOSPACE
|
|
|
|
|
|
|
|
/* #define PN_BACKGROUND_AUTONEG */
|
|
|
|
|
1999-04-13 17:29:55 +00:00
|
|
|
#define PN_RX_BUG_WAR
|
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
|
|
|
|
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
|
|
|
#include <pci/if_pnreg.h>
|
|
|
|
|
|
|
|
#ifndef lint
|
1998-12-07 21:58:50 +00:00
|
|
|
static const char rcsid[] =
|
1999-08-28 01:08:13 +00:00
|
|
|
"$FreeBSD$";
|
1999-04-16 21:22:55 +00:00
|
|
|
#endif
|
|
|
|
|
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
|
|
|
/*
|
|
|
|
* Various supported device vendors/types and their names.
|
|
|
|
*/
|
|
|
|
static struct pn_type pn_devs[] = {
|
|
|
|
{ PN_VENDORID, PN_DEVICEID_PNIC,
|
1999-04-10 18:44:53 +00:00
|
|
|
"82c168 PNIC 10/100BaseTX" },
|
|
|
|
{ PN_VENDORID, PN_DEVICEID_PNIC,
|
|
|
|
"82c169 PNIC 10/100BaseTX" },
|
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
|
|
|
{ 0, 0, NULL }
|
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Various supported PHY vendors/types and their names. Note that
|
|
|
|
* this driver will work with pretty much any MII-compliant PHY,
|
|
|
|
* so failure to positively identify the chip is not a fatal error.
|
|
|
|
*/
|
|
|
|
|
|
|
|
static struct pn_type pn_phys[] = {
|
|
|
|
{ TI_PHY_VENDORID, TI_PHY_10BT, "<TI ThunderLAN 10BT (internal)>" },
|
|
|
|
{ TI_PHY_VENDORID, TI_PHY_100VGPMI, "<TI TNETE211 100VG Any-LAN>" },
|
|
|
|
{ NS_PHY_VENDORID, NS_PHY_83840A, "<National Semiconductor DP83840A>"},
|
|
|
|
{ LEVEL1_PHY_VENDORID, LEVEL1_PHY_LXT970, "<Level 1 LXT970>" },
|
|
|
|
{ INTEL_PHY_VENDORID, INTEL_PHY_82555, "<Intel 82555>" },
|
|
|
|
{ SEEQ_PHY_VENDORID, SEEQ_PHY_80220, "<SEEQ 80220>" },
|
|
|
|
{ 0, 0, "<MII-compliant physical interface>" }
|
|
|
|
};
|
|
|
|
|
1999-07-28 02:19:52 +00:00
|
|
|
static int pn_probe __P((device_t));
|
|
|
|
static int pn_attach __P((device_t));
|
|
|
|
static int pn_detach __P((device_t));
|
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
|
|
|
|
|
|
|
static int pn_newbuf __P((struct pn_softc *,
|
1999-07-28 02:19:52 +00:00
|
|
|
struct pn_chain_onefrag *,
|
|
|
|
struct mbuf *));
|
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
|
|
|
static int pn_encap __P((struct pn_softc *, struct pn_chain *,
|
|
|
|
struct mbuf *));
|
|
|
|
|
1999-04-13 17:29:55 +00:00
|
|
|
#ifdef PN_RX_BUG_WAR
|
|
|
|
static void pn_rx_bug_war __P((struct pn_softc *,
|
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
|
|
|
struct pn_chain_onefrag *));
|
|
|
|
#endif
|
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
|
|
|
static void pn_rxeof __P((struct pn_softc *));
|
|
|
|
static void pn_rxeoc __P((struct pn_softc *));
|
|
|
|
static void pn_txeof __P((struct pn_softc *));
|
|
|
|
static void pn_txeoc __P((struct pn_softc *));
|
|
|
|
static void pn_intr __P((void *));
|
|
|
|
static void pn_start __P((struct ifnet *));
|
|
|
|
static int pn_ioctl __P((struct ifnet *, u_long, caddr_t));
|
|
|
|
static void pn_init __P((void *));
|
|
|
|
static void pn_stop __P((struct pn_softc *));
|
|
|
|
static void pn_watchdog __P((struct ifnet *));
|
1999-07-28 02:19:52 +00:00
|
|
|
static void pn_shutdown __P((device_t));
|
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
|
|
|
static int pn_ifmedia_upd __P((struct ifnet *));
|
|
|
|
static void pn_ifmedia_sts __P((struct ifnet *, struct ifmediareq *));
|
|
|
|
|
|
|
|
static void pn_eeprom_getword __P((struct pn_softc *, u_int8_t, u_int16_t *));
|
|
|
|
static void pn_read_eeprom __P((struct pn_softc *, caddr_t, int,
|
|
|
|
int, int));
|
|
|
|
static u_int16_t pn_phy_readreg __P((struct pn_softc *, int));
|
|
|
|
static void pn_phy_writereg __P((struct pn_softc *, u_int16_t, u_int16_t));
|
|
|
|
|
|
|
|
static void pn_autoneg_xmit __P((struct pn_softc *));
|
|
|
|
static void pn_autoneg_mii __P((struct pn_softc *, int, int));
|
|
|
|
static void pn_setmode_mii __P((struct pn_softc *, int));
|
|
|
|
static void pn_getmode_mii __P((struct pn_softc *));
|
1999-04-10 18:44:53 +00:00
|
|
|
static void pn_autoneg __P((struct pn_softc *, int, int));
|
|
|
|
static void pn_setmode __P((struct pn_softc *, int));
|
|
|
|
static void pn_setcfg __P((struct pn_softc *, u_int32_t));
|
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
|
|
|
static u_int32_t pn_calchash __P((u_int8_t *));
|
|
|
|
static void pn_setfilt __P((struct pn_softc *));
|
|
|
|
static void pn_reset __P((struct pn_softc *));
|
|
|
|
static int pn_list_rx_init __P((struct pn_softc *));
|
|
|
|
static int pn_list_tx_init __P((struct pn_softc *));
|
|
|
|
|
1999-07-28 02:19:52 +00:00
|
|
|
#ifdef PN_USEIOSPACE
|
|
|
|
#define PN_RES SYS_RES_IOPORT
|
|
|
|
#define PN_RID PN_PCI_LOIO
|
|
|
|
#else
|
|
|
|
#define PN_RES SYS_RES_MEMORY
|
|
|
|
#define PN_RID PN_PCI_LOMEM
|
|
|
|
#endif
|
|
|
|
|
|
|
|
static device_method_t pn_methods[] = {
|
|
|
|
/* Device interface */
|
|
|
|
DEVMETHOD(device_probe, pn_probe),
|
|
|
|
DEVMETHOD(device_attach, pn_attach),
|
|
|
|
DEVMETHOD(device_detach, pn_detach),
|
|
|
|
DEVMETHOD(device_shutdown, pn_shutdown),
|
|
|
|
{ 0, 0 }
|
|
|
|
};
|
|
|
|
|
|
|
|
static driver_t pn_driver = {
|
|
|
|
"pn",
|
|
|
|
pn_methods,
|
|
|
|
sizeof(struct pn_softc),
|
|
|
|
};
|
|
|
|
|
|
|
|
static devclass_t pn_devclass;
|
|
|
|
|
|
|
|
DRIVER_MODULE(pn, pci, pn_driver, pn_devclass, 0, 0);
|
|
|
|
|
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
|
|
|
#define PN_SETBIT(sc, reg, x) \
|
|
|
|
CSR_WRITE_4(sc, reg, \
|
1999-04-14 19:40:08 +00:00
|
|
|
CSR_READ_4(sc, reg) | (x))
|
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
|
|
|
|
|
|
|
#define PN_CLRBIT(sc, reg, x) \
|
|
|
|
CSR_WRITE_4(sc, reg, \
|
1999-04-14 19:40:08 +00:00
|
|
|
CSR_READ_4(sc, reg) & ~(x))
|
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
|
|
|
|
|
|
|
/*
|
|
|
|
* Read a word of data stored in the EEPROM at address 'addr.'
|
|
|
|
*/
|
|
|
|
static void pn_eeprom_getword(sc, addr, dest)
|
|
|
|
struct pn_softc *sc;
|
|
|
|
u_int8_t addr;
|
|
|
|
u_int16_t *dest;
|
|
|
|
{
|
|
|
|
register int i;
|
|
|
|
u_int32_t r;
|
|
|
|
|
|
|
|
CSR_WRITE_4(sc, PN_SIOCTL, PN_EE_READ|addr);
|
|
|
|
|
|
|
|
for (i = 0; i < PN_TIMEOUT; i++) {
|
|
|
|
DELAY(1);
|
|
|
|
r = CSR_READ_4(sc, PN_SIO);
|
|
|
|
if (!(r & PN_SIO_BUSY)) {
|
|
|
|
*dest = (u_int16_t)(r & 0x0000FFFF);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Read a sequence of words from the EEPROM.
|
|
|
|
*/
|
|
|
|
static void pn_read_eeprom(sc, dest, off, cnt, swap)
|
|
|
|
struct pn_softc *sc;
|
|
|
|
caddr_t dest;
|
|
|
|
int off;
|
|
|
|
int cnt;
|
|
|
|
int swap;
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
u_int16_t word = 0, *ptr;
|
|
|
|
|
|
|
|
for (i = 0; i < cnt; i++) {
|
|
|
|
pn_eeprom_getword(sc, off + i, &word);
|
|
|
|
ptr = (u_int16_t *)(dest + (i * 2));
|
|
|
|
if (swap)
|
|
|
|
*ptr = ntohs(word);
|
|
|
|
else
|
|
|
|
*ptr = word;
|
|
|
|
}
|
|
|
|
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
static u_int16_t pn_phy_readreg(sc, reg)
|
|
|
|
struct pn_softc *sc;
|
|
|
|
int reg;
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
u_int32_t rval;
|
|
|
|
|
|
|
|
CSR_WRITE_4(sc, PN_MII,
|
|
|
|
PN_MII_READ | (sc->pn_phy_addr << 23) | (reg << 18));
|
|
|
|
|
|
|
|
for (i = 0; i < PN_TIMEOUT; i++) {
|
|
|
|
DELAY(1);
|
|
|
|
rval = CSR_READ_4(sc, PN_MII);
|
|
|
|
if (!(rval & PN_MII_BUSY)) {
|
|
|
|
if ((u_int16_t)(rval & 0x0000FFFF) == 0xFFFF)
|
|
|
|
return(0);
|
|
|
|
else
|
|
|
|
return((u_int16_t)(rval & 0x0000FFFF));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return(0);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void pn_phy_writereg(sc, reg, data)
|
|
|
|
struct pn_softc *sc;
|
|
|
|
u_int16_t reg;
|
|
|
|
u_int16_t data;
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
CSR_WRITE_4(sc, PN_MII,
|
|
|
|
PN_MII_WRITE | (sc->pn_phy_addr << 23) | (reg << 18) | data);
|
|
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < PN_TIMEOUT; i++) {
|
|
|
|
if (!(CSR_READ_4(sc, PN_MII) & PN_MII_BUSY))
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
#define PN_POLY 0xEDB88320
|
|
|
|
#define PN_BITS 9
|
|
|
|
|
|
|
|
static u_int32_t pn_calchash(addr)
|
|
|
|
u_int8_t *addr;
|
|
|
|
{
|
|
|
|
u_int32_t idx, bit, data, crc;
|
|
|
|
|
|
|
|
/* Compute CRC for the address value. */
|
|
|
|
crc = 0xFFFFFFFF; /* initial value */
|
|
|
|
|
|
|
|
for (idx = 0; idx < 6; idx++) {
|
|
|
|
for (data = *addr++, bit = 0; bit < 8; bit++, data >>= 1)
|
|
|
|
crc = (crc >> 1) ^ (((crc ^ data) & 1) ? PN_POLY : 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
return (crc & ((1 << PN_BITS) - 1));
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Initiate an autonegotiation session.
|
|
|
|
*/
|
|
|
|
static void pn_autoneg_xmit(sc)
|
|
|
|
struct pn_softc *sc;
|
|
|
|
{
|
|
|
|
u_int16_t phy_sts;
|
|
|
|
|
|
|
|
pn_phy_writereg(sc, PHY_BMCR, PHY_BMCR_RESET);
|
|
|
|
DELAY(500);
|
|
|
|
while(pn_phy_readreg(sc, PHY_BMCR)
|
|
|
|
& PHY_BMCR_RESET);
|
|
|
|
|
|
|
|
phy_sts = pn_phy_readreg(sc, PHY_BMCR);
|
|
|
|
phy_sts |= PHY_BMCR_AUTONEGENBL|PHY_BMCR_AUTONEGRSTR;
|
|
|
|
pn_phy_writereg(sc, PHY_BMCR, phy_sts);
|
|
|
|
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Invoke autonegotiation on a PHY.
|
|
|
|
*/
|
|
|
|
static void pn_autoneg_mii(sc, flag, verbose)
|
|
|
|
struct pn_softc *sc;
|
|
|
|
int flag;
|
|
|
|
int verbose;
|
|
|
|
{
|
|
|
|
u_int16_t phy_sts = 0, media, advert, ability;
|
|
|
|
struct ifnet *ifp;
|
|
|
|
struct ifmedia *ifm;
|
|
|
|
|
|
|
|
ifm = &sc->ifmedia;
|
|
|
|
ifp = &sc->arpcom.ac_if;
|
|
|
|
|
|
|
|
ifm->ifm_media = IFM_ETHER | IFM_AUTO;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The 100baseT4 PHY on the 3c905-T4 has the 'autoneg supported'
|
|
|
|
* bit cleared in the status register, but has the 'autoneg enabled'
|
|
|
|
* bit set in the control register. This is a contradiction, and
|
|
|
|
* I'm not sure how to handle it. If you want to force an attempt
|
|
|
|
* to autoneg for 100baseT4 PHYs, #define FORCE_AUTONEG_TFOUR
|
|
|
|
* and see what happens.
|
|
|
|
*/
|
|
|
|
#ifndef FORCE_AUTONEG_TFOUR
|
|
|
|
/*
|
|
|
|
* First, see if autoneg is supported. If not, there's
|
|
|
|
* no point in continuing.
|
|
|
|
*/
|
|
|
|
phy_sts = pn_phy_readreg(sc, PHY_BMSR);
|
|
|
|
if (!(phy_sts & PHY_BMSR_CANAUTONEG)) {
|
|
|
|
if (verbose)
|
|
|
|
printf("pn%d: autonegotiation not supported\n",
|
|
|
|
sc->pn_unit);
|
|
|
|
ifm->ifm_media = IFM_ETHER|IFM_10_T|IFM_HDX;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
switch (flag) {
|
|
|
|
case PN_FLAG_FORCEDELAY:
|
|
|
|
/*
|
|
|
|
* XXX Never use this option anywhere but in the probe
|
|
|
|
* routine: making the kernel stop dead in its tracks
|
|
|
|
* for three whole seconds after we've gone multi-user
|
|
|
|
* is really bad manners.
|
|
|
|
*/
|
|
|
|
pn_autoneg_xmit(sc);
|
|
|
|
DELAY(5000000);
|
|
|
|
break;
|
|
|
|
case PN_FLAG_SCHEDDELAY:
|
|
|
|
/*
|
|
|
|
* Wait for the transmitter to go idle before starting
|
|
|
|
* an autoneg session, otherwise pn_start() may clobber
|
|
|
|
* our timeout, and we don't want to allow transmission
|
|
|
|
* during an autoneg session since that can screw it up.
|
|
|
|
*/
|
|
|
|
if (sc->pn_cdata.pn_tx_head != NULL) {
|
|
|
|
sc->pn_want_auto = 1;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
pn_autoneg_xmit(sc);
|
|
|
|
ifp->if_timer = 5;
|
|
|
|
sc->pn_autoneg = 1;
|
|
|
|
sc->pn_want_auto = 0;
|
|
|
|
return;
|
|
|
|
break;
|
|
|
|
case PN_FLAG_DELAYTIMEO:
|
|
|
|
ifp->if_timer = 0;
|
|
|
|
sc->pn_autoneg = 0;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
printf("pn%d: invalid autoneg flag: %d\n", sc->pn_unit, flag);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (pn_phy_readreg(sc, PHY_BMSR) & PHY_BMSR_AUTONEGCOMP) {
|
|
|
|
if (verbose)
|
|
|
|
printf("pn%d: autoneg complete, ", sc->pn_unit);
|
|
|
|
phy_sts = pn_phy_readreg(sc, PHY_BMSR);
|
|
|
|
} else {
|
|
|
|
if (verbose)
|
|
|
|
printf("pn%d: autoneg not complete, ", sc->pn_unit);
|
|
|
|
}
|
|
|
|
|
|
|
|
media = pn_phy_readreg(sc, PHY_BMCR);
|
|
|
|
|
|
|
|
/* Link is good. Report modes and set duplex mode. */
|
|
|
|
if (pn_phy_readreg(sc, PHY_BMSR) & PHY_BMSR_LINKSTAT) {
|
|
|
|
if (verbose)
|
|
|
|
printf("link status good ");
|
|
|
|
advert = pn_phy_readreg(sc, PHY_ANAR);
|
|
|
|
ability = pn_phy_readreg(sc, PHY_LPAR);
|
|
|
|
|
|
|
|
if (advert & PHY_ANAR_100BT4 && ability & PHY_ANAR_100BT4) {
|
|
|
|
ifm->ifm_media = IFM_ETHER|IFM_100_T4;
|
|
|
|
media |= PHY_BMCR_SPEEDSEL;
|
|
|
|
media &= ~PHY_BMCR_DUPLEX;
|
|
|
|
printf("(100baseT4)\n");
|
|
|
|
} else if (advert & PHY_ANAR_100BTXFULL &&
|
|
|
|
ability & PHY_ANAR_100BTXFULL) {
|
|
|
|
ifm->ifm_media = IFM_ETHER|IFM_100_TX|IFM_FDX;
|
|
|
|
media |= PHY_BMCR_SPEEDSEL;
|
|
|
|
media |= PHY_BMCR_DUPLEX;
|
|
|
|
printf("(full-duplex, 100Mbps)\n");
|
|
|
|
} else if (advert & PHY_ANAR_100BTXHALF &&
|
|
|
|
ability & PHY_ANAR_100BTXHALF) {
|
|
|
|
ifm->ifm_media = IFM_ETHER|IFM_100_TX|IFM_HDX;
|
|
|
|
media |= PHY_BMCR_SPEEDSEL;
|
|
|
|
media &= ~PHY_BMCR_DUPLEX;
|
|
|
|
printf("(half-duplex, 100Mbps)\n");
|
|
|
|
} else if (advert & PHY_ANAR_10BTFULL &&
|
|
|
|
ability & PHY_ANAR_10BTFULL) {
|
|
|
|
ifm->ifm_media = IFM_ETHER|IFM_10_T|IFM_FDX;
|
|
|
|
media &= ~PHY_BMCR_SPEEDSEL;
|
|
|
|
media |= PHY_BMCR_DUPLEX;
|
|
|
|
printf("(full-duplex, 10Mbps)\n");
|
|
|
|
} else if (advert & PHY_ANAR_10BTHALF &&
|
|
|
|
ability & PHY_ANAR_10BTHALF) {
|
|
|
|
ifm->ifm_media = IFM_ETHER|IFM_10_T|IFM_HDX;
|
|
|
|
media &= ~PHY_BMCR_SPEEDSEL;
|
|
|
|
media &= ~PHY_BMCR_DUPLEX;
|
|
|
|
printf("(half-duplex, 10Mbps)\n");
|
|
|
|
}
|
|
|
|
|
|
|
|
media &= ~PHY_BMCR_AUTONEGENBL;
|
|
|
|
|
|
|
|
/* Set ASIC's duplex mode to match the PHY. */
|
1999-04-10 18:44:53 +00:00
|
|
|
pn_setcfg(sc, ifm->ifm_media);
|
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
|
|
|
pn_phy_writereg(sc, PHY_BMCR, media);
|
|
|
|
} else {
|
|
|
|
if (verbose)
|
|
|
|
printf("no carrier\n");
|
|
|
|
}
|
|
|
|
|
|
|
|
pn_init(sc);
|
|
|
|
|
|
|
|
if (sc->pn_tx_pend) {
|
|
|
|
sc->pn_autoneg = 0;
|
|
|
|
sc->pn_tx_pend = 0;
|
|
|
|
pn_start(ifp);
|
|
|
|
}
|
|
|
|
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void pn_getmode_mii(sc)
|
|
|
|
struct pn_softc *sc;
|
|
|
|
{
|
|
|
|
u_int16_t bmsr;
|
|
|
|
struct ifnet *ifp;
|
|
|
|
|
|
|
|
ifp = &sc->arpcom.ac_if;
|
|
|
|
|
|
|
|
bmsr = pn_phy_readreg(sc, PHY_BMSR);
|
|
|
|
if (bootverbose)
|
|
|
|
printf("pn%d: PHY status word: %x\n", sc->pn_unit, bmsr);
|
|
|
|
|
|
|
|
/* fallback */
|
|
|
|
sc->ifmedia.ifm_media = IFM_ETHER|IFM_10_T|IFM_HDX;
|
|
|
|
|
|
|
|
if (bmsr & PHY_BMSR_10BTHALF) {
|
|
|
|
if (bootverbose)
|
|
|
|
printf("pn%d: 10Mbps half-duplex mode supported\n",
|
|
|
|
sc->pn_unit);
|
|
|
|
ifmedia_add(&sc->ifmedia,
|
|
|
|
IFM_ETHER|IFM_10_T|IFM_HDX, 0, NULL);
|
|
|
|
ifmedia_add(&sc->ifmedia, IFM_ETHER|IFM_10_T, 0, NULL);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (bmsr & PHY_BMSR_10BTFULL) {
|
|
|
|
if (bootverbose)
|
|
|
|
printf("pn%d: 10Mbps full-duplex mode supported\n",
|
|
|
|
sc->pn_unit);
|
|
|
|
ifmedia_add(&sc->ifmedia,
|
|
|
|
IFM_ETHER|IFM_10_T|IFM_FDX, 0, NULL);
|
|
|
|
sc->ifmedia.ifm_media = IFM_ETHER|IFM_10_T|IFM_FDX;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (bmsr & PHY_BMSR_100BTXHALF) {
|
|
|
|
if (bootverbose)
|
|
|
|
printf("pn%d: 100Mbps half-duplex mode supported\n",
|
|
|
|
sc->pn_unit);
|
|
|
|
ifp->if_baudrate = 100000000;
|
|
|
|
ifmedia_add(&sc->ifmedia, IFM_ETHER|IFM_100_TX, 0, NULL);
|
|
|
|
ifmedia_add(&sc->ifmedia,
|
|
|
|
IFM_ETHER|IFM_100_TX|IFM_HDX, 0, NULL);
|
|
|
|
sc->ifmedia.ifm_media = IFM_ETHER|IFM_100_TX|IFM_HDX;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (bmsr & PHY_BMSR_100BTXFULL) {
|
|
|
|
if (bootverbose)
|
|
|
|
printf("pn%d: 100Mbps full-duplex mode supported\n",
|
|
|
|
sc->pn_unit);
|
|
|
|
ifp->if_baudrate = 100000000;
|
|
|
|
ifmedia_add(&sc->ifmedia,
|
|
|
|
IFM_ETHER|IFM_100_TX|IFM_FDX, 0, NULL);
|
|
|
|
sc->ifmedia.ifm_media = IFM_ETHER|IFM_100_TX|IFM_FDX;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Some also support 100BaseT4. */
|
|
|
|
if (bmsr & PHY_BMSR_100BT4) {
|
|
|
|
if (bootverbose)
|
|
|
|
printf("pn%d: 100baseT4 mode supported\n", sc->pn_unit);
|
|
|
|
ifp->if_baudrate = 100000000;
|
|
|
|
ifmedia_add(&sc->ifmedia, IFM_ETHER|IFM_100_T4, 0, NULL);
|
|
|
|
sc->ifmedia.ifm_media = IFM_ETHER|IFM_100_T4;
|
|
|
|
#ifdef FORCE_AUTONEG_TFOUR
|
|
|
|
if (bootverbose)
|
|
|
|
printf("pn%d: forcing on autoneg support for BT4\n",
|
|
|
|
sc->pn_unit);
|
|
|
|
ifmedia_add(&sc->ifmedia, IFM_ETHER|IFM_AUTO, 0 NULL):
|
|
|
|
sc->ifmedia.ifm_media = IFM_ETHER|IFM_AUTO;
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
|
|
|
if (bmsr & PHY_BMSR_CANAUTONEG) {
|
|
|
|
if (bootverbose)
|
|
|
|
printf("pn%d: autoneg supported\n", sc->pn_unit);
|
|
|
|
ifmedia_add(&sc->ifmedia, IFM_ETHER|IFM_AUTO, 0, NULL);
|
|
|
|
sc->ifmedia.ifm_media = IFM_ETHER|IFM_AUTO;
|
|
|
|
}
|
|
|
|
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
1999-04-10 18:44:53 +00:00
|
|
|
static void pn_autoneg(sc, flag, verbose)
|
|
|
|
struct pn_softc *sc;
|
|
|
|
int flag;
|
|
|
|
int verbose;
|
|
|
|
{
|
|
|
|
u_int32_t nway = 0, ability;
|
|
|
|
struct ifnet *ifp;
|
|
|
|
struct ifmedia *ifm;
|
|
|
|
|
|
|
|
ifm = &sc->ifmedia;
|
|
|
|
ifp = &sc->arpcom.ac_if;
|
|
|
|
|
|
|
|
ifm->ifm_media = IFM_ETHER | IFM_AUTO;
|
|
|
|
|
|
|
|
switch (flag) {
|
|
|
|
case PN_FLAG_FORCEDELAY:
|
|
|
|
/*
|
|
|
|
* XXX Never use this option anywhere but in the probe
|
|
|
|
* routine: making the kernel stop dead in its tracks
|
|
|
|
* for three whole seconds after we've gone multi-user
|
|
|
|
* is really bad manners.
|
|
|
|
*/
|
|
|
|
CSR_WRITE_4(sc, PN_GEN,
|
|
|
|
PN_GEN_MUSTBEONE|PN_GEN_100TX_LOOP);
|
|
|
|
PN_CLRBIT(sc, PN_NWAY, PN_NWAY_AUTONEGRSTR);
|
|
|
|
PN_SETBIT(sc, PN_NWAY, PN_NWAY_AUTOENB);
|
|
|
|
DELAY(5000000);
|
|
|
|
break;
|
|
|
|
case PN_FLAG_SCHEDDELAY:
|
|
|
|
/*
|
|
|
|
* Wait for the transmitter to go idle before starting
|
|
|
|
* an autoneg session, otherwise pn_start() may clobber
|
|
|
|
* our timeout, and we don't want to allow transmission
|
|
|
|
* during an autoneg session since that can screw it up.
|
|
|
|
*/
|
|
|
|
if (sc->pn_cdata.pn_tx_head != NULL) {
|
|
|
|
sc->pn_want_auto = 1;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
CSR_WRITE_4(sc, PN_GEN,
|
|
|
|
PN_GEN_MUSTBEONE|PN_GEN_100TX_LOOP);
|
|
|
|
PN_CLRBIT(sc, PN_NWAY, PN_NWAY_AUTONEGRSTR);
|
|
|
|
PN_SETBIT(sc, PN_NWAY, PN_NWAY_AUTOENB);
|
|
|
|
ifp->if_timer = 5;
|
|
|
|
sc->pn_autoneg = 1;
|
|
|
|
sc->pn_want_auto = 0;
|
|
|
|
return;
|
|
|
|
break;
|
|
|
|
case PN_FLAG_DELAYTIMEO:
|
|
|
|
ifp->if_timer = 0;
|
|
|
|
sc->pn_autoneg = 0;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
printf("pn%d: invalid autoneg flag: %d\n", sc->pn_unit, flag);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (CSR_READ_4(sc, PN_NWAY) & PN_NWAY_LPAR) {
|
|
|
|
if (verbose)
|
|
|
|
printf("pn%d: autoneg complete, ", sc->pn_unit);
|
|
|
|
} else {
|
|
|
|
if (verbose)
|
|
|
|
printf("pn%d: autoneg not complete, ", sc->pn_unit);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Link is good. Report modes and set duplex mode. */
|
|
|
|
if (CSR_READ_4(sc, PN_ISR) & PN_ISR_LINKPASS) {
|
|
|
|
if (verbose)
|
|
|
|
printf("link status good ");
|
|
|
|
|
|
|
|
ability = CSR_READ_4(sc, PN_NWAY);
|
|
|
|
if (ability & PN_NWAY_LPAR100T4) {
|
|
|
|
ifm->ifm_media = IFM_ETHER|IFM_100_T4;
|
|
|
|
nway = PN_NWAY_MODE_100T4;
|
|
|
|
printf("(100baseT4)\n");
|
|
|
|
} else if (ability & PN_NWAY_LPAR100FULL) {
|
|
|
|
ifm->ifm_media = IFM_ETHER|IFM_100_TX|IFM_FDX;
|
|
|
|
nway = PN_NWAY_MODE_100FD;
|
|
|
|
printf("(full-duplex, 100Mbps)\n");
|
|
|
|
} else if (ability & PN_NWAY_LPAR100HALF) {
|
|
|
|
ifm->ifm_media = IFM_ETHER|IFM_100_TX|IFM_HDX;
|
|
|
|
nway = PN_NWAY_MODE_100HD;
|
|
|
|
printf("(half-duplex, 100Mbps)\n");
|
|
|
|
} else if (ability & PN_NWAY_LPAR10FULL) {
|
|
|
|
ifm->ifm_media = IFM_ETHER|IFM_10_T|IFM_FDX;
|
|
|
|
nway = PN_NWAY_MODE_10FD;
|
|
|
|
printf("(full-duplex, 10Mbps)\n");
|
|
|
|
} else if (ability & PN_NWAY_LPAR10HALF) {
|
|
|
|
ifm->ifm_media = IFM_ETHER|IFM_10_T|IFM_HDX;
|
|
|
|
nway = PN_NWAY_MODE_10HD;
|
|
|
|
printf("(half-duplex, 10Mbps)\n");
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Set ASIC's duplex mode to match the PHY. */
|
|
|
|
pn_setcfg(sc, ifm->ifm_media);
|
|
|
|
CSR_WRITE_4(sc, PN_NWAY, nway);
|
|
|
|
} else {
|
|
|
|
if (verbose)
|
|
|
|
printf("no carrier\n");
|
|
|
|
}
|
|
|
|
|
|
|
|
pn_init(sc);
|
|
|
|
|
|
|
|
if (sc->pn_tx_pend) {
|
|
|
|
sc->pn_autoneg = 0;
|
|
|
|
sc->pn_tx_pend = 0;
|
|
|
|
pn_start(ifp);
|
|
|
|
}
|
|
|
|
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void pn_setmode(sc, media)
|
|
|
|
struct pn_softc *sc;
|
|
|
|
int media;
|
|
|
|
{
|
|
|
|
struct ifnet *ifp;
|
|
|
|
|
|
|
|
ifp = &sc->arpcom.ac_if;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If an autoneg session is in progress, stop it.
|
|
|
|
*/
|
|
|
|
if (sc->pn_autoneg) {
|
|
|
|
printf("pn%d: canceling autoneg session\n", sc->pn_unit);
|
|
|
|
ifp->if_timer = sc->pn_autoneg = sc->pn_want_auto = 0;
|
|
|
|
PN_CLRBIT(sc, PN_NWAY, PN_NWAY_AUTONEGRSTR);
|
|
|
|
}
|
|
|
|
|
|
|
|
printf("pn%d: selecting NWAY, ", sc->pn_unit);
|
|
|
|
|
|
|
|
if (IFM_SUBTYPE(media) == IFM_100_T4) {
|
|
|
|
printf("100Mbps/T4, half-duplex\n");
|
|
|
|
}
|
|
|
|
|
|
|
|
if (IFM_SUBTYPE(media) == IFM_100_TX) {
|
|
|
|
printf("100Mbps, ");
|
|
|
|
}
|
|
|
|
|
|
|
|
if (IFM_SUBTYPE(media) == IFM_10_T) {
|
|
|
|
printf("10Mbps, ");
|
|
|
|
}
|
|
|
|
|
|
|
|
if ((media & IFM_GMASK) == IFM_FDX) {
|
|
|
|
printf("full duplex\n");
|
|
|
|
} else {
|
|
|
|
printf("half duplex\n");
|
|
|
|
}
|
|
|
|
|
|
|
|
pn_setcfg(sc, media);
|
|
|
|
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
static void pn_setmode_mii(sc, media)
|
|
|
|
struct pn_softc *sc;
|
|
|
|
int media;
|
|
|
|
{
|
|
|
|
u_int16_t bmcr;
|
|
|
|
struct ifnet *ifp;
|
|
|
|
|
|
|
|
ifp = &sc->arpcom.ac_if;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If an autoneg session is in progress, stop it.
|
|
|
|
*/
|
|
|
|
if (sc->pn_autoneg) {
|
|
|
|
printf("pn%d: canceling autoneg session\n", sc->pn_unit);
|
|
|
|
ifp->if_timer = sc->pn_autoneg = sc->pn_want_auto = 0;
|
|
|
|
bmcr = pn_phy_readreg(sc, PHY_BMCR);
|
|
|
|
bmcr &= ~PHY_BMCR_AUTONEGENBL;
|
|
|
|
pn_phy_writereg(sc, PHY_BMCR, bmcr);
|
|
|
|
}
|
|
|
|
|
|
|
|
printf("pn%d: selecting MII, ", sc->pn_unit);
|
|
|
|
|
|
|
|
bmcr = pn_phy_readreg(sc, PHY_BMCR);
|
|
|
|
|
|
|
|
bmcr &= ~(PHY_BMCR_AUTONEGENBL|PHY_BMCR_SPEEDSEL|
|
|
|
|
PHY_BMCR_DUPLEX|PHY_BMCR_LOOPBK);
|
|
|
|
|
|
|
|
if (IFM_SUBTYPE(media) == IFM_100_T4) {
|
|
|
|
printf("100Mbps/T4, half-duplex\n");
|
|
|
|
bmcr |= PHY_BMCR_SPEEDSEL;
|
|
|
|
bmcr &= ~PHY_BMCR_DUPLEX;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (IFM_SUBTYPE(media) == IFM_100_TX) {
|
|
|
|
printf("100Mbps, ");
|
|
|
|
bmcr |= PHY_BMCR_SPEEDSEL;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (IFM_SUBTYPE(media) == IFM_10_T) {
|
|
|
|
printf("10Mbps, ");
|
|
|
|
bmcr &= ~PHY_BMCR_SPEEDSEL;
|
|
|
|
}
|
|
|
|
|
|
|
|
if ((media & IFM_GMASK) == IFM_FDX) {
|
|
|
|
printf("full duplex\n");
|
|
|
|
bmcr |= PHY_BMCR_DUPLEX;
|
|
|
|
} else {
|
|
|
|
printf("half duplex\n");
|
|
|
|
bmcr &= ~PHY_BMCR_DUPLEX;
|
|
|
|
}
|
|
|
|
|
1999-04-10 18:44:53 +00:00
|
|
|
pn_setcfg(sc, media);
|
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
|
|
|
pn_phy_writereg(sc, PHY_BMCR, bmcr);
|
|
|
|
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Programming the receiver filter on the tulip/PNIC is gross. You
|
|
|
|
* have to construct a special setup frame and download it to the
|
|
|
|
* chip via the transmit DMA engine. This routine is also somewhat
|
|
|
|
* gross, as the setup frame is sent synchronously rather than putting
|
|
|
|
* on the transmit queue. The transmitter has to be stopped, then we
|
|
|
|
* can download the frame and wait for the 'owned' bit to clear.
|
|
|
|
*
|
|
|
|
* We always program the chip using 'hash perfect' mode, i.e. one perfect
|
|
|
|
* address (our node address) and a 512-bit hash filter for multicast
|
|
|
|
* frames. We also sneak the broadcast address into the hash filter since
|
|
|
|
* we need that too.
|
|
|
|
*/
|
|
|
|
void pn_setfilt(sc)
|
|
|
|
struct pn_softc *sc;
|
|
|
|
{
|
|
|
|
struct pn_desc *sframe;
|
|
|
|
u_int32_t h, *sp;
|
|
|
|
struct ifmultiaddr *ifma;
|
|
|
|
struct ifnet *ifp;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
ifp = &sc->arpcom.ac_if;
|
|
|
|
|
|
|
|
PN_CLRBIT(sc, PN_NETCFG, PN_NETCFG_TX_ON);
|
|
|
|
PN_SETBIT(sc, PN_ISR, PN_ISR_TX_IDLE);
|
|
|
|
|
|
|
|
sframe = &sc->pn_cdata.pn_sframe;
|
|
|
|
sp = (u_int32_t *)&sc->pn_cdata.pn_sbuf;
|
|
|
|
bzero((char *)sp, PN_SFRAME_LEN);
|
|
|
|
|
|
|
|
sframe->pn_status = PN_TXSTAT_OWN;
|
|
|
|
sframe->pn_next = vtophys(&sc->pn_ldata->pn_tx_list[0]);
|
|
|
|
sframe->pn_data = vtophys(&sc->pn_cdata.pn_sbuf);
|
|
|
|
sframe->pn_ctl = PN_SFRAME_LEN | PN_TXCTL_TLINK |
|
|
|
|
PN_TXCTL_SETUP | PN_FILTER_HASHPERF;
|
|
|
|
|
|
|
|
/* If we want promiscuous mode, set the allframes bit. */
|
|
|
|
if (ifp->if_flags & IFF_PROMISC)
|
|
|
|
PN_SETBIT(sc, PN_NETCFG, PN_NETCFG_RX_PROMISC);
|
|
|
|
else
|
|
|
|
PN_CLRBIT(sc, PN_NETCFG, PN_NETCFG_RX_PROMISC);
|
|
|
|
|
|
|
|
if (ifp->if_flags & IFF_ALLMULTI)
|
|
|
|
PN_SETBIT(sc, PN_NETCFG, PN_NETCFG_RX_ALLMULTI);
|
|
|
|
|
|
|
|
for (ifma = ifp->if_multiaddrs.lh_first; ifma != NULL;
|
|
|
|
ifma = ifma->ifma_link.le_next) {
|
|
|
|
if (ifma->ifma_addr->sa_family != AF_LINK)
|
|
|
|
continue;
|
|
|
|
h = pn_calchash(LLADDR((struct sockaddr_dl *)ifma->ifma_addr));
|
|
|
|
sp[h >> 4] |= 1 << (h & 0xF);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (ifp->if_flags & IFF_BROADCAST) {
|
|
|
|
h = pn_calchash(etherbroadcastaddr);
|
|
|
|
sp[h >> 4] |= 1 << (h & 0xF);
|
|
|
|
}
|
|
|
|
|
|
|
|
sp[39] = ((u_int16_t *)sc->arpcom.ac_enaddr)[0];
|
|
|
|
sp[40] = ((u_int16_t *)sc->arpcom.ac_enaddr)[1];
|
|
|
|
sp[41] = ((u_int16_t *)sc->arpcom.ac_enaddr)[2];
|
|
|
|
|
|
|
|
CSR_WRITE_4(sc, PN_TXADDR, vtophys(sframe));
|
|
|
|
PN_SETBIT(sc, PN_NETCFG, PN_NETCFG_TX_ON);
|
|
|
|
CSR_WRITE_4(sc, PN_TXSTART, 0xFFFFFFFF);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Wait for chip to clear the 'own' bit.
|
|
|
|
*/
|
|
|
|
for (i = 0; i < PN_TIMEOUT; i++) {
|
|
|
|
DELAY(10);
|
|
|
|
if (sframe->pn_status != PN_TXSTAT_OWN)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (i == PN_TIMEOUT)
|
|
|
|
printf("pn%d: failed to send setup frame\n", sc->pn_unit);
|
|
|
|
|
|
|
|
PN_SETBIT(sc, PN_ISR, PN_ISR_TX_NOBUF|PN_ISR_TX_IDLE);
|
|
|
|
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* In order to fiddle with the
|
|
|
|
* 'full-duplex' and '100Mbps' bits in the netconfig register, we
|
|
|
|
* first have to put the transmit and/or receive logic in the idle state.
|
|
|
|
*/
|
1999-04-10 18:44:53 +00:00
|
|
|
static void pn_setcfg(sc, media)
|
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
|
|
|
struct pn_softc *sc;
|
1999-04-10 18:44:53 +00:00
|
|
|
u_int32_t media;
|
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
|
|
|
{
|
|
|
|
int i, restart = 0;
|
|
|
|
|
|
|
|
if (CSR_READ_4(sc, PN_NETCFG) & (PN_NETCFG_TX_ON|PN_NETCFG_RX_ON)) {
|
|
|
|
restart = 1;
|
|
|
|
PN_CLRBIT(sc, PN_NETCFG, (PN_NETCFG_TX_ON|PN_NETCFG_RX_ON));
|
|
|
|
|
|
|
|
for (i = 0; i < PN_TIMEOUT; i++) {
|
|
|
|
DELAY(10);
|
|
|
|
if ((CSR_READ_4(sc, PN_ISR) & PN_ISR_TX_IDLE) &&
|
|
|
|
(CSR_READ_4(sc, PN_ISR) & PN_ISR_RX_IDLE))
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (i == PN_TIMEOUT)
|
|
|
|
printf("pn%d: failed to force tx and "
|
|
|
|
"rx to idle state\n", sc->pn_unit);
|
|
|
|
|
|
|
|
}
|
|
|
|
|
1999-04-10 18:44:53 +00:00
|
|
|
if (IFM_SUBTYPE(media) == IFM_100_TX) {
|
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
|
|
|
PN_CLRBIT(sc, PN_NETCFG, PN_NETCFG_SPEEDSEL);
|
1999-04-14 19:40:08 +00:00
|
|
|
if (sc->pn_pinfo == NULL) {
|
1999-04-12 21:13:12 +00:00
|
|
|
CSR_WRITE_4(sc, PN_GEN, PN_GEN_MUSTBEONE|
|
|
|
|
PN_GEN_SPEEDSEL|PN_GEN_100TX_LOOP);
|
1999-04-14 19:40:08 +00:00
|
|
|
PN_SETBIT(sc, PN_NETCFG, PN_NETCFG_PCS|
|
|
|
|
PN_NETCFG_SCRAMBLER|PN_NETCFG_MIIENB);
|
|
|
|
PN_SETBIT(sc, PN_NWAY, PN_NWAY_SPEEDSEL);
|
|
|
|
}
|
1999-04-10 18:44:53 +00:00
|
|
|
} else {
|
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
|
|
|
PN_SETBIT(sc, PN_NETCFG, PN_NETCFG_SPEEDSEL);
|
1999-04-14 19:40:08 +00:00
|
|
|
if (sc->pn_pinfo == NULL) {
|
1999-04-12 21:13:12 +00:00
|
|
|
CSR_WRITE_4(sc, PN_GEN,
|
|
|
|
PN_GEN_MUSTBEONE|PN_GEN_100TX_LOOP);
|
1999-04-14 19:40:08 +00:00
|
|
|
PN_CLRBIT(sc, PN_NETCFG, PN_NETCFG_PCS|
|
|
|
|
PN_NETCFG_SCRAMBLER|PN_NETCFG_MIIENB);
|
|
|
|
PN_CLRBIT(sc, PN_NWAY, PN_NWAY_SPEEDSEL);
|
|
|
|
}
|
1999-04-10 18:44:53 +00:00
|
|
|
}
|
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
|
|
|
|
1999-04-14 19:40:08 +00:00
|
|
|
if ((media & IFM_GMASK) == IFM_FDX) {
|
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
|
|
|
PN_SETBIT(sc, PN_NETCFG, PN_NETCFG_FULLDUPLEX);
|
1999-04-14 19:40:08 +00:00
|
|
|
if (sc->pn_pinfo == NULL)
|
|
|
|
PN_SETBIT(sc, PN_NWAY, PN_NWAY_DUPLEX);
|
|
|
|
} else {
|
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
|
|
|
PN_CLRBIT(sc, PN_NETCFG, PN_NETCFG_FULLDUPLEX);
|
1999-04-14 19:40:08 +00:00
|
|
|
if (sc->pn_pinfo == NULL)
|
|
|
|
PN_CLRBIT(sc, PN_NWAY, PN_NWAY_DUPLEX);
|
|
|
|
}
|
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
|
|
|
|
|
|
|
if (restart)
|
|
|
|
PN_SETBIT(sc, PN_NETCFG, PN_NETCFG_TX_ON|PN_NETCFG_RX_ON);
|
|
|
|
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void pn_reset(sc)
|
|
|
|
struct pn_softc *sc;
|
|
|
|
{
|
|
|
|
register int i;
|
|
|
|
|
|
|
|
PN_SETBIT(sc, PN_BUSCTL, PN_BUSCTL_RESET);
|
|
|
|
|
|
|
|
for (i = 0; i < PN_TIMEOUT; i++) {
|
|
|
|
DELAY(10);
|
|
|
|
if (!(CSR_READ_4(sc, PN_BUSCTL) & PN_BUSCTL_RESET))
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (i == PN_TIMEOUT)
|
|
|
|
printf("pn%d: reset never completed!\n", sc->pn_unit);
|
|
|
|
|
|
|
|
/* Wait a little while for the chip to get its brains in order. */
|
|
|
|
DELAY(1000);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Probe for a Lite-On PNIC chip. Check the PCI vendor and device
|
|
|
|
* IDs against our list and return a device name if we find a match.
|
|
|
|
*/
|
1999-07-28 02:19:52 +00:00
|
|
|
static int pn_probe(dev)
|
|
|
|
device_t dev;
|
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
|
|
|
{
|
|
|
|
struct pn_type *t;
|
1999-04-10 18:44:53 +00:00
|
|
|
u_int32_t rev;
|
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
|
|
|
|
|
|
|
t = pn_devs;
|
|
|
|
|
|
|
|
while(t->pn_name != NULL) {
|
1999-07-28 02:19:52 +00:00
|
|
|
if ((pci_get_vendor(dev) == t->pn_vid) &&
|
|
|
|
(pci_get_device(dev) == t->pn_did)) {
|
1999-04-10 18:44:53 +00:00
|
|
|
if (t->pn_did == PN_DEVICEID_PNIC) {
|
1999-07-28 02:19:52 +00:00
|
|
|
rev = pci_read_config(dev,
|
|
|
|
PN_PCI_REVISION, 4) & 0xFF;
|
1999-04-10 18:44:53 +00:00
|
|
|
switch(rev & PN_REVMASK) {
|
|
|
|
case PN_REVID_82C168:
|
1999-07-28 02:19:52 +00:00
|
|
|
device_set_desc(dev, t->pn_name);
|
|
|
|
return(0);
|
1999-04-10 18:44:53 +00:00
|
|
|
break;
|
|
|
|
case PN_REVID_82C169:
|
|
|
|
t++;
|
1999-07-28 02:19:52 +00:00
|
|
|
device_set_desc(dev, t->pn_name);
|
|
|
|
return(0);
|
1999-04-10 18:44:53 +00:00
|
|
|
default:
|
|
|
|
printf("unknown PNIC rev: %x\n", rev);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
1999-07-28 02:19:52 +00:00
|
|
|
device_set_desc(dev, t->pn_name);
|
|
|
|
return(0);
|
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
|
|
|
}
|
|
|
|
t++;
|
|
|
|
}
|
|
|
|
|
1999-07-28 02:19:52 +00:00
|
|
|
return(ENXIO);
|
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
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Attach the interface. Allocate softc structures, do ifmedia
|
|
|
|
* setup and ethernet/BPF attach.
|
|
|
|
*/
|
1999-07-28 02:19:52 +00:00
|
|
|
static int pn_attach(dev)
|
|
|
|
device_t dev;
|
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
|
|
|
{
|
|
|
|
int s, i;
|
|
|
|
u_char eaddr[ETHER_ADDR_LEN];
|
|
|
|
u_int32_t command;
|
|
|
|
struct pn_softc *sc;
|
|
|
|
struct ifnet *ifp;
|
|
|
|
int media = IFM_ETHER|IFM_100_TX|IFM_FDX;
|
|
|
|
unsigned int round;
|
|
|
|
caddr_t roundptr;
|
|
|
|
struct pn_type *p;
|
|
|
|
u_int16_t phy_vid, phy_did, phy_sts;
|
1999-04-13 17:29:55 +00:00
|
|
|
#ifdef PN_RX_BUG_WAR
|
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
|
|
|
u_int32_t revision = 0;
|
|
|
|
#endif
|
1999-07-28 02:19:52 +00:00
|
|
|
int unit, error = 0, rid;
|
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
|
|
|
|
|
|
|
s = splimp();
|
|
|
|
|
1999-07-28 02:19:52 +00:00
|
|
|
sc = device_get_softc(dev);
|
|
|
|
unit = device_get_unit(dev);
|
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
|
|
|
bzero(sc, sizeof(struct pn_softc));
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Handle power management nonsense.
|
|
|
|
*/
|
1999-07-28 02:19:52 +00:00
|
|
|
command = pci_read_config(dev, PN_PCI_CAPID, 4) & 0x000000FF;
|
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
|
|
|
if (command == 0x01) {
|
|
|
|
|
1999-07-28 02:19:52 +00:00
|
|
|
command = pci_read_config(dev, PN_PCI_PWRMGMTCTRL, 4);
|
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
|
|
|
if (command & PN_PSTATE_MASK) {
|
|
|
|
u_int32_t iobase, membase, irq;
|
|
|
|
|
|
|
|
/* Save important PCI config data. */
|
1999-07-28 02:19:52 +00:00
|
|
|
iobase = pci_read_config(dev, PN_PCI_LOIO, 4);
|
|
|
|
membase = pci_read_config(dev, PN_PCI_LOMEM, 4);
|
|
|
|
irq = pci_read_config(dev, PN_PCI_INTLINE, 4);
|
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
|
|
|
|
|
|
|
/* Reset the power state. */
|
|
|
|
printf("pn%d: chip is in D%d power mode "
|
|
|
|
"-- setting to D0\n", unit, command & PN_PSTATE_MASK);
|
|
|
|
command &= 0xFFFFFFFC;
|
1999-07-28 02:19:52 +00:00
|
|
|
pci_write_config(dev, PN_PCI_PWRMGMTCTRL, command, 4);
|
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
|
|
|
|
|
|
|
/* Restore PCI config data. */
|
1999-07-28 02:19:52 +00:00
|
|
|
pci_write_config(dev, PN_PCI_LOIO, iobase, 4);
|
|
|
|
pci_write_config(dev, PN_PCI_LOMEM, membase, 4);
|
|
|
|
pci_write_config(dev, PN_PCI_INTLINE, irq, 4);
|
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
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Map control/status registers.
|
|
|
|
*/
|
1999-07-28 02:19:52 +00:00
|
|
|
command = pci_read_config(dev, PCI_COMMAND_STATUS_REG, 4);
|
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
|
|
|
command |= (PCIM_CMD_PORTEN|PCIM_CMD_MEMEN|PCIM_CMD_BUSMASTEREN);
|
1999-07-28 02:19:52 +00:00
|
|
|
pci_write_config(dev, PCI_COMMAND_STATUS_REG, command, 4);
|
|
|
|
command = pci_read_config(dev, PCI_COMMAND_STATUS_REG, 4);
|
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
|
|
|
|
|
|
|
#ifdef PN_USEIOSPACE
|
|
|
|
if (!(command & PCIM_CMD_PORTEN)) {
|
|
|
|
printf("pn%d: failed to enable I/O ports!\n", unit);
|
1999-07-28 02:19:52 +00:00
|
|
|
error = ENXIO;
|
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
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
#else
|
|
|
|
if (!(command & PCIM_CMD_MEMEN)) {
|
|
|
|
printf("pn%d: failed to enable memory mapping!\n", unit);
|
1999-07-28 02:19:52 +00:00
|
|
|
error = ENXIO;
|
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
|
|
|
goto fail;
|
|
|
|
}
|
1999-07-28 02:19:52 +00:00
|
|
|
#endif
|
|
|
|
|
|
|
|
rid = PN_RID;
|
|
|
|
sc->pn_res = bus_alloc_resource(dev, PN_RES, &rid,
|
|
|
|
0, ~0, 1, RF_ACTIVE);
|
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
|
|
|
|
1999-07-28 02:19:52 +00:00
|
|
|
if (sc->pn_res == NULL) {
|
|
|
|
printf ("pn%d: couldn't map ports/memory\n", unit);
|
|
|
|
error = ENXIO;
|
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
|
|
|
goto fail;
|
|
|
|
}
|
1999-07-28 02:19:52 +00:00
|
|
|
|
|
|
|
sc->pn_btag = rman_get_bustag(sc->pn_res);
|
|
|
|
sc->pn_bhandle = rman_get_bushandle(sc->pn_res);
|
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
|
|
|
|
|
|
|
/* Allocate interrupt */
|
1999-07-28 02:19:52 +00:00
|
|
|
rid = 0;
|
|
|
|
sc->pn_irq = bus_alloc_resource(dev, SYS_RES_IRQ, &rid, 0, ~0, 1,
|
|
|
|
RF_SHAREABLE | RF_ACTIVE);
|
|
|
|
|
|
|
|
if (sc->pn_irq == NULL) {
|
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
|
|
|
printf("pn%d: couldn't map interrupt\n", unit);
|
1999-07-28 02:19:52 +00:00
|
|
|
bus_release_resource(dev, PN_RES, PN_RID, sc->pn_res);
|
|
|
|
error = ENXIO;
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
|
|
|
|
error = bus_setup_intr(dev, sc->pn_irq, INTR_TYPE_NET,
|
|
|
|
pn_intr, sc, &sc->pn_intrhand);
|
|
|
|
|
|
|
|
if (error) {
|
|
|
|
bus_release_resource(dev, SYS_RES_IRQ, 0, sc->pn_res);
|
|
|
|
bus_release_resource(dev, PN_RES, PN_RID, sc->pn_res);
|
|
|
|
printf("pn%d: couldn't set up irq\n", unit);
|
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
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
|
1999-04-10 18:44:53 +00:00
|
|
|
/* Save the cache line size. */
|
1999-07-28 02:19:52 +00:00
|
|
|
sc->pn_cachesize = pci_read_config(dev, PN_PCI_CACHELEN, 4) & 0xFF;
|
1999-04-10 18:44:53 +00:00
|
|
|
|
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
|
|
|
/* Reset the adapter. */
|
|
|
|
pn_reset(sc);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Get station address from the EEPROM.
|
|
|
|
*/
|
|
|
|
pn_read_eeprom(sc, (caddr_t)&eaddr, 0, 3, 1);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* A PNIC chip was detected. Inform the world.
|
|
|
|
*/
|
|
|
|
printf("pn%d: Ethernet address: %6D\n", unit, eaddr, ":");
|
|
|
|
|
|
|
|
sc->pn_unit = unit;
|
|
|
|
bcopy(eaddr, (char *)&sc->arpcom.ac_enaddr, ETHER_ADDR_LEN);
|
|
|
|
|
|
|
|
sc->pn_ldata_ptr = malloc(sizeof(struct pn_list_data) + 8,
|
|
|
|
M_DEVBUF, M_NOWAIT);
|
|
|
|
if (sc->pn_ldata_ptr == NULL) {
|
|
|
|
printf("pn%d: no memory for list buffers!\n", unit);
|
1999-07-28 02:19:52 +00:00
|
|
|
bus_teardown_intr(dev, sc->pn_irq, sc->pn_intrhand);
|
|
|
|
bus_release_resource(dev, SYS_RES_IRQ, 0, sc->pn_res);
|
|
|
|
bus_release_resource(dev, PN_RES, PN_RID, sc->pn_res);
|
|
|
|
error = ENXIO;
|
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
|
|
|
goto fail;
|
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
|
|
|
}
|
|
|
|
|
|
|
|
sc->pn_ldata = (struct pn_list_data *)sc->pn_ldata_ptr;
|
1999-07-02 04:17:16 +00:00
|
|
|
round = (uintptr_t)sc->pn_ldata_ptr & 0xF;
|
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
|
|
|
roundptr = sc->pn_ldata_ptr;
|
|
|
|
for (i = 0; i < 8; i++) {
|
|
|
|
if (round % 8) {
|
|
|
|
round++;
|
|
|
|
roundptr++;
|
|
|
|
} else
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
sc->pn_ldata = (struct pn_list_data *)roundptr;
|
|
|
|
bzero(sc->pn_ldata, sizeof(struct pn_list_data));
|
|
|
|
|
1999-04-13 17:29:55 +00:00
|
|
|
#ifdef PN_RX_BUG_WAR
|
1999-07-28 02:19:52 +00:00
|
|
|
revision = pci_read_config(dev, PN_PCI_REVISION, 4) & 0x000000FF;
|
1999-04-11 05:15:26 +00:00
|
|
|
if (revision == PN_169B_REV || revision == PN_169_REV ||
|
|
|
|
(revision & 0xF0) == PN_168_REV) {
|
1999-04-13 17:29:55 +00:00
|
|
|
sc->pn_rx_war = 1;
|
1999-08-24 03:19:45 +00:00
|
|
|
sc->pn_rx_buf = malloc(PN_RXLEN * 5, M_DEVBUF, M_NOWAIT);
|
1999-04-13 17:29:55 +00:00
|
|
|
if (sc->pn_rx_buf == NULL) {
|
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
|
|
|
printf("pn%d: no memory for workaround buffer\n", unit);
|
1999-07-28 02:19:52 +00:00
|
|
|
bus_teardown_intr(dev, sc->pn_irq, sc->pn_intrhand);
|
|
|
|
bus_release_resource(dev, SYS_RES_IRQ, 0, sc->pn_res);
|
|
|
|
bus_release_resource(dev, PN_RES, PN_RID, sc->pn_res);
|
|
|
|
free(sc->pn_ldata_ptr, M_DEVBUF);
|
|
|
|
error = ENXIO;
|
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
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
} else {
|
1999-04-13 17:29:55 +00:00
|
|
|
sc->pn_rx_war = 0;
|
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
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
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
|
|
|
ifp = &sc->arpcom.ac_if;
|
|
|
|
ifp->if_softc = sc;
|
|
|
|
ifp->if_unit = unit;
|
|
|
|
ifp->if_name = "pn";
|
|
|
|
ifp->if_mtu = ETHERMTU;
|
|
|
|
ifp->if_flags = IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST;
|
|
|
|
ifp->if_ioctl = pn_ioctl;
|
|
|
|
ifp->if_output = ether_output;
|
|
|
|
ifp->if_start = pn_start;
|
|
|
|
ifp->if_watchdog = pn_watchdog;
|
|
|
|
ifp->if_init = pn_init;
|
|
|
|
ifp->if_baudrate = 10000000;
|
1999-02-01 21:25:52 +00:00
|
|
|
ifp->if_snd.ifq_maxlen = PN_TX_LIST_CNT - 1;
|
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
|
|
|
|
1999-04-10 18:44:53 +00:00
|
|
|
ifmedia_init(&sc->ifmedia, 0, pn_ifmedia_upd, pn_ifmedia_sts);
|
|
|
|
|
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
|
|
|
if (bootverbose)
|
|
|
|
printf("pn%d: probing for a PHY\n", sc->pn_unit);
|
|
|
|
for (i = PN_PHYADDR_MIN; i < PN_PHYADDR_MAX + 1; i++) {
|
|
|
|
if (bootverbose)
|
|
|
|
printf("pn%d: checking address: %d\n",
|
|
|
|
sc->pn_unit, i);
|
|
|
|
sc->pn_phy_addr = i;
|
|
|
|
pn_phy_writereg(sc, PHY_BMCR, PHY_BMCR_RESET);
|
|
|
|
DELAY(500);
|
|
|
|
while(pn_phy_readreg(sc, PHY_BMCR)
|
|
|
|
& PHY_BMCR_RESET);
|
|
|
|
if ((phy_sts = pn_phy_readreg(sc, PHY_BMSR)))
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (phy_sts) {
|
|
|
|
phy_vid = pn_phy_readreg(sc, PHY_VENID);
|
|
|
|
phy_did = pn_phy_readreg(sc, PHY_DEVID);
|
|
|
|
if (bootverbose)
|
|
|
|
printf("pn%d: found PHY at address %d, ",
|
|
|
|
sc->pn_unit, sc->pn_phy_addr);
|
|
|
|
if (bootverbose)
|
|
|
|
printf("vendor id: %x device id: %x\n",
|
|
|
|
phy_vid, phy_did);
|
|
|
|
p = pn_phys;
|
|
|
|
while(p->pn_vid) {
|
|
|
|
if (phy_vid == p->pn_vid &&
|
|
|
|
(phy_did | 0x000F) == p->pn_did) {
|
|
|
|
sc->pn_pinfo = p;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
p++;
|
|
|
|
}
|
|
|
|
if (sc->pn_pinfo == NULL)
|
|
|
|
sc->pn_pinfo = &pn_phys[PHY_UNKNOWN];
|
|
|
|
if (bootverbose)
|
|
|
|
printf("pn%d: PHY type: %s\n",
|
|
|
|
sc->pn_unit, sc->pn_pinfo->pn_name);
|
1999-04-10 18:44:53 +00:00
|
|
|
|
|
|
|
pn_getmode_mii(sc);
|
1999-07-28 02:19:52 +00:00
|
|
|
if (cold) {
|
|
|
|
pn_autoneg_mii(sc, PN_FLAG_FORCEDELAY, 1);
|
|
|
|
pn_stop(sc);
|
|
|
|
} else {
|
|
|
|
pn_init(sc);
|
|
|
|
pn_autoneg_mii(sc, PN_FLAG_SCHEDDELAY, 1);
|
|
|
|
}
|
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
|
|
|
} else {
|
1999-04-10 18:44:53 +00:00
|
|
|
ifmedia_add(&sc->ifmedia, IFM_ETHER|IFM_10_T, 0, NULL);
|
|
|
|
ifmedia_add(&sc->ifmedia, IFM_ETHER|IFM_10_T|IFM_HDX, 0, NULL);
|
|
|
|
ifmedia_add(&sc->ifmedia, IFM_ETHER|IFM_10_T|IFM_FDX, 0, NULL);
|
|
|
|
ifmedia_add(&sc->ifmedia, IFM_ETHER|IFM_100_TX, 0, NULL);
|
|
|
|
ifmedia_add(&sc->ifmedia,
|
|
|
|
IFM_ETHER|IFM_100_TX|IFM_HDX, 0, NULL);
|
|
|
|
ifmedia_add(&sc->ifmedia,
|
|
|
|
IFM_ETHER|IFM_100_TX|IFM_FDX, 0, NULL);
|
|
|
|
ifmedia_add(&sc->ifmedia, IFM_ETHER|IFM_100_T4, 0, NULL);
|
|
|
|
ifmedia_add(&sc->ifmedia, IFM_ETHER|IFM_AUTO, 0, NULL);
|
1999-07-28 02:19:52 +00:00
|
|
|
pn_init(sc);
|
|
|
|
if (cold) {
|
|
|
|
pn_autoneg(sc, PN_FLAG_FORCEDELAY, 1);
|
|
|
|
pn_stop(sc);
|
|
|
|
} else {
|
|
|
|
pn_init(sc);
|
|
|
|
pn_autoneg(sc, PN_FLAG_SCHEDDELAY, 1);
|
|
|
|
}
|
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
|
|
|
}
|
|
|
|
|
|
|
|
media = sc->ifmedia.ifm_media;
|
|
|
|
ifmedia_set(&sc->ifmedia, media);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Call MI attach routines.
|
|
|
|
*/
|
|
|
|
if_attach(ifp);
|
|
|
|
ether_ifattach(ifp);
|
|
|
|
|
1999-07-06 19:23:32 +00:00
|
|
|
#if NBPF > 0
|
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
|
|
|
bpfattach(ifp, DLT_EN10MB, sizeof(struct ether_header));
|
|
|
|
#endif
|
|
|
|
|
|
|
|
fail:
|
|
|
|
splx(s);
|
1999-07-28 02:19:52 +00:00
|
|
|
return(error);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int pn_detach(dev)
|
|
|
|
device_t dev;
|
|
|
|
{
|
|
|
|
struct pn_softc *sc;
|
|
|
|
struct ifnet *ifp;
|
|
|
|
int s;
|
|
|
|
|
|
|
|
s = splimp();
|
|
|
|
|
|
|
|
sc = device_get_softc(dev);
|
|
|
|
ifp = &sc->arpcom.ac_if;
|
|
|
|
|
|
|
|
if_detach(ifp);
|
|
|
|
pn_stop(sc);
|
|
|
|
|
|
|
|
bus_teardown_intr(dev, sc->pn_irq, sc->pn_intrhand);
|
|
|
|
bus_release_resource(dev, SYS_RES_IRQ, 0, sc->pn_res);
|
|
|
|
bus_release_resource(dev, PN_RES, PN_RID, sc->pn_res);
|
|
|
|
|
|
|
|
free(sc->pn_ldata_ptr, M_DEVBUF);
|
|
|
|
#ifdef PN_RX_BUG_WAR
|
1999-08-31 04:22:46 +00:00
|
|
|
if (sc->pn_rx_war)
|
|
|
|
free(sc->pn_rx_buf, M_DEVBUF);
|
1999-07-28 02:19:52 +00:00
|
|
|
#endif
|
|
|
|
ifmedia_removeall(&sc->ifmedia);
|
|
|
|
|
|
|
|
splx(s);
|
|
|
|
|
|
|
|
return(0);
|
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
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Initialize the transmit descriptors.
|
|
|
|
*/
|
|
|
|
static int pn_list_tx_init(sc)
|
|
|
|
struct pn_softc *sc;
|
|
|
|
{
|
|
|
|
struct pn_chain_data *cd;
|
|
|
|
struct pn_list_data *ld;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
cd = &sc->pn_cdata;
|
|
|
|
ld = sc->pn_ldata;
|
|
|
|
for (i = 0; i < PN_TX_LIST_CNT; i++) {
|
|
|
|
cd->pn_tx_chain[i].pn_ptr = &ld->pn_tx_list[i];
|
|
|
|
if (i == (PN_TX_LIST_CNT - 1))
|
|
|
|
cd->pn_tx_chain[i].pn_nextdesc =
|
|
|
|
&cd->pn_tx_chain[0];
|
|
|
|
else
|
|
|
|
cd->pn_tx_chain[i].pn_nextdesc =
|
|
|
|
&cd->pn_tx_chain[i + 1];
|
|
|
|
}
|
|
|
|
|
|
|
|
cd->pn_tx_free = &cd->pn_tx_chain[0];
|
|
|
|
cd->pn_tx_tail = cd->pn_tx_head = NULL;
|
|
|
|
|
|
|
|
return(0);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Initialize the RX descriptors and allocate mbufs for them. Note that
|
|
|
|
* we arrange the descriptors in a closed ring, so that the last descriptor
|
|
|
|
* points back to the first.
|
|
|
|
*/
|
|
|
|
static int pn_list_rx_init(sc)
|
|
|
|
struct pn_softc *sc;
|
|
|
|
{
|
|
|
|
struct pn_chain_data *cd;
|
|
|
|
struct pn_list_data *ld;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
cd = &sc->pn_cdata;
|
|
|
|
ld = sc->pn_ldata;
|
|
|
|
|
|
|
|
for (i = 0; i < PN_RX_LIST_CNT; i++) {
|
|
|
|
cd->pn_rx_chain[i].pn_ptr =
|
|
|
|
(struct pn_desc *)&ld->pn_rx_list[i];
|
1999-07-28 02:19:52 +00:00
|
|
|
if (pn_newbuf(sc, &cd->pn_rx_chain[i], NULL) == ENOBUFS)
|
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
|
|
|
return(ENOBUFS);
|
|
|
|
if (i == (PN_RX_LIST_CNT - 1)) {
|
|
|
|
cd->pn_rx_chain[i].pn_nextdesc = &cd->pn_rx_chain[0];
|
|
|
|
ld->pn_rx_list[i].pn_next =
|
|
|
|
vtophys(&ld->pn_rx_list[0]);
|
|
|
|
} else {
|
|
|
|
cd->pn_rx_chain[i].pn_nextdesc = &cd->pn_rx_chain[i + 1];
|
|
|
|
ld->pn_rx_list[i].pn_next =
|
|
|
|
vtophys(&ld->pn_rx_list[i + 1]);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
cd->pn_rx_head = &cd->pn_rx_chain[0];
|
|
|
|
|
|
|
|
return(0);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Initialize an RX descriptor and attach an MBUF cluster.
|
|
|
|
* Note: the length fields are only 11 bits wide, which means the
|
|
|
|
* largest size we can specify is 2047. This is important because
|
|
|
|
* MCLBYTES is 2048, so we have to subtract one otherwise we'll
|
|
|
|
* overflow the field and make a mess.
|
|
|
|
*/
|
1999-07-28 02:19:52 +00:00
|
|
|
static int pn_newbuf(sc, c, m)
|
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
|
|
|
struct pn_softc *sc;
|
|
|
|
struct pn_chain_onefrag *c;
|
1999-07-28 02:19:52 +00:00
|
|
|
struct mbuf *m;
|
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
|
|
|
{
|
|
|
|
struct mbuf *m_new = NULL;
|
|
|
|
|
1999-07-28 02:19:52 +00:00
|
|
|
if (m == NULL) {
|
|
|
|
MGETHDR(m_new, M_DONTWAIT, MT_DATA);
|
|
|
|
if (m_new == NULL) {
|
|
|
|
printf("pn%d: no memory for rx list "
|
|
|
|
"-- packet dropped!\n", sc->pn_unit);
|
|
|
|
return(ENOBUFS);
|
|
|
|
}
|
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
|
|
|
|
1999-07-28 02:19:52 +00:00
|
|
|
MCLGET(m_new, M_DONTWAIT);
|
|
|
|
if (!(m_new->m_flags & M_EXT)) {
|
|
|
|
printf("pn%d: no memory for rx list -- "
|
|
|
|
"packet dropped!\n", sc->pn_unit);
|
|
|
|
m_freem(m_new);
|
|
|
|
return(ENOBUFS);
|
|
|
|
}
|
|
|
|
m_new->m_len = m_new->m_pkthdr.len = MCLBYTES;
|
|
|
|
} else {
|
|
|
|
m_new = m;
|
|
|
|
m_new->m_len = m_new->m_pkthdr.len = MCLBYTES;
|
|
|
|
m_new->m_data = m_new->m_ext.ext_buf;
|
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
|
|
|
}
|
|
|
|
|
1999-07-28 02:19:52 +00:00
|
|
|
/*
|
|
|
|
* Leave a couple of empty leading bytes; we'll need them later
|
|
|
|
* when we fix up things for proper payload alignment.
|
|
|
|
*/
|
|
|
|
m_adj(m_new, sizeof(u_int64_t));
|
|
|
|
|
1999-08-31 04:22:46 +00:00
|
|
|
#ifdef PN_RX_BUG_WAR
|
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
|
|
|
/*
|
|
|
|
* Zero the buffer. This is part of the workaround for the
|
|
|
|
* promiscuous mode bug in the revision 33 PNIC chips.
|
|
|
|
*/
|
1999-08-31 04:22:46 +00:00
|
|
|
if (sc->pn_rx_war)
|
|
|
|
bzero((char *)mtod(m_new, char *), m_new->m_len);
|
|
|
|
#endif
|
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
|
|
|
|
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
|
|
|
c->pn_mbuf = m_new;
|
|
|
|
c->pn_ptr->pn_data = vtophys(mtod(m_new, caddr_t));
|
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
|
|
|
c->pn_ptr->pn_ctl = PN_RXCTL_RLINK | PN_RXLEN;
|
1999-07-28 02:19:52 +00:00
|
|
|
c->pn_ptr->pn_status = PN_RXSTAT;
|
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
|
|
|
|
|
|
|
return(0);
|
|
|
|
}
|
|
|
|
|
1999-04-13 17:29:55 +00:00
|
|
|
#ifdef PN_RX_BUG_WAR
|
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
|
|
|
/*
|
|
|
|
* Grrrrr.
|
1999-04-13 17:29:55 +00:00
|
|
|
* The PNIC chip has a terrible bug in it that manifests itself during
|
|
|
|
* periods of heavy activity. The exact mode of failure if difficult to
|
|
|
|
* pinpoint: sometimes it only happens in promiscuous mode, sometimes it
|
|
|
|
* will happen on slow machines. The bug is that sometimes instead of
|
|
|
|
* uploading one complete frame during reception, it uploads what looks
|
|
|
|
* like the entire contents of its FIFO memory. The frame we want is at
|
|
|
|
* the end of the whole mess, but we never know exactly how much data has
|
|
|
|
* been uploaded, so salvaging the frame is hard.
|
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
|
|
|
*
|
|
|
|
* There is only one way to do it reliably, and it's disgusting.
|
|
|
|
* Here's what we know:
|
|
|
|
*
|
|
|
|
* - We know there will always be somewhere between one and three extra
|
|
|
|
* descriptors uploaded.
|
|
|
|
*
|
|
|
|
* - We know the desired received frame will always be at the end of the
|
|
|
|
* total data upload.
|
|
|
|
*
|
|
|
|
* - We know the size of the desired received frame because it will be
|
|
|
|
* provided in the length field of the status word in the last descriptor.
|
|
|
|
*
|
|
|
|
* Here's what we do:
|
|
|
|
*
|
|
|
|
* - When we allocate buffers for the receive ring, we bzero() them.
|
|
|
|
* This means that we know that the buffer contents should be all
|
|
|
|
* zeros, except for data uploaded by the chip.
|
|
|
|
*
|
|
|
|
* - We also force the PNIC chip to upload frames that include the
|
|
|
|
* ethernet CRC at the end.
|
|
|
|
*
|
|
|
|
* - We gather all of the bogus frame data into a single buffer.
|
|
|
|
*
|
|
|
|
* - We then position a pointer at the end of this buffer and scan
|
|
|
|
* backwards until we encounter the first non-zero byte of data.
|
|
|
|
* This is the end of the received frame. We know we will encounter
|
|
|
|
* some data at the end of the frame because the CRC will always be
|
|
|
|
* there, so even if the sender transmits a packet of all zeros,
|
|
|
|
* we won't be fooled.
|
|
|
|
*
|
|
|
|
* - We know the size of the actual received frame, so we subtract
|
|
|
|
* that value from the current pointer location. This brings us
|
|
|
|
* to the start of the actual received packet.
|
|
|
|
*
|
|
|
|
* - We copy this into an mbuf and pass it on, along with the actual
|
|
|
|
* frame length.
|
|
|
|
*
|
|
|
|
* The performance hit is tremendous, but it beats dropping frames all
|
|
|
|
* the time.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#define PN_WHOLEFRAME (PN_RXSTAT_FIRSTFRAG|PN_RXSTAT_LASTFRAG)
|
1999-04-13 17:29:55 +00:00
|
|
|
static void pn_rx_bug_war(sc, cur_rx)
|
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
|
|
|
struct pn_softc *sc;
|
|
|
|
struct pn_chain_onefrag *cur_rx;
|
|
|
|
{
|
|
|
|
struct pn_chain_onefrag *c;
|
|
|
|
unsigned char *ptr;
|
|
|
|
int total_len;
|
|
|
|
u_int32_t rxstat = 0;
|
|
|
|
|
1999-04-13 17:29:55 +00:00
|
|
|
c = sc->pn_rx_bug_save;
|
|
|
|
ptr = sc->pn_rx_buf;
|
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
|
|
|
bzero(ptr, sizeof(PN_RXLEN * 5));
|
|
|
|
|
|
|
|
/* Copy all the bytes from the bogus buffers. */
|
|
|
|
while ((c->pn_ptr->pn_status & PN_WHOLEFRAME) != PN_WHOLEFRAME) {
|
|
|
|
rxstat = c->pn_ptr->pn_status;
|
|
|
|
m_copydata(c->pn_mbuf, 0, PN_RXLEN, ptr);
|
1999-08-24 03:19:45 +00:00
|
|
|
ptr += PN_RXLEN;
|
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
|
|
|
if (c == cur_rx)
|
|
|
|
break;
|
|
|
|
if (rxstat & PN_RXSTAT_LASTFRAG)
|
|
|
|
break;
|
|
|
|
c->pn_ptr->pn_status = PN_RXSTAT;
|
|
|
|
c->pn_ptr->pn_ctl = PN_RXCTL_RLINK | PN_RXLEN;
|
|
|
|
bzero((char *)mtod(c->pn_mbuf, char *), MCLBYTES);
|
|
|
|
c = c->pn_nextdesc;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Find the length of the actual receive frame. */
|
|
|
|
total_len = PN_RXBYTES(rxstat);
|
|
|
|
|
|
|
|
/* Scan backwards until we hit a non-zero byte. */
|
1999-04-13 17:29:55 +00:00
|
|
|
while(*ptr == 0x00)
|
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
|
|
|
ptr--;
|
|
|
|
|
1999-04-13 17:29:55 +00:00
|
|
|
/* Round off. */
|
1999-07-02 04:17:16 +00:00
|
|
|
if ((uintptr_t)(ptr) & 0x3)
|
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
|
|
|
ptr -= 1;
|
|
|
|
|
|
|
|
/* Now find the start of the frame. */
|
|
|
|
ptr -= total_len;
|
1999-04-13 17:29:55 +00:00
|
|
|
if (ptr < sc->pn_rx_buf)
|
|
|
|
ptr = sc->pn_rx_buf;
|
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
|
|
|
|
|
|
|
/*
|
|
|
|
* Now copy the salvaged frame to the last mbuf and fake up
|
|
|
|
* the status word to make it look like a successful
|
|
|
|
* frame reception.
|
|
|
|
*/
|
|
|
|
m_copyback(cur_rx->pn_mbuf, 0, total_len, ptr);
|
|
|
|
cur_rx->pn_mbuf->m_len = c->pn_mbuf->m_pkthdr.len = MCLBYTES;
|
|
|
|
cur_rx->pn_ptr->pn_status |= PN_RXSTAT_FIRSTFRAG;
|
|
|
|
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
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
|
|
|
/*
|
|
|
|
* A frame has been uploaded: pass the resulting mbuf chain up to
|
|
|
|
* the higher level protocols.
|
|
|
|
*/
|
|
|
|
static void pn_rxeof(sc)
|
|
|
|
struct pn_softc *sc;
|
|
|
|
{
|
|
|
|
struct ether_header *eh;
|
|
|
|
struct mbuf *m;
|
|
|
|
struct ifnet *ifp;
|
|
|
|
struct pn_chain_onefrag *cur_rx;
|
|
|
|
int total_len = 0;
|
|
|
|
u_int32_t rxstat;
|
|
|
|
|
|
|
|
ifp = &sc->arpcom.ac_if;
|
|
|
|
|
|
|
|
while(!((rxstat = sc->pn_cdata.pn_rx_head->pn_ptr->pn_status) &
|
|
|
|
PN_RXSTAT_OWN)) {
|
1999-03-27 20:41:25 +00:00
|
|
|
struct mbuf *m0 = NULL;
|
1999-07-28 02:19:52 +00:00
|
|
|
|
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
|
|
|
cur_rx = sc->pn_cdata.pn_rx_head;
|
|
|
|
sc->pn_cdata.pn_rx_head = cur_rx->pn_nextdesc;
|
|
|
|
|
1999-04-13 17:29:55 +00:00
|
|
|
#ifdef PN_RX_BUG_WAR
|
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
|
|
|
/*
|
1999-04-13 17:29:55 +00:00
|
|
|
* XXX The PNIC has a nasty receiver bug that manifests
|
|
|
|
* under certain conditions (sometimes only in promiscuous
|
|
|
|
* mode, sometimes only on slow machines even when not in
|
|
|
|
* promiscuous mode). We have to keep an eye out for the
|
|
|
|
* failure condition and employ a workaround to recover
|
|
|
|
* any mangled frames.
|
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
|
|
|
*/
|
1999-04-13 17:29:55 +00:00
|
|
|
if (sc->pn_rx_war) {
|
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
|
|
|
if ((rxstat & PN_WHOLEFRAME) != PN_WHOLEFRAME) {
|
|
|
|
if (rxstat & PN_RXSTAT_FIRSTFRAG)
|
1999-04-13 17:29:55 +00:00
|
|
|
sc->pn_rx_bug_save = cur_rx;
|
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
|
|
|
if ((rxstat & PN_RXSTAT_LASTFRAG) == 0)
|
|
|
|
continue;
|
1999-04-13 17:29:55 +00:00
|
|
|
pn_rx_bug_war(sc, cur_rx);
|
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
|
|
|
rxstat = cur_rx->pn_ptr->pn_status;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
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
|
|
|
/*
|
|
|
|
* If an error occurs, update stats, clear the
|
|
|
|
* status word and leave the mbuf cluster in place:
|
|
|
|
* it should simply get re-used next time this descriptor
|
|
|
|
* comes up in the ring.
|
|
|
|
*/
|
|
|
|
if (rxstat & PN_RXSTAT_RXERR) {
|
|
|
|
ifp->if_ierrors++;
|
|
|
|
if (rxstat & PN_RXSTAT_COLLSEEN)
|
|
|
|
ifp->if_collisions++;
|
1999-07-28 02:19:52 +00:00
|
|
|
pn_newbuf(sc, cur_rx, cur_rx->pn_mbuf);
|
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
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* No errors; receive the packet. */
|
|
|
|
m = cur_rx->pn_mbuf;
|
|
|
|
total_len = PN_RXBYTES(cur_rx->pn_ptr->pn_status);
|
|
|
|
|
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
|
|
|
/* Trim off the CRC. */
|
|
|
|
total_len -= ETHER_CRC_LEN;
|
|
|
|
|
1999-07-28 02:19:52 +00:00
|
|
|
m0 = m_devget(mtod(m, char *) - ETHER_ALIGN,
|
|
|
|
total_len + ETHER_ALIGN, 0, ifp, NULL);
|
|
|
|
pn_newbuf(sc, cur_rx, m);
|
1999-03-27 20:41:25 +00:00
|
|
|
if (m0 == NULL) {
|
|
|
|
ifp->if_ierrors++;
|
|
|
|
continue;
|
|
|
|
}
|
1999-07-28 02:19:52 +00:00
|
|
|
m_adj(m0, ETHER_ALIGN);
|
|
|
|
m = m0;
|
|
|
|
ifp->if_ipackets++;
|
|
|
|
eh = mtod(m, struct ether_header *);
|
1999-03-27 20:41:25 +00:00
|
|
|
|
1999-07-28 02:19:52 +00:00
|
|
|
#ifdef BRIDGE
|
|
|
|
if (do_bridge) {
|
|
|
|
struct ifnet *bdg_ifp;
|
|
|
|
bdg_ifp = bridge_in(m);
|
|
|
|
if (bdg_ifp != BDG_LOCAL && bdg_ifp != BDG_DROP)
|
|
|
|
bdg_forward(&m, bdg_ifp);
|
|
|
|
if (((bdg_ifp != BDG_LOCAL) && (bdg_ifp != BDG_BCAST) &&
|
|
|
|
(bdg_ifp != BDG_MCAST)) || bdg_ifp == BDG_DROP) {
|
|
|
|
m_freem(m);
|
|
|
|
continue;
|
|
|
|
}
|
1999-03-27 20:41:25 +00:00
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
1999-07-06 19:23:32 +00:00
|
|
|
#if NBPF > 0
|
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
|
|
|
/*
|
|
|
|
* Handle BPF listeners. Let the BPF user see the packet, but
|
|
|
|
* don't pass it up to the ether_input() layer unless it's
|
|
|
|
* a broadcast packet, multicast packet, matches our ethernet
|
|
|
|
* address or the interface is in promiscuous mode.
|
|
|
|
*/
|
|
|
|
if (ifp->if_bpf) {
|
|
|
|
bpf_mtap(ifp, m);
|
|
|
|
if (ifp->if_flags & IFF_PROMISC &&
|
|
|
|
(bcmp(eh->ether_dhost, sc->arpcom.ac_enaddr,
|
|
|
|
ETHER_ADDR_LEN) &&
|
|
|
|
(eh->ether_dhost[0] & 1) == 0)) {
|
|
|
|
m_freem(m);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
/* Remove header from mbuf and pass it on. */
|
|
|
|
m_adj(m, sizeof(struct ether_header));
|
|
|
|
ether_input(ifp, eh, m);
|
|
|
|
}
|
|
|
|
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
void pn_rxeoc(sc)
|
|
|
|
struct pn_softc *sc;
|
|
|
|
{
|
|
|
|
|
|
|
|
pn_rxeof(sc);
|
|
|
|
PN_CLRBIT(sc, PN_NETCFG, PN_NETCFG_RX_ON);
|
|
|
|
CSR_WRITE_4(sc, PN_RXADDR, vtophys(sc->pn_cdata.pn_rx_head->pn_ptr));
|
|
|
|
PN_SETBIT(sc, PN_NETCFG, PN_NETCFG_RX_ON);
|
|
|
|
CSR_WRITE_4(sc, PN_RXSTART, 0xFFFFFFFF);
|
|
|
|
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* A frame was downloaded to the chip. It's safe for us to clean up
|
|
|
|
* the list buffers.
|
|
|
|
*/
|
|
|
|
|
|
|
|
static void pn_txeof(sc)
|
|
|
|
struct pn_softc *sc;
|
|
|
|
{
|
|
|
|
struct pn_chain *cur_tx;
|
|
|
|
struct ifnet *ifp;
|
|
|
|
|
|
|
|
ifp = &sc->arpcom.ac_if;
|
|
|
|
|
|
|
|
/* Clear the timeout timer. */
|
|
|
|
ifp->if_timer = 0;
|
|
|
|
|
|
|
|
if (sc->pn_cdata.pn_tx_head == NULL)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Go through our tx list and free mbufs for those
|
|
|
|
* frames that have been transmitted.
|
|
|
|
*/
|
|
|
|
while(sc->pn_cdata.pn_tx_head->pn_mbuf != NULL) {
|
|
|
|
u_int32_t txstat;
|
|
|
|
|
|
|
|
cur_tx = sc->pn_cdata.pn_tx_head;
|
|
|
|
txstat = PN_TXSTATUS(cur_tx);
|
|
|
|
|
1999-03-27 20:41:25 +00:00
|
|
|
if (txstat & PN_TXSTAT_OWN)
|
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
|
|
|
break;
|
|
|
|
|
|
|
|
if (txstat & PN_TXSTAT_ERRSUM) {
|
|
|
|
ifp->if_oerrors++;
|
|
|
|
if (txstat & PN_TXSTAT_EXCESSCOLL)
|
|
|
|
ifp->if_collisions++;
|
|
|
|
if (txstat & PN_TXSTAT_LATECOLL)
|
|
|
|
ifp->if_collisions++;
|
|
|
|
}
|
|
|
|
|
|
|
|
ifp->if_collisions += (txstat & PN_TXSTAT_COLLCNT) >> 3;
|
|
|
|
|
|
|
|
|
|
|
|
ifp->if_opackets++;
|
|
|
|
m_freem(cur_tx->pn_mbuf);
|
|
|
|
cur_tx->pn_mbuf = NULL;
|
|
|
|
|
|
|
|
if (sc->pn_cdata.pn_tx_head == sc->pn_cdata.pn_tx_tail) {
|
|
|
|
sc->pn_cdata.pn_tx_head = NULL;
|
|
|
|
sc->pn_cdata.pn_tx_tail = NULL;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
sc->pn_cdata.pn_tx_head = cur_tx->pn_nextdesc;
|
|
|
|
}
|
|
|
|
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* TX 'end of channel' interrupt handler.
|
|
|
|
*/
|
|
|
|
static void pn_txeoc(sc)
|
|
|
|
struct pn_softc *sc;
|
|
|
|
{
|
|
|
|
struct ifnet *ifp;
|
|
|
|
|
|
|
|
ifp = &sc->arpcom.ac_if;
|
|
|
|
|
|
|
|
ifp->if_timer = 0;
|
|
|
|
|
|
|
|
if (sc->pn_cdata.pn_tx_head == NULL) {
|
|
|
|
ifp->if_flags &= ~IFF_OACTIVE;
|
|
|
|
sc->pn_cdata.pn_tx_tail = NULL;
|
1999-04-10 18:44:53 +00:00
|
|
|
if (sc->pn_want_auto) {
|
|
|
|
if (sc->pn_pinfo == NULL)
|
|
|
|
pn_autoneg(sc, PN_FLAG_SCHEDDELAY, 1);
|
|
|
|
else
|
|
|
|
pn_autoneg_mii(sc, PN_FLAG_SCHEDDELAY, 1);
|
|
|
|
}
|
|
|
|
|
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
|
|
|
}
|
|
|
|
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void pn_intr(arg)
|
|
|
|
void *arg;
|
|
|
|
{
|
|
|
|
struct pn_softc *sc;
|
|
|
|
struct ifnet *ifp;
|
|
|
|
u_int32_t status;
|
|
|
|
|
|
|
|
sc = arg;
|
|
|
|
ifp = &sc->arpcom.ac_if;
|
|
|
|
|
|
|
|
/* Supress unwanted interrupts. */
|
|
|
|
if (!(ifp->if_flags & IFF_UP)) {
|
|
|
|
pn_stop(sc);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Disable interrupts. */
|
|
|
|
CSR_WRITE_4(sc, PN_IMR, 0x00000000);
|
|
|
|
|
|
|
|
for (;;) {
|
|
|
|
status = CSR_READ_4(sc, PN_ISR);
|
|
|
|
if (status)
|
|
|
|
CSR_WRITE_4(sc, PN_ISR, status);
|
|
|
|
|
|
|
|
if ((status & PN_INTRS) == 0)
|
|
|
|
break;
|
|
|
|
|
|
|
|
if (status & PN_ISR_RX_OK)
|
|
|
|
pn_rxeof(sc);
|
|
|
|
|
|
|
|
if ((status & PN_ISR_RX_WATCHDOG) || (status & PN_ISR_RX_IDLE)
|
|
|
|
|| (status & PN_ISR_RX_NOBUF))
|
|
|
|
pn_rxeoc(sc);
|
|
|
|
|
|
|
|
if (status & PN_ISR_TX_OK)
|
|
|
|
pn_txeof(sc);
|
|
|
|
|
|
|
|
if (status & PN_ISR_TX_NOBUF)
|
|
|
|
pn_txeoc(sc);
|
|
|
|
|
|
|
|
if (status & PN_ISR_TX_IDLE) {
|
|
|
|
pn_txeof(sc);
|
|
|
|
if (sc->pn_cdata.pn_tx_head != NULL) {
|
|
|
|
PN_SETBIT(sc, PN_NETCFG, PN_NETCFG_TX_ON);
|
|
|
|
CSR_WRITE_4(sc, PN_TXSTART, 0xFFFFFFFF);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (status & PN_ISR_TX_UNDERRUN) {
|
|
|
|
ifp->if_oerrors++;
|
|
|
|
pn_txeof(sc);
|
|
|
|
if (sc->pn_cdata.pn_tx_head != NULL) {
|
|
|
|
PN_SETBIT(sc, PN_NETCFG, PN_NETCFG_TX_ON);
|
|
|
|
CSR_WRITE_4(sc, PN_TXSTART, 0xFFFFFFFF);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (status & PN_ISR_BUS_ERR) {
|
|
|
|
pn_reset(sc);
|
|
|
|
pn_init(sc);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Re-enable interrupts. */
|
|
|
|
CSR_WRITE_4(sc, PN_IMR, PN_INTRS);
|
|
|
|
|
|
|
|
if (ifp->if_snd.ifq_head != NULL) {
|
|
|
|
pn_start(ifp);
|
|
|
|
}
|
|
|
|
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Encapsulate an mbuf chain in a descriptor by coupling the mbuf data
|
|
|
|
* pointers to the fragment pointers.
|
|
|
|
*/
|
|
|
|
static int pn_encap(sc, c, m_head)
|
|
|
|
struct pn_softc *sc;
|
|
|
|
struct pn_chain *c;
|
|
|
|
struct mbuf *m_head;
|
|
|
|
{
|
|
|
|
int frag = 0;
|
|
|
|
struct pn_desc *f = NULL;
|
|
|
|
int total_len;
|
|
|
|
struct mbuf *m;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Start packing the mbufs in this chain into
|
|
|
|
* the fragment pointers. Stop when we run out
|
|
|
|
* of fragments or hit the end of the mbuf chain.
|
|
|
|
*/
|
|
|
|
m = m_head;
|
|
|
|
total_len = 0;
|
|
|
|
|
|
|
|
for (m = m_head, frag = 0; m != NULL; m = m->m_next) {
|
|
|
|
if (m->m_len != 0) {
|
|
|
|
if (frag == PN_MAXFRAGS)
|
|
|
|
break;
|
|
|
|
total_len += m->m_len;
|
|
|
|
f = &c->pn_ptr->pn_frag[frag];
|
|
|
|
f->pn_ctl = PN_TXCTL_TLINK | m->m_len;
|
|
|
|
if (frag == 0) {
|
|
|
|
f->pn_ctl |= PN_TXCTL_FIRSTFRAG;
|
|
|
|
f->pn_status = 0;
|
|
|
|
} else
|
|
|
|
f->pn_status = PN_TXSTAT_OWN;
|
|
|
|
f->pn_data = vtophys(mtod(m, vm_offset_t));
|
|
|
|
f->pn_next = vtophys(&c->pn_ptr->pn_frag[frag + 1]);
|
|
|
|
frag++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Handle special case: we used up all 16 fragments,
|
|
|
|
* but we have more mbufs left in the chain. Copy the
|
|
|
|
* data into an mbuf cluster. Note that we don't
|
|
|
|
* bother clearing the values in the other fragment
|
|
|
|
* pointers/counters; it wouldn't gain us anything,
|
|
|
|
* and would waste cycles.
|
|
|
|
*/
|
|
|
|
if (m != NULL) {
|
|
|
|
struct mbuf *m_new = NULL;
|
|
|
|
|
|
|
|
MGETHDR(m_new, M_DONTWAIT, MT_DATA);
|
|
|
|
if (m_new == NULL) {
|
|
|
|
printf("pn%d: no memory for tx list", sc->pn_unit);
|
|
|
|
return(1);
|
|
|
|
}
|
|
|
|
if (m_head->m_pkthdr.len > MHLEN) {
|
|
|
|
MCLGET(m_new, M_DONTWAIT);
|
|
|
|
if (!(m_new->m_flags & M_EXT)) {
|
|
|
|
m_freem(m_new);
|
|
|
|
printf("pn%d: no memory for tx list",
|
|
|
|
sc->pn_unit);
|
|
|
|
return(1);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
m_copydata(m_head, 0, m_head->m_pkthdr.len,
|
|
|
|
mtod(m_new, caddr_t));
|
|
|
|
m_new->m_pkthdr.len = m_new->m_len = m_head->m_pkthdr.len;
|
|
|
|
m_freem(m_head);
|
|
|
|
m_head = m_new;
|
|
|
|
f = &c->pn_ptr->pn_frag[0];
|
|
|
|
f->pn_data = vtophys(mtod(m_new, caddr_t));
|
|
|
|
f->pn_ctl = total_len = m_new->m_len;
|
|
|
|
f->pn_ctl |= PN_TXCTL_TLINK|PN_TXCTL_FIRSTFRAG;
|
|
|
|
frag = 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
c->pn_mbuf = m_head;
|
|
|
|
c->pn_lastdesc = frag - 1;
|
1999-03-27 20:41:25 +00:00
|
|
|
PN_TXCTL(c) |= PN_TXCTL_LASTFRAG|PN_TXCTL_FINT;
|
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
|
|
|
PN_TXNEXT(c) = vtophys(&c->pn_nextdesc->pn_ptr->pn_frag[0]);
|
|
|
|
|
|
|
|
return(0);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Main transmit routine. To avoid having to do mbuf copies, we put pointers
|
|
|
|
* to the mbuf data regions directly in the transmit lists. We also save a
|
|
|
|
* copy of the pointers since the transmit list fragment pointers are
|
|
|
|
* physical addresses.
|
|
|
|
*/
|
|
|
|
|
|
|
|
static void pn_start(ifp)
|
|
|
|
struct ifnet *ifp;
|
|
|
|
{
|
|
|
|
struct pn_softc *sc;
|
|
|
|
struct mbuf *m_head = NULL;
|
|
|
|
struct pn_chain *cur_tx = NULL, *start_tx;
|
|
|
|
|
|
|
|
sc = ifp->if_softc;
|
|
|
|
|
|
|
|
if (sc->pn_autoneg) {
|
|
|
|
sc->pn_tx_pend = 1;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check for an available queue slot. If there are none,
|
|
|
|
* punt.
|
|
|
|
*/
|
|
|
|
if (sc->pn_cdata.pn_tx_free->pn_mbuf != NULL) {
|
|
|
|
ifp->if_flags |= IFF_OACTIVE;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
start_tx = sc->pn_cdata.pn_tx_free;
|
|
|
|
|
|
|
|
while(sc->pn_cdata.pn_tx_free->pn_mbuf == NULL) {
|
|
|
|
IF_DEQUEUE(&ifp->if_snd, m_head);
|
|
|
|
if (m_head == NULL)
|
|
|
|
break;
|
|
|
|
|
|
|
|
/* Pick a descriptor off the free list. */
|
|
|
|
cur_tx = sc->pn_cdata.pn_tx_free;
|
|
|
|
sc->pn_cdata.pn_tx_free = cur_tx->pn_nextdesc;
|
|
|
|
|
|
|
|
/* Pack the data into the descriptor. */
|
|
|
|
pn_encap(sc, cur_tx, m_head);
|
|
|
|
|
|
|
|
if (cur_tx != start_tx)
|
|
|
|
PN_TXOWN(cur_tx) = PN_TXSTAT_OWN;
|
|
|
|
|
1999-07-06 19:23:32 +00:00
|
|
|
#if NBPF > 0
|
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
|
|
|
/*
|
|
|
|
* If there's a BPF listener, bounce a copy of this frame
|
|
|
|
* to him.
|
|
|
|
*/
|
|
|
|
if (ifp->if_bpf)
|
|
|
|
bpf_mtap(ifp, cur_tx->pn_mbuf);
|
|
|
|
#endif
|
1999-03-27 20:41:25 +00:00
|
|
|
PN_TXOWN(cur_tx) = PN_TXSTAT_OWN;
|
|
|
|
CSR_WRITE_4(sc, PN_TXSTART, 0xFFFFFFFF);
|
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
|
|
|
}
|
|
|
|
|
1998-12-05 02:21:44 +00:00
|
|
|
/*
|
|
|
|
* If there are no packets queued, bail.
|
|
|
|
*/
|
|
|
|
if (cur_tx == NULL)
|
|
|
|
return;
|
|
|
|
|
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
|
|
|
sc->pn_cdata.pn_tx_tail = cur_tx;
|
|
|
|
|
1999-03-27 20:41:25 +00:00
|
|
|
if (sc->pn_cdata.pn_tx_head == NULL)
|
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
|
|
|
sc->pn_cdata.pn_tx_head = start_tx;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Set a timeout in case the chip goes out to lunch.
|
|
|
|
*/
|
|
|
|
ifp->if_timer = 5;
|
|
|
|
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void pn_init(xsc)
|
|
|
|
void *xsc;
|
|
|
|
{
|
|
|
|
struct pn_softc *sc = xsc;
|
|
|
|
struct ifnet *ifp = &sc->arpcom.ac_if;
|
|
|
|
u_int16_t phy_bmcr = 0;
|
|
|
|
int s;
|
|
|
|
|
|
|
|
if (sc->pn_autoneg)
|
|
|
|
return;
|
|
|
|
|
|
|
|
s = splimp();
|
|
|
|
|
|
|
|
if (sc->pn_pinfo != NULL)
|
|
|
|
phy_bmcr = pn_phy_readreg(sc, PHY_BMCR);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Cancel pending I/O and free all RX/TX buffers.
|
|
|
|
*/
|
|
|
|
pn_stop(sc);
|
|
|
|
pn_reset(sc);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Set cache alignment and burst length.
|
|
|
|
*/
|
1999-04-13 17:29:55 +00:00
|
|
|
CSR_WRITE_4(sc, PN_BUSCTL, PN_BUSCTL_MUSTBEONE|PN_BUSCTL_ARBITRATION);
|
|
|
|
PN_SETBIT(sc, PN_BUSCTL, PN_BURSTLEN_16LONG);
|
1999-04-10 18:44:53 +00:00
|
|
|
switch(sc->pn_cachesize) {
|
|
|
|
case 32:
|
|
|
|
PN_SETBIT(sc, PN_BUSCTL, PN_CACHEALIGN_32LONG);
|
|
|
|
break;
|
|
|
|
case 16:
|
|
|
|
PN_SETBIT(sc, PN_BUSCTL, PN_CACHEALIGN_16LONG);
|
|
|
|
break;
|
|
|
|
case 8:
|
|
|
|
PN_SETBIT(sc, PN_BUSCTL, PN_CACHEALIGN_8LONG);
|
|
|
|
break;
|
|
|
|
case 0:
|
|
|
|
default:
|
|
|
|
PN_SETBIT(sc, PN_BUSCTL, PN_CACHEALIGN_NONE);
|
|
|
|
break;
|
|
|
|
}
|
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
|
|
|
|
|
|
|
PN_CLRBIT(sc, PN_NETCFG, PN_NETCFG_TX_IMMEDIATE);
|
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
|
|
|
PN_CLRBIT(sc, PN_NETCFG, PN_NETCFG_NO_RXCRC);
|
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
|
|
|
PN_CLRBIT(sc, PN_NETCFG, PN_NETCFG_HEARTBEAT);
|
|
|
|
PN_CLRBIT(sc, PN_NETCFG, PN_NETCFG_STORENFWD);
|
|
|
|
PN_CLRBIT(sc, PN_NETCFG, PN_NETCFG_TX_BACKOFF);
|
|
|
|
|
|
|
|
PN_CLRBIT(sc, PN_NETCFG, PN_NETCFG_TX_THRESH);
|
|
|
|
PN_SETBIT(sc, PN_NETCFG, PN_TXTHRESH_72BYTES);
|
|
|
|
|
1999-04-10 18:44:53 +00:00
|
|
|
if (sc->pn_pinfo == NULL) {
|
|
|
|
PN_CLRBIT(sc, PN_NETCFG, PN_NETCFG_MIIENB);
|
|
|
|
PN_SETBIT(sc, PN_NETCFG, PN_NETCFG_TX_BACKOFF);
|
|
|
|
} else {
|
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
|
|
|
PN_SETBIT(sc, PN_NETCFG, PN_NETCFG_MIIENB);
|
|
|
|
PN_SETBIT(sc, PN_ENDEC, PN_ENDEC_JABBERDIS);
|
|
|
|
}
|
|
|
|
|
1999-04-10 18:44:53 +00:00
|
|
|
pn_setcfg(sc, sc->ifmedia.ifm_media);
|
|
|
|
|
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
|
|
|
/* Init circular RX list. */
|
|
|
|
if (pn_list_rx_init(sc) == ENOBUFS) {
|
|
|
|
printf("pn%d: initialization failed: no "
|
|
|
|
"memory for rx buffers\n", sc->pn_unit);
|
|
|
|
pn_stop(sc);
|
|
|
|
(void)splx(s);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Init tx descriptors.
|
|
|
|
*/
|
|
|
|
pn_list_tx_init(sc);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Load the address of the RX list.
|
|
|
|
*/
|
|
|
|
CSR_WRITE_4(sc, PN_RXADDR, vtophys(sc->pn_cdata.pn_rx_head->pn_ptr));
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Load the RX/multicast filter.
|
|
|
|
*/
|
|
|
|
pn_setfilt(sc);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Enable interrupts.
|
|
|
|
*/
|
|
|
|
CSR_WRITE_4(sc, PN_IMR, PN_INTRS);
|
|
|
|
CSR_WRITE_4(sc, PN_ISR, 0xFFFFFFFF);
|
|
|
|
|
|
|
|
/* Enable receiver and transmitter. */
|
|
|
|
PN_SETBIT(sc, PN_NETCFG, PN_NETCFG_TX_ON|PN_NETCFG_RX_ON);
|
|
|
|
CSR_WRITE_4(sc, PN_RXSTART, 0xFFFFFFFF);
|
|
|
|
|
|
|
|
/* Restore state of BMCR */
|
|
|
|
if (sc->pn_pinfo != NULL)
|
|
|
|
pn_phy_writereg(sc, PHY_BMCR, phy_bmcr);
|
|
|
|
|
|
|
|
ifp->if_flags |= IFF_RUNNING;
|
|
|
|
ifp->if_flags &= ~IFF_OACTIVE;
|
|
|
|
|
|
|
|
(void)splx(s);
|
|
|
|
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Set media options.
|
|
|
|
*/
|
|
|
|
static int pn_ifmedia_upd(ifp)
|
|
|
|
struct ifnet *ifp;
|
|
|
|
{
|
|
|
|
struct pn_softc *sc;
|
|
|
|
struct ifmedia *ifm;
|
|
|
|
|
|
|
|
sc = ifp->if_softc;
|
|
|
|
ifm = &sc->ifmedia;
|
|
|
|
|
|
|
|
if (IFM_TYPE(ifm->ifm_media) != IFM_ETHER)
|
|
|
|
return(EINVAL);
|
|
|
|
|
1999-04-10 18:44:53 +00:00
|
|
|
if (IFM_SUBTYPE(ifm->ifm_media) == IFM_AUTO) {
|
|
|
|
if (sc->pn_pinfo == NULL)
|
|
|
|
pn_autoneg(sc, PN_FLAG_SCHEDDELAY, 1);
|
|
|
|
else
|
|
|
|
pn_autoneg_mii(sc, PN_FLAG_SCHEDDELAY, 1);
|
|
|
|
} else {
|
|
|
|
if (sc->pn_pinfo == NULL)
|
|
|
|
pn_setmode(sc, ifm->ifm_media);
|
|
|
|
else
|
|
|
|
pn_setmode_mii(sc, ifm->ifm_media);
|
|
|
|
}
|
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
|
|
|
|
|
|
|
return(0);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Report current media status.
|
|
|
|
*/
|
|
|
|
static void pn_ifmedia_sts(ifp, ifmr)
|
|
|
|
struct ifnet *ifp;
|
|
|
|
struct ifmediareq *ifmr;
|
|
|
|
{
|
|
|
|
struct pn_softc *sc;
|
|
|
|
u_int16_t advert = 0, ability = 0;
|
|
|
|
|
|
|
|
sc = ifp->if_softc;
|
|
|
|
|
|
|
|
ifmr->ifm_active = IFM_ETHER;
|
|
|
|
|
1999-04-14 19:40:08 +00:00
|
|
|
if (sc->pn_pinfo == NULL) {
|
|
|
|
if (CSR_READ_4(sc, PN_NETCFG) & PN_NETCFG_SPEEDSEL)
|
|
|
|
ifmr->ifm_active = IFM_ETHER|IFM_10_T;
|
|
|
|
else
|
|
|
|
ifmr->ifm_active = IFM_ETHER|IFM_100_TX;
|
|
|
|
if (CSR_READ_4(sc, PN_NETCFG) & PN_NETCFG_FULLDUPLEX)
|
|
|
|
ifmr->ifm_active |= IFM_FDX;
|
|
|
|
else
|
|
|
|
ifmr->ifm_active |= IFM_HDX;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
if (!(pn_phy_readreg(sc, PHY_BMCR) & PHY_BMCR_AUTONEGENBL)) {
|
|
|
|
if (pn_phy_readreg(sc, PHY_BMCR) & PHY_BMCR_SPEEDSEL)
|
|
|
|
ifmr->ifm_active = IFM_ETHER|IFM_100_TX;
|
|
|
|
else
|
|
|
|
ifmr->ifm_active = IFM_ETHER|IFM_10_T;
|
|
|
|
if (pn_phy_readreg(sc, PHY_BMCR) & PHY_BMCR_DUPLEX)
|
|
|
|
ifmr->ifm_active |= IFM_FDX;
|
|
|
|
else
|
|
|
|
ifmr->ifm_active |= IFM_HDX;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
ability = pn_phy_readreg(sc, PHY_LPAR);
|
|
|
|
advert = pn_phy_readreg(sc, PHY_ANAR);
|
|
|
|
if (advert & PHY_ANAR_100BT4 &&
|
|
|
|
ability & PHY_ANAR_100BT4) {
|
|
|
|
ifmr->ifm_active = IFM_ETHER|IFM_100_T4;
|
|
|
|
} else if (advert & PHY_ANAR_100BTXFULL &&
|
|
|
|
ability & PHY_ANAR_100BTXFULL) {
|
|
|
|
ifmr->ifm_active = IFM_ETHER|IFM_100_TX|IFM_FDX;
|
|
|
|
} else if (advert & PHY_ANAR_100BTXHALF &&
|
|
|
|
ability & PHY_ANAR_100BTXHALF) {
|
|
|
|
ifmr->ifm_active = IFM_ETHER|IFM_100_TX|IFM_HDX;
|
|
|
|
} else if (advert & PHY_ANAR_10BTFULL &&
|
|
|
|
ability & PHY_ANAR_10BTFULL) {
|
|
|
|
ifmr->ifm_active = IFM_ETHER|IFM_10_T|IFM_FDX;
|
|
|
|
} else if (advert & PHY_ANAR_10BTHALF &&
|
|
|
|
ability & PHY_ANAR_10BTHALF) {
|
|
|
|
ifmr->ifm_active = IFM_ETHER|IFM_10_T|IFM_HDX;
|
|
|
|
}
|
|
|
|
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int pn_ioctl(ifp, command, data)
|
|
|
|
struct ifnet *ifp;
|
|
|
|
u_long command;
|
|
|
|
caddr_t data;
|
|
|
|
{
|
|
|
|
struct pn_softc *sc = ifp->if_softc;
|
|
|
|
struct ifreq *ifr = (struct ifreq *) data;
|
|
|
|
int s, error = 0;
|
|
|
|
|
|
|
|
s = splimp();
|
|
|
|
|
|
|
|
switch(command) {
|
|
|
|
case SIOCSIFADDR:
|
|
|
|
case SIOCGIFADDR:
|
|
|
|
case SIOCSIFMTU:
|
|
|
|
error = ether_ioctl(ifp, command, data);
|
|
|
|
break;
|
|
|
|
case SIOCSIFFLAGS:
|
|
|
|
if (ifp->if_flags & IFF_UP) {
|
|
|
|
pn_init(sc);
|
|
|
|
} else {
|
|
|
|
if (ifp->if_flags & IFF_RUNNING)
|
|
|
|
pn_stop(sc);
|
|
|
|
}
|
|
|
|
error = 0;
|
|
|
|
break;
|
|
|
|
case SIOCADDMULTI:
|
|
|
|
case SIOCDELMULTI:
|
|
|
|
pn_init(sc);
|
|
|
|
error = 0;
|
|
|
|
break;
|
|
|
|
case SIOCGIFMEDIA:
|
|
|
|
case SIOCSIFMEDIA:
|
|
|
|
error = ifmedia_ioctl(ifp, ifr, &sc->ifmedia, command);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
error = EINVAL;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
(void)splx(s);
|
|
|
|
|
|
|
|
return(error);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void pn_watchdog(ifp)
|
|
|
|
struct ifnet *ifp;
|
|
|
|
{
|
|
|
|
struct pn_softc *sc;
|
|
|
|
|
|
|
|
sc = ifp->if_softc;
|
|
|
|
|
|
|
|
if (sc->pn_autoneg) {
|
1999-04-10 18:44:53 +00:00
|
|
|
if (sc->pn_pinfo == NULL)
|
|
|
|
pn_autoneg(sc, PN_FLAG_DELAYTIMEO, 1);
|
|
|
|
else
|
|
|
|
pn_autoneg_mii(sc, PN_FLAG_DELAYTIMEO, 1);
|
1999-07-28 02:19:52 +00:00
|
|
|
if (!(ifp->if_flags & IFF_UP))
|
|
|
|
pn_stop(sc);
|
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
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
ifp->if_oerrors++;
|
|
|
|
printf("pn%d: watchdog timeout\n", sc->pn_unit);
|
|
|
|
|
|
|
|
if (!(pn_phy_readreg(sc, PHY_BMSR) & PHY_BMSR_LINKSTAT))
|
|
|
|
printf("pn%d: no carrier - transceiver cable problem?\n",
|
|
|
|
sc->pn_unit);
|
|
|
|
pn_stop(sc);
|
|
|
|
pn_reset(sc);
|
|
|
|
pn_init(sc);
|
|
|
|
|
|
|
|
if (ifp->if_snd.ifq_head != NULL)
|
|
|
|
pn_start(ifp);
|
|
|
|
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Stop the adapter and free any mbufs allocated to the
|
|
|
|
* RX and TX lists.
|
|
|
|
*/
|
|
|
|
static void pn_stop(sc)
|
|
|
|
struct pn_softc *sc;
|
|
|
|
{
|
|
|
|
register int i;
|
|
|
|
struct ifnet *ifp;
|
|
|
|
|
|
|
|
ifp = &sc->arpcom.ac_if;
|
|
|
|
ifp->if_timer = 0;
|
|
|
|
|
|
|
|
PN_CLRBIT(sc, PN_NETCFG, (PN_NETCFG_RX_ON|PN_NETCFG_TX_ON));
|
|
|
|
CSR_WRITE_4(sc, PN_IMR, 0x00000000);
|
|
|
|
CSR_WRITE_4(sc, PN_TXADDR, 0x00000000);
|
|
|
|
CSR_WRITE_4(sc, PN_RXADDR, 0x00000000);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Free data in the RX lists.
|
|
|
|
*/
|
|
|
|
for (i = 0; i < PN_RX_LIST_CNT; i++) {
|
|
|
|
if (sc->pn_cdata.pn_rx_chain[i].pn_mbuf != NULL) {
|
|
|
|
m_freem(sc->pn_cdata.pn_rx_chain[i].pn_mbuf);
|
|
|
|
sc->pn_cdata.pn_rx_chain[i].pn_mbuf = NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
bzero((char *)&sc->pn_ldata->pn_rx_list,
|
|
|
|
sizeof(sc->pn_ldata->pn_rx_list));
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Free the TX list buffers.
|
|
|
|
*/
|
|
|
|
for (i = 0; i < PN_TX_LIST_CNT; i++) {
|
|
|
|
if (sc->pn_cdata.pn_tx_chain[i].pn_mbuf != NULL) {
|
|
|
|
m_freem(sc->pn_cdata.pn_tx_chain[i].pn_mbuf);
|
|
|
|
sc->pn_cdata.pn_tx_chain[i].pn_mbuf = NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
bzero((char *)&sc->pn_ldata->pn_tx_list,
|
|
|
|
sizeof(sc->pn_ldata->pn_tx_list));
|
|
|
|
|
|
|
|
ifp->if_flags &= ~(IFF_RUNNING | IFF_OACTIVE);
|
|
|
|
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Stop all chip I/O so that the kernel's probe routines don't
|
|
|
|
* get confused by errant DMAs when rebooting.
|
|
|
|
*/
|
1999-07-28 02:19:52 +00:00
|
|
|
static void pn_shutdown(dev)
|
|
|
|
device_t dev;
|
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
|
|
|
{
|
1999-07-28 02:19:52 +00:00
|
|
|
struct pn_softc *sc;
|
|
|
|
|
|
|
|
sc = device_get_softc(dev);
|
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
|
|
|
|
|
|
|
pn_stop(sc);
|
|
|
|
|
|
|
|
return;
|
|
|
|
}
|