Don't document non-bugs in the BUGS section, or anywhere else. It
is not a bug to drop data when overloaded. The compile-time tuning
options turned out to be not very useful, and aren't supported
offically.
Documented the not so new option CY_PCI_FASTINTR.
to implement multi-link ppp over more than one ISP with
the ability to lose ISPs without loss of connectivity.
It *requires* that you either have administrative access
to a machine that's already connected to the 'net or at
least know a really nice person that does.
(QIC) written under 2.X may not be easily read under the current
driver without explicitly setting to variable mode or to the blocksize
these tapes were written under 2.X with.
PR: 6681
similar to the PNIC I (supported by the pn driver). In fact, it's really
a Macronix 98715A with wake on LAN support added. According to LinkSys,
the PNIC II was jointly developed by Lite-On and Macronis. I get the
feeling Macronix did most of the work. (The datasheet has the Macronix
logo on it, and is in fact nearly identical to the 98715 datasheet, except
for the extra wake on LAN registers.) In any case, the PNIC II works just
fine with the Macronix driver.
The changes are:
- Move PCI ID for the PNIC II from the pn driver to the mx driver.
- Mention PNIC II support in mx.4.
- Mention PNIC II support in RELNOTES.TXT and HARDWARE.TXT.
- Mention that the 6Mbps turbo adapters are supported in HARDWARE.TXT
and RELNOTES.TXT and the wi.4 man page
- Mention turbo adapters in the wicontrol.8 man page and provide a
complete table of available transmit speed settings
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.
