This adds support for EtherExpress/16 cards with 16k of RAM, and in the
process adds general support for PIO mode on these cards. This entails
changing the way the i82586 driver handles bus barriers, since it doesn't
allow for strange cases like this.
This has been tested on the i386 port with the 'ix' driver in both
16KB (which was the source of the problem) and 32KB modes, as well
as with the 'ef' driver. I've tested it (briefly) with 'ei' on arm26
as well. In theory, drivers other than 'ix' should follow precisely the
same code paths as before.
Only access board memory using the front-end functions.
Add hook for clearing latched interrupts.
Corrent debugging printf of ethertype on LE systems.
Make it possible to us I82586_DEBUG as a kernel option.
Tested on arm26 and mvme68k.
return 0 instead of EINVAL. In this case, there will only be one media
type, and the upper-level if_media code will ensure that the user is
setting to that type.
This matches changes Jason made a while back to sys/dev/ic/lance.c
directly, call the function pointer (*if_input)(ifp, m). The input routine
expects the packet header to be at the head of the packet, and will adjust
as necessary. Privatize the layer 2 input and output routines, allowing
*_ifattach() to set them up as appropriate.
- "out of resource" errors cause receive buffer chain corruption
- resets can confuse the interrupt handler
- multi-cast setup causes receive buffer chain corruption
- shared memory setup incomplete
* Enhance effiency by avoiding unnecessary shared memory access,
improved handling of receive frame & buffer descriptors, and
introducing an `asynchronous' option when issuing 82586 commands.
* Exclusively use offsets relative to the bus handle representing the shared
memory area to formulate accesses to the chip's data-structures. The
front-ends provide glue functions that cater to the chip's endian-
sensitivity, to perform the actual device access (note: single-byte
accesses are done here using `bus_space_{read,write}_1()').
This concludes the transformation into a bus-independent driver module.
a command to the 82586 for every frame to be transmitted. Instead, a
single command sets off the execution of a chain of commands consisting
of alternate XMITs and NO-OPs, where the link fields in the NO-OPs are
set to loop back onto themselves until the next XMIT is ready to go.
This trick found on a Linux WEB page.
All this induces reasonable transmission performance in my old multibus
adapter. The receiver performance is still abysmal..
bjh21