| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Notes:
svn path=/head/; revision=48645
|
|
|
|
|
|
|
|
|
|
| |
compiles cleanly on the Alpha. (On the alpha, the port type is an int,
not a short).
Cast a couple of pointers to ints via 'uintptr_t' rather than 'unsigned
int' since uintptr_t is long (64 bit) on Alpha, as are pointers.
Notes:
svn path=/head/; revision=48443
|
|
|
|
|
|
|
|
|
| |
- Clear the IFF_OACTIVE flag when al_txeof() runs down the last TX mbuf chain.
- Mark the workaround for the transmitter stalling bug with
#ifdef AL_TX_STALL_WAR/#endif.
Notes:
svn path=/head/; revision=47528
|
|
|
|
|
|
|
|
| |
broadcast frames' bit, so we don't need any code in al_init() to set/clear
it.
Notes:
svn path=/head/; revision=47376
|
|
|
|
| |
Notes:
svn path=/head/; revision=47351
|
|
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.
Notes:
svn path=/head/; revision=47350
|