summaryrefslogtreecommitdiffstats
path: root/sys/pci/if_pn.c
Commit message (Collapse)AuthorAgeFilesLines
* Simplify the COMPAT_PCI_DRIVER/DATA_SET hack. We can add:peter1999-05-091-6/+2
| | | | | | | | #define COMPAT_PCI_DRIVER(name,data) DATA_SET(pcidevice_set,data) .. to 2.2.x and 3.x if people think it's worth it. Driver writers can do this if it's not defined. (The reason for this is that I'm trying to progressively eliminate use of linker_sets where it hurts modularity and runtime load capability, and these DATA_SET's keep getting in the way.)
* Use COMPAT_PCI_DRIVER() for registration if it exists. This shouldn'tpeter1999-04-241-2/+6
| | | | hurt the driver portability to 3.x too much for where drivers are shared.
* Bring the 'new-bus' to the i386. This extensively changes the way thepeter1999-04-161-2/+8
| | | | | | | | | | | | | | | | | | i386 platform boots, it is no longer ISA-centric, and is fully dynamic. Most old drivers compile and run without modification via 'compatability shims' to enable a smoother transition. eisa, isapnp and pccard* are not yet using the new resource manager. Once fully converted, all drivers will be loadable, including PCI and ISA. (Some other changes appear to have snuck in, including a port of Soren's ATA driver to the Alpha. Soren, back this out if you need to.) This is a checkpoint of work-in-progress, but is quite functional. The bulk of the work was done over the last few years by Doug Rabson and Garrett Wollman. Approved by: core
* Grrr. Make all modes work properly with the 82c168 chip and built-inwpaul1999-04-141-14/+33
| | | | | | | | | | transceiver. Note in the manual page that autoselection doesn't work on the 82c168 because the built-in NWAY support is horribly broken. Manual mode selection works fine, but autoneg is broken for everything except maybe 10Mbps half-duplex. There's no simple way to fix this at the moment, so I have to settle for documenting the bug for now. Fortunately, there aren't anywhere near as many 82c168 boards around as there are 82c169s.
* Some more fixes:wpaul1999-04-131-33/+39
| | | | | | | | | | | | | | | - It turns out that the 'promiscuous mode' bug what I discovered with the PNIC is not restricted to promiscuous mode. I've been doing some remote debugging for someone with a P75 system, and at 100Mbps, the receiver screws up even when the NIC is in normal mode. Thus, enable the workaround for this bug all the time. Note that the workaround is still not enabled for the PNIC II, since I haven't tested one yet. - Set the 'arbitration' bit in the bus configuration register and set the maximum burst size to 16 longwords. This seems to fix problems with transmit corruption on the P75 system mentioned above. (It probably hurts performance a bit too, but I've given up trying to make the PNIC perform well.)
* Grr... don't touch the PN_GEN (general purpose) register in pn_setcfg()wpaul1999-04-121-6/+8
| | | | | unless this is a NIC without an MII-based PHY (i.e. an older LinkSys LNE100TX).
* Minor tweak: move initialiation of busctl register to before setting ofwpaul1999-04-121-3/+3
| | | | the cache alignment bits.
* Enable the promiscuous mode workaround for the PNIC 82c168 chip, whichwpaul1999-04-111-3/+4
| | | | appears to need it.
* Finally add support for the older 82c168 PNIC chip with the built-inwpaul1999-04-101-35/+259
| | | | | | | | transceiver. Thanks to Brian Walenze for donating a NIC with this chip on it (LinkSys didn't really sell that many of them and they're not in production anymore). The driver now distinguishes between the 82c168 and 82c169 when probing. If no MII transceiver is detected, it switches over to using the internal one.
* Fix a line wrap bogon.wpaul1999-03-301-3/+4
|
* Make the xl and pn drivers work on FreeBSD/alpha and add them towpaul1999-03-271-25/+62
| | | | | | | | | | | | | | | sys/alpha/conf/GENERIC. Note: the PNIC ignores the lower few bits of the RX buffer DMA address, which means we have to add yet another kludge to make it happy. Since we can't offset the packet data, we copy the first few bytes of the received data into a separate mbuf with proper alignment. This puts the IP header where it needs to be to prevent unaligned accesses. Also modified the PNIC driver to use a non-interrupt driven TX strategy. This improves performance somewhat on x86/SMP systems where interrupt delivery doesn't seem to be as fast with an SMP kernel as with a UP kernel.
* Add PCI device ID for the PNIC II.wpaul1999-02-261-2/+4
|
* Remember to initialize ifp->if_snd.ifq_maxlen.wpaul1999-02-011-2/+3
|
* GRRRR! Apparently, the promiscuous mode chip bug which I thought waswpaul1999-01-051-3/+3
| | | | | | | | | | | | | | | | | 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.
* This commit adds a software workaround for a hardware bug in certain PNICwpaul1998-12-311-12/+170
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* probe function changed from returning char * to const char *.dillon1998-12-141-4/+4
|
* The "easy" fixes for compiling the kernel -Wunused: remove unreferenced staticarchie1998-12-071-3/+3
| | | | and local variables, goto labels, and functions declared but not defined.
* Add sanity check to foo_start() routines: in the unlikely (thoughwpaul1998-12-051-2/+8
| | | | | | 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.
* An early Christmas present: add driver support for a whole bunch ofwpaul1998-12-041-0/+1822
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.
OpenPOWER on IntegriCloud