Commit Graph

5 Commits

Author SHA1 Message Date
Matt Jacob
3fdd89c865 Very early and very *very* lightly tested support for LIVENGOOD chipset
(followon to WISEMAN). Presumably some flavors are also no multimode copper
as well.
2000-10-16 23:08:45 +00:00
Matt Jacob
a46c6a5114 Fix this driver to (finally) work with switches. Some more black
magic from the linux driver.
2000-06-16 06:28:31 +00:00
Matt Jacob
110bbc0dcf define jumbo packet size 2000-01-25 04:11:33 +00:00
Matt Jacob
e2e6935a6f Add in a define for the optimal cache line size. 2000-01-23 01:39:13 +00:00
Matt Jacob
78dda2ae0c Add first pass of the Intel Gigabit Ethernet (wiseman) driver. This
driver seems relatively functional, but could use some souping up,
particularly in the performance area. This has both NetBSD and FreeBSD
attachment code and a fair amount of effort has been put into making
it easy to port to different *BSD platforms.

The basic design is a one tfd per mbuf transmit (with no transmit
related interrupts- tfds are gc'd as needed). The receive ring
uses a 2K buffer per rfd with a +2 byte adjust for the ethernet
header (so the payload is aligned). There's support that *almost*
works for doing large packets- the rfd chaining code works, but there's
some problem with getting good checksums at the IP reassembly level
(ditto for doing short tfd's too).

The chip has support for TCP checksums insertion for transmit and
TCP checksum calculation on receive (for both you have to do some
appropriate backoff && twiddling), but this isn't in place.

This is nearly entirely reverse engineered from the released Intel
driver, so there's a lot of "We have to do this but do not know why"
stuff. There is somebody who has the chip specs who works in FreeBSD
but they're being a bit standoffish about even sharing hints which
is somewhat annoying. It's also apparent that all I had to work with
were the first rev boards.

This driver has been lightly tested on intel && alpha, but only
point-to-point. There may be some issues with switches- use of
boot time environment variables that override EEPROM settings
(e.g., 'set wx_ilos=1' which inverts the sense of optical signal
loss) may help with this.

I had this out for review for three weeks, and nobody said anything
negative or positive, ergo, this checkin has no 'reviewed by' field
which I would have preferred.
2000-01-04 11:12:42 +00:00