summaryrefslogtreecommitdiffstats
path: root/share/man/man4/man4.i386/al.4
Commit message (Collapse)AuthorAgeFilesLines
* Deactivate manpages repo-copied to man4 directory (all these driversphantom1999-11-151-152/+0
| | | | not i386 specific anymore -- move them to appropriate place)
* Spruce up the ADMtek driver: conver to newbus, miibus and add supportwpaul1999-09-221-6/+6
| | | | | | | | | | | | | | | for the AN985 "Centaur" chip, which is apparently the next genetation of the "Comet." The AN985 is also a tulip clone and is similar to the AL981 except that it uses a 99C66 EEPROM and a serial MII interface (instead of direct access to the PHY registers). Also updated various documentation to mention the AN985 and created a loadable module. I don't think there are any cards that use this chip on the market yet: the datasheet I got from ADMtek has boxes with big X's in them where the diagrams should be, and the sample boards I got have chips without any artwork on them.
* $Id$ -> $FreeBSD$peter1999-08-281-1/+1
|
* Various man page cleanup:mpp1999-08-151-2/+2
| | | | | | | | | | - Sort xrefs - FreeBSD.ORG -> FreeBSD.org - Be consistent with section names as outlined in mdoc(7). - Other misc mdoc cleanup. PR: doc/13144 Submitted by: Alexey M. Zelkin <phantom@cris.net>
* Fix a couple of small grammatical errors.wpaul1999-05-211-2/+2
|
* This commit adds driver support for PCI fast ethernet cards based on thewpaul1999-05-211-0/+152
ADMtek AL981 "Comet" chipset. The AL981 is yet another DEC tulip clone, except with simpler receive filter options. The AL981 has a built-in transceiver, power management support, wake on LAN and flow control. This chip performs extremely well; it's on par with the ASIX chipset in terms of speed, which is pretty good (it can do 11.5MB/sec with TCP easily). I would have committed this driver sooner, except I ran into one problem with the AL981 that required a workaround. When the chip is transmitting at full speed, it will sometimes wedge if you queue a series of packets that wrap from the end of the transmit descriptor list back to the beginning. I can't explain why this happens, and none of the other tulip clones behave this way. The workaround this is to just watch for the end of the transmit ring and make sure that al_start() breaks out of its packet queuing loop and waiting until the current batch of transmissions completes before wrapping back to the start of the ring. Fortunately, this does not significantly impact transmit performance. This is one of those things that takes weeks of analysis just to come up with two or three lines of code changes.
OpenPOWER on IntegriCloud