864 Commits

Author SHA1 Message Date
julian
bd874070d8 remove some unused variables 1999-01-11 22:49:16 +00:00
julian
cfa1742c7a Add support for the Cyrix Cx5530 PCI/ISA bridge which also includes
a PCI UDMA IDE controller.
1999-01-11 22:14:23 +00:00
wpaul
8d57d11ab2 Tweak the vr_start() and vr_rxeof() routines a little to improve
performance and reliability a little. There was a condition before
where transmission would stall during periods of heavy traffic
exchange between two hosts. Also set the 'want interrupt' bit in
receive descriptor control words.
1999-01-10 18:51:49 +00:00
mjacob
da7bad3421 Amazingly stupid forgetfullness had me forgetting to turn on FIFO bursts
for the 1XX0 cards. That cost > 50% performance.
1999-01-10 02:45:51 +00:00
wpaul
84a9b3dd33 Add driver support (and man page) for PCI fast ethernet cards based
on the ASIX AX88140A chip. Update /sys/conf/files, RELNOTES.TXT,
/sys/i388/i386/userconfig.c, sysinstall/devices.c, GENERIC and LINT
accordingly.

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

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

Also updated RELNOTEX.TXT to mention that the SVEC PN102TX is supported
by the Macronix driver (assuming you actually have an SVEC PN102TX with
a Macronix chip on it; I tried to order a PN102TX once and got a box
labeled 'Hawking Technology PN102TX' that had a VIA Rhine board inside
it).
1999-01-09 18:12:08 +00:00
kjc
fe2dbd0b73 cleanup: remove part of the code for 2.1.
add two functions to get the MAC address of the card.

Obtained from: ALTQ
1999-01-09 12:56:17 +00:00
wpaul
7bcec4ef4c Add some tweaks to mx_mii_readreg(), mx_phy_readreg(), mx_phy_writereg()
and mx_setcfg() so that we can read the internal MII registers on the
MX98713 chip correctly. With these changes, media autoselection now
works correctly on the original 98713. All Macronix chips should now
be properly supported (unless there's a surprise waiting in the 98725).

Thanks to Ulf Zimmermann for providing a 98713 board.
1999-01-06 17:30:06 +00:00
wpaul
169d9aa405 GRRRR! Apparently, the promiscuous mode chip bug which I thought was
isolated to revision 33 PNIC chips is also present in revision 32 chips.
Cards with rev. 32 chips include the LinkSys LNE100TX and the Matrox
FastNIC 10/100. This accounts for all the cards that I have to test
with.

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

This commit enables the promiscuous mode software workaround code for
both revison 32 and revision 33 chips. It's possible all of the PNIC
chips suffer from this bug, but these are the only two revs where I
know for a fact it exists.
1999-01-05 00:59:08 +00:00
wpaul
eaf34b61de Minor bug: in the case where allocating a fresh mbuf for the receive ring
fails, we need to set the descriptor status word so that the 'OWN' bit
is set again so that the chip can reuse it. Previously, this wasn't being
done.
1999-01-03 02:05:21 +00:00
wpaul
ef9b43fe9a 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
luigi
33a313ee9d Add Joachim Kuebart's ES1370 driver. With my Shuttle HOT-255 card,
this has a problem with capture but i am not sure if it is related
to the mixer or what else.
But in the meantime, this is ok to listen to mpegs.

I also have a much simpler version of the driver in the works which
reuses a lot more of the existing "pcm" routines.  Next year...
1998-12-31 08:14:27 +00:00
hoek
5e720f3594 Silence -Wtrigraph.
Submitted by:	Bradley Dunn <bradley@dunn.org>  (pr: kern/8817)
1998-12-30 00:37:44 +00:00
wpaul
9cf4a5a2e1 Fix the tl_start() routine; sometimes the tl_tx_tail pointer was not
being updated correctly.
1998-12-29 15:39:35 +00:00
mjacob
5c42627795 clarify headers;ansify 1998-12-28 19:24:23 +00:00
foxfair
a90947f54c Turn the VIA chipset ,<<IDE/USB>> controller probing off.
It might cause some problem and something like USB has its
own driver.
1998-12-27 07:59:25 +00:00
wpaul
7378825b0e One more time: another case where we need to trim the CRC manually. 1998-12-24 19:10:05 +00:00
wpaul
4959cd39d9 Grrrr... The RealTek 8139 is yet another chip that includes the ethernet
CRC in received frames, which we need to trim manually.
1998-12-24 18:39:48 +00:00
wpaul
bd6e00f32c The VIA Rhine appears to be yet another chip that always includes the
ethernet CRC in received frames and has no option to turn this behavior
off. Trim the CRC off manually in vr_rxeof().
1998-12-24 18:03:17 +00:00
wpaul
fcf431dd97 Fix a small bug in xl_start(): when queuing a packet onto the end of
an existing chain, don't forget to move xl_tx_tail to point to the new
tail end.
1998-12-24 17:50:34 +00:00
foxfair
a8c2d8d742 Add Matrox Mystique 1064/1164SG chips info. By the datasheet from Matrox,
they use the same value in the VID register.

PR		kern/9137: Matrox Mystique chip name typo error
Submitted by:	Alex D. Chen <dhchen@Canvas.dorm7.nccu.edu.tw>
1998-12-23 14:28:37 +00:00
gibbs
b6ee7c1b3f Staticize the overrun buffer so that they are not shared between
cards of different bus types as each bus type may have a different
bus mapping.

Submitted by:	Eivind Eklund <eivind@yes.no>
1998-12-22 18:14:15 +00:00
msmith
307f62acf1 Check for DMA capbility is against unit,not controller.
Submitted by:	Lee Cremeans <lee@st-lcremean.tidalwave.net>
1998-12-21 08:55:56 +00:00
bde
7674c039cb Remove a vestige of the amd driver.
Forgotten by:	msmith
1998-12-20 15:26:02 +00:00
foxfair
4b4a7fe681 Add more non-Intel family ((new)) chipset, just like VIA technology MVP3
AcerLabs Aladdin-V. It makes the PCI probing work when system booting. I
will try to merge some additional funtion(i.e. wdc1 problem cause tons of
PR appear :<) ASAP if I could.

Remind me if something wrong after committing, thanks!
1998-12-19 16:05:19 +00:00
julian
2a8dd8b3fc Remove the bogus charracters "42" from the beginning of the first line.
looks like "editor turd".
1998-12-19 08:35:30 +00:00
wpaul
6a5ae683b9 Trim the ethernet CRC from received frames manually in wb_rxeof().
The Winbond chip always includes the CRC with every received frame,
and I can't find anything in the Winbond manual that indicates you can
program it not to do this.
1998-12-19 04:19:44 +00:00
msmith
434b0ce442 Fix for bogus BIOS configuration of the 450NX PCI interface on some
systems (eg. Dell 6300).

PR:		kern/8928
Submitted by:	David Malone <dwmalone@maths.tcd.ie>
1998-12-19 02:58:29 +00:00
msmith
da7c7a2e12 Support for Intel 450NX-based systems with more than one PCI bus (ie.
most of them).

Many thanks to Kevin Van Maren for the work here, Intel for lending us
a 450NX system to work this out on, and several other folks for testing
the patches.  See the PR for an extensive discussion of the nature of
the problem and resolution.

PR:		kern/8928
Submitted by:	Kevin Van Maren <vanmaren@fast.cs.utah.edu>
1998-12-19 02:51:22 +00:00
wpaul
e5dfa4c78d Correct the definition for PN_NETCFG_NO_RXCRC: it's 0x20000000, not
0x02000000. This error was causing the chip to always include the
ethernet CRC along with every received frame (the driver turns on
PN_NETCFG_NO_RXCRC, but it was frobbing the wrong bit).
1998-12-18 18:31:34 +00:00
eivind
0a8613d749 vxalloc() can return NULL. Deal with it. 1998-12-16 00:38:57 +00:00
gibbs
147f35e007 Pull in new ccb_hdr list types. 1998-12-15 08:24:45 +00:00
n_hibma
09cea3a47d Removed probe for VIA 82C586B OHCI controller (is done in ohci_pci.c now) 1998-12-14 09:46:31 +00:00
dillon
1b46557c21 probe function changed from returning char * to const char *. 1998-12-14 06:37:37 +00:00
dillon
987bd366d4 Fix uninitialized variable warning by preinitializing 'class' to 0. This
wasn't a bug, just added to silence a warning.
1998-12-14 05:49:04 +00:00
dillon
5e557fc6bd pci_device pd_probe function changed from returning char * to returning
const char *.  Originally I was going to add casts from const char * to
    char * in some of the pci device drivers, but the reality is that the
    pci device probes return constant quoted strings.
1998-12-14 05:47:29 +00:00
wpaul
e4b351684b Silence gcc -Wall -ansi -pedantic.
Pointed out by: Eivind
1998-12-10 19:02:07 +00:00
wpaul
8bc6574c8b Silence gcc -Wall -ansi -pedantic and fix minor bug in xl_txeof().
Pointed out by: Eivind
1998-12-10 16:18:43 +00:00
archie
c1f1caae59 Eliminate compiler warning. 1998-12-10 02:02:30 +00:00
archie
7e681e5e17 Eliminate compiler warning. 1998-12-10 01:52:16 +00:00
eivind
95121431dd Check return value of malloc. 1998-12-09 01:33:03 +00:00
eivind
83a7ac6bd9 Bailing out when malloc returns != NULL will not help anybody. 1998-12-09 01:27:29 +00:00
eivind
52811ba27f Adjust prototype to match definition (by adding a 'const'). 1998-12-09 01:12:18 +00:00
archie
60d13c7a9d The "easy" fixes for compiling the kernel -Wunused: remove unreferenced static
and local variables, goto labels, and functions declared but not defined.
1998-12-07 21:58:50 +00:00
wpaul
d5e7be6625 if_rl.c: make a small tweak to properly handle the Accton MPX 5030/5038
as a RealTek 8139
if_rlreg.h: use bus_space_read_X() in CSR_READ_X() macros instead of
            directly calling inb()/outb() etc...
rl.4 + RELNOTES.TXT: mention that SMC EtherEZ PCI 1211-TX is supported
                     by the RealTek driver
1998-12-07 00:35:06 +00:00
wpaul
f72fa84f93 Add sanity check to foo_start() routines: in the unlikely (though
apparently possible) event that the transmit start routine is
called with and empty if_snd queue, bail out instead of dereferencing
unilitialized transmit list pointers and panicking.
1998-12-05 02:21:44 +00:00
mjacob
0ff3e17e01 trivial header fix 1998-12-05 00:07:04 +00:00
archie
982e80577d Examine all occurrences of sprintf(), strcat(), and str[n]cpy()
for possible buffer overflow problems. Replaced most sprintf()'s
with snprintf(); for others cases, added terminating NUL bytes where
appropriate, replaced constants like "16" with sizeof(), etc.

These changes include several bug fixes, but most changes are for
maintainability's sake. Any instance where it wasn't "immediately
obvious" that a buffer overflow could not occur was made safer.

Reviewed by:	Bruce Evans <bde@zeta.org.au>
Reviewed by:	Matthew Dillon <dillon@apollo.backplane.com>
Reviewed by:	Mike Spengler <mks@networkcs.com>
1998-12-04 22:54:57 +00:00
wpaul
1a73567f51 Put back some missing chip identification code that got lost somehow
during a trek through RCS. The Macronix 98713 and 98713A both have the
same PCI device ID but different revision numbers, and we need to be
able to tell one from the other. The 98715 and 98715A chips have the
same device ID as the 98725 chip but different revision numbers, however
we lump them into the same category except when identifying them during
the PCI probe output.

The main reason we need tell the chips apart is that the Macronix app
notes say you have to write a special magic number into one of the
registers in order to put the chip in normal operating mode. The 98713
requires one magic value, while all the others require a different one.
1998-12-04 21:48:12 +00:00
archie
4f36a36aa4 Fix typo: expression needs parentheses
PR:             8280 (3/3 patches contained in this PR)
Submitted by:   Sakari Jalovaara <sja@tekla.fi>
1998-12-04 21:41:18 +00:00
wpaul
dfd7dd0c59 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