summaryrefslogtreecommitdiffstats
path: root/sys/pci
Commit message (Collapse)AuthorAgeFilesLines
* Add driver support (and man page) for PCI fast ethernet cards basedwpaul1999-01-092-0/+2731
| | | | | | | | | | | | | | | | | | | | | | | | | | 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).
* cleanup: remove part of the code for 2.1.kjc1999-01-091-36/+128
| | | | | | add two functions to get the MAC address of the card. Obtained from: ALTQ
* Add some tweaks to mx_mii_readreg(), mx_phy_readreg(), mx_phy_writereg()wpaul1999-01-061-4/+18
| | | | | | | | | 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.
* GRRRR! Apparently, the promiscuous mode chip bug which I thought waswpaul1999-01-052-4/+5
| | | | | | | | | | | | | | | | | 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.
* Minor bug: in the case where allocating a fresh mbuf for the receive ringwpaul1999-01-032-8/+6
| | | | | | 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.
* This commit adds a software workaround for a hardware bug in certain PNICwpaul1998-12-312-13/+179
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Add Joachim Kuebart's ES1370 driver. With my Shuttle HOT-255 card,luigi1998-12-312-0/+1261
| | | | | | | | | 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...
* Silence -Wtrigraph.hoek1998-12-302-5/+5
| | | | Submitted by: Bradley Dunn <bradley@dunn.org> (pr: kern/8817)
* Fix the tl_start() routine; sometimes the tl_tx_tail pointer was notwpaul1998-12-291-3/+3
| | | | being updated correctly.
* clarify headers;ansifymjacob1998-12-281-60/+22
|
* Turn the VIA chipset ,<<IDE/USB>> controller probing off.foxfair1998-12-271-6/+1
| | | | | It might cause some problem and something like USB has its own driver.
* One more time: another case where we need to trim the CRC manually.wpaul1998-12-241-2/+11
|
* Grrrr... The RealTek 8139 is yet another chip that includes the ethernetwpaul1998-12-241-4/+13
| | | | CRC in received frames, which we need to trim manually.
* The VIA Rhine appears to be yet another chip that always includes thewpaul1998-12-241-2/+11
| | | | | ethernet CRC in received frames and has no option to turn this behavior off. Trim the CRC off manually in vr_rxeof().
* Fix a small bug in xl_start(): when queuing a packet onto the end ofwpaul1998-12-241-2/+3
| | | | | an existing chain, don't forget to move xl_tx_tail to point to the new tail end.
* Add Matrox Mystique 1064/1164SG chips info. By the datasheet from Matrox,foxfair1998-12-231-2/+2
| | | | | | | 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>
* Staticize the overrun buffer so that they are not shared betweengibbs1998-12-221-4/+4
| | | | | | | cards of different bus types as each bus type may have a different bus mapping. Submitted by: Eivind Eklund <eivind@yes.no>
* Check for DMA capbility is against unit,not controller.msmith1998-12-211-2/+2
| | | | Submitted by: Lee Cremeans <lee@st-lcremean.tidalwave.net>
* Remove a vestige of the amd driver.bde1998-12-201-667/+0
| | | | Forgotten by: msmith
* Add more non-Intel family ((new)) chipset, just like VIA technology MVP3foxfair1998-12-191-9/+37
| | | | | | | | 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!
* Remove the bogus charracters "42" from the beginning of the first line.julian1998-12-191-2/+2
| | | | looks like "editor turd".
* Trim the ethernet CRC from received frames manually in wb_rxeof().wpaul1998-12-191-2/+11
| | | | | | 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.
* Fix for bogus BIOS configuration of the 450NX PCI interface on somemsmith1998-12-191-2/+14
| | | | | | | systems (eg. Dell 6300). PR: kern/8928 Submitted by: David Malone <dwmalone@maths.tcd.ie>
* Support for Intel 450NX-based systems with more than one PCI bus (ie.msmith1998-12-191-1/+54
| | | | | | | | | | | | 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>
* Correct the definition for PN_NETCFG_NO_RXCRC: it's 0x20000000, notwpaul1998-12-181-2/+2
| | | | | | 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).
* vxalloc() can return NULL. Deal with it.eivind1998-12-161-1/+3
|
* Pull in new ccb_hdr list types.gibbs1998-12-151-1/+2
|
* Removed probe for VIA 82C586B OHCI controller (is done in ohci_pci.c now)n_hibma1998-12-141-3/+1
|
* probe function changed from returning char * to const char *.dillon1998-12-1424-75/+75
|
* Fix uninitialized variable warning by preinitializing 'class' to 0. Thisdillon1998-12-141-2/+2
| | | | wasn't a bug, just added to silence a warning.
* pci_device pd_probe function changed from returning char * to returningdillon1998-12-1410-33/+33
| | | | | | 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.
* Silence gcc -Wall -ansi -pedantic.wpaul1998-12-102-71/+65
| | | | Pointed out by: Eivind
* Silence gcc -Wall -ansi -pedantic and fix minor bug in xl_txeof().wpaul1998-12-101-9/+7
| | | | Pointed out by: Eivind
* Eliminate compiler warning.archie1998-12-101-3/+3
|
* Eliminate compiler warning.archie1998-12-101-2/+5
|
* Check return value of malloc.eivind1998-12-091-3/+5
|
* Bailing out when malloc returns != NULL will not help anybody.eivind1998-12-091-2/+2
|
* Adjust prototype to match definition (by adding a 'const').eivind1998-12-091-2/+2
|
* The "easy" fixes for compiling the kernel -Wunused: remove unreferenced staticarchie1998-12-0715-54/+54
| | | | and local variables, goto labels, and functions declared but not defined.
* if_rl.c: make a small tweak to properly handle the Accton MPX 5030/5038wpaul1998-12-072-46/+28
| | | | | | | | 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
* Add sanity check to foo_start() routines: in the unlikely (thoughwpaul1998-12-056-12/+48
| | | | | | 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.
* trivial header fixmjacob1998-12-051-0/+5
|
* Examine all occurrences of sprintf(), strcat(), and str[n]cpy()archie1998-12-045-9/+12
| | | | | | | | | | | | | | 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>
* Put back some missing chip identification code that got lost somehowwpaul1998-12-042-8/+15
| | | | | | | | | | | | | | 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.
* Fix typo: expression needs parenthesesarchie1998-12-041-3/+3
| | | | | PR: 8280 (3/3 patches contained in this PR) Submitted by: Sakari Jalovaara <sja@tekla.fi>
* An early Christmas present: add driver support for a whole bunch ofwpaul1998-12-048-0/+10836
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* The Neomagic chip is a 2160 not a 3160.sos1998-12-011-2/+2
|
* Alias Adaptec as a vendor of Cogent NICs.msmith1998-11-281-1/+2
|
* Removed probes for USB chips 82371xB (done in dev/pci/uhci_pci.c)n_hibma1998-11-261-5/+1
|
* Add missing return statement to rl_phy_writereg(). This bug didn't actuallywpaul1998-11-201-2/+3
| | | | | | hurt anything, but it's still a bug. Pointed out by: Jason Wright <jason@thought.net>
OpenPOWER on IntegriCloud