on the following PRO/100 chips:
* i82558 step A4
* i82558 step B0
* i82559 step A0
* i82559S step A
* i82550
* i82550 step C
The interrupt delay is configurable on all microcodable chips. The
maximum "bundle" size (packet count) is configurable on all but the
i82558.
The microcode is enabled by setting IFF_LINK0 on the interface.
Derived from code in FreeBSD.
- Add some additional config block bits for the i82558/i82559.
- Change the config block template to only fill in the must-be-one
reserved bits, leave fxp_init() to fill in all the important things.
- On the i82558/i82559, we can use "Receive Long Frames" rather than
"Save Bad Frames" to support the VLAN MTU.
- Use 802.3x flow control on the i82558/i82559. This is all handled
transparently by the hardware. When in promiscuous mode, allow
wire-watchers to see the flow control frames.
- Use the Extended TxCB format on the i82558/i82559. This places two
Transmit Buffer Descriptors directly in the TxCB, which should cover
the vast majority of packets transmitted. This saves PCI transactions
that would otherwise be required to fetch the TBD list.
With the tansmit queue length changes from yesterday, this gets us up to
11.5MB/s TCP transmit speed, out of an absolute maximum of 12MB/s possible
on a 100Mb/s link.
have _detach() functions:
Ensure that softc keeps state about whether the attach succeeded,
and make the detach function return immediately if the attach did
not complete.
timeout()/untimeout() API:
- Clients supply callout handle storage, thus eliminating problems of
resource allocation.
- Insertion and removal of callouts is constant time, important as
this facility is used quite a lot in the kernel.
The old timeout()/untimeout() API has been removed from the kernel.
Symptoms: system would crash with "data modified on free list" pool
panic from the mbuf cluster pool shortly after a resume. The cluster
in question contained a valid 82557 receive descriptor and an IP
packet. Happened sporadically in normal use. Easiest way for me to
reproduce it was to run tcpdump and a flood ping and do a
suspend/resume cycle or two.
Changes:
- in interrupt handler, if the interface isn't in IFF_RUNNING state,
just ack interrupts and return; don't try to receive packets, queue
new descriptors, etc., etc.,
- add power control hook to take interface down on suspend,
and restart it (if it was up) on resume.
- tweaks to fxp_stop and fxp_shutdown to avoid recursive panics due
to the (now fixed) bug.
anyway, take advantage of this and greatly simplify the programming
of the multicast filter. This solves the last reported "device timeout"
problem with this driver.
to the EPIC/100 driver's (adjusting for the fact that Intel Ethernet chips
are from Pluto):
* Don't allocate receive buffers until the interface is actually brought
up, and release all of them if the interface is taken down.
* Add a knob (defaults to off) which will copy an incoming packet to
a single header mbuf if it is small enough to fit in one, rather than
burning an entire cluster on it. Note that this change will be mostly
moot if/when sbcompress() is changed to handle compressing clusters.
Simplify some of the receive list logic:
* Rather than using a homegrown queue and additional software RX descriptors,
use an ifqueue to queue receive buffers, and M_{GET,SET}CTX() to hook DMA
maps and receive buffers together.
Clean up a bit:
* Macroize a bunch of things to make the code a bit easier to follow.
