- 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.
reception and saving other "bad frames" (i.e. ones that are larger
than the standard Ethernet frame length) if we have VLANs configured
on the interface.
memory that is explicitly mapped in a DMA-coherent manner, we must
make sure to PREREAD sync the RFA after noticing a clear "complete"
bit. Without this, the clear bit will linger in the cache, and the
CPU will not notice when the chip updates the bit via DMA later.
From Izumi Tsutsui on port-arm32@netbsd.org.
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.
values are less machine-dependant. Fixes port-i386/10141, where
spurrious timeouts were being seen.
Also note the line numbers of the timeouts so it can be determined
which is being seen (via __LINE__).
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.
thorpej