attempt to map the I/O BAR if it is 0. This will have the side-effect
of causing the wm_reset() routine to fall back to memory BAR accesses
for those chips on which it would attempt I/O BAR accesses for the reset.
Also update the comments about why we attempt the I/O BAR accesses for
the reset in favor of the memory BAR accesses.
make sure that the pullup was done into trailing space at the end of
the existing first-mbuf-in-chain. If not, log an error and drop the
packet, because the mbuf chain no longer corresponds to the DMA map,
and we are already committed to transmitting the packet.
- Change the Tx:Rx on-chip RAM allocation ratio based on MTU:
=> 82547: > 8192 18K:22K, else 10K:30K
=> others: > 8192 24K:40K, else 16K:48K
Values derived from Linux driver.
- On the 82547, keep track of how much of the Tx FIFO has been used.
When in half-duplex mode, don't let packets wrap around the FIFO ring
buffer, because that causes the chip to croak. Detect this, stall the
Tx queue, use a timer to wait for the packets to drain from the Tx FIFO,
reset the internal FIFO pointers, and restart the Tx queue. Basic
algorithm (and some magic numbers) derived from FreeBSD and Linux drivers.
on transmit.
- On 82544 and up, allocate 4096 Tx descriptors rather than just 256.
82543 and down must still use 256, due to errata.
- Allow up to 256 DMA segments per packet. I have observed some truly
pathological mbuf chains under certain (admittedly uncommon) workloads
when jumbo frames are in use.
Tested on macppc by HATANO Hiromichi.
Note I guess this bug could be fixed only adding one htole32(),
but I'd rather clean up endianness handling:
- Use htole32() only to accesses against DMA descriptors.
- Don't use uint32_t union member with htole32()/le32toh()
to access uint8_t/uint16_t descriptors.
- Add le32toh() in some DPRINTF.
(XXX: strictly speaking, bus_dmamap_sync() is needed for these DPRINTF)
chips. Add the i82541 and i82547 product IDs to the table, #if 0'd
out, for now (there are still more changes to come for these new chips
to work properly).
max memory read byte count in the command register is <= the max designed
memory read byte count in the status register. If not, reset it to the
status register's value. This is necessary because some BIOSes configure
the wrong value, and the wrong value confused some versions of the PCI-X
capable chips.
normal operation, it is required to implement a bug work-around on
some chips.
- When issuing a reset on the i82544, i82540, i82545, i82546,
and i82541, use I/O space, if available, to work around a problem
with the memory write cycle (problem only occurs when issuing
a reset).
descriptor sizes if larger mbuf clusters are in use -- currently
commented out because, for some reason, transmit doesn't work at
all with large mbuf cluster sizes.
Note that using actual 9K frames is a _lot_ less efficient than
using frames that are a little smaller than 8K so that they fit
in one or two pages (instead of two or three) and avoid the extra
chained descriptor with only 1K of data in it, too. TCP will
segment things just fine for an 8K total packet size, just as it
does for 1500-byte packets.
On my system, using "mtu 8000" with ifconfig, I get an almost 50%
performance boost for TCP (930Mbit/sec instead of 660Mbit/sec) over
1500-byte frames. "mtu 9000" yields only 770Mbit/sec.
