Commit Graph

56 Commits

Author SHA1 Message Date
Bill Paul
497760a16a Fix bug that can cause transmit corruption. There are actually two 'rings'
in the transmit code: the TX descriptor ring, and a 'shadow' ring of mbuf
pointers, one for each TX descriptor. When transmitting a packet that
consists of several fragments in an mbuf chain, we link each fragment
to a descriptor in the TX ring, but we only save a pointer to the mbuf
chain. This pointer is saved in the shadow ring entry which corresponds
to the first fragment in the packet. Later, ti_txeof() can release the
whole chain with a single m_freem() call. (We need the second ring to
keep track of the virtual addresses of the mbuf chains.)

The problem with this is that the Tigon isn't actually through with the
mbuf chain until it reaches the last fragment (which has the TI_BDFLAG_END
bit set), however the current scheme releases the mbuf chain as soon as
the first fragment is consumed. This is wrong, since the mbufs can then
be yanked out from under the Tigon and modified before the other fragments
can be transmitted.

The fix is to make a one line change to ti_encap() so that it saves the
mbuf chain pointer in the shadow ring entry that corresponds to the last
fragment in TX ring instead of the first. This prevents the mbufs from
being released until the last fragment is transmitted.

Painstakingly diagnosed and fixed by: Robert Picco <picco@mail.wevinc.com>
Brought to my attention by: dg
1999-05-24 14:56:55 +00:00
Peter Wemm
579f45fa60 Simplify the COMPAT_PCI_DRIVER/DATA_SET hack. We can add:
#define COMPAT_PCI_DRIVER(name,data) DATA_SET(pcidevice_set,data)
.. to 2.2.x and 3.x if people think it's worth it.  Driver writers can do
this if it's not defined.  (The reason for this is that I'm trying to
progressively eliminate use of linker_sets where it hurts modularity and
runtime load capability, and these DATA_SET's keep getting in the way.)
1999-05-09 17:07:30 +00:00
Bill Paul
737267b891 Add a test to ti_encap() to try and prevent the transmit producer index
from ever catching up to the transmit consumer index. We can't let this
happen because ti_txeof() depends on the assumption that producer == consumer
means the ring is empty, and producer != consumer means the ring has some
number of active descriptors in it.
1999-04-29 16:27:51 +00:00
Peter Wemm
96b3554e5c Use COMPAT_PCI_DRIVER() for registration if it exists. This shouldn't
hurt the driver portability to 3.x too much for where drivers are shared.
1999-04-24 20:17:05 +00:00
Bill Paul
2075407db2 Remove teensy-weensy bit of debug code that crept in.
Oh, I forgot to mention: this driver also works on FreeBSD/alpha (big
thanks to Andrew Gallatin). And there is a 2.2.x version available for
those who stubbornly refuse to upgrade.
1999-04-06 22:56:21 +00:00
Bill Paul
d02c233129 Add driver support for gigabit ethernet adapters based on the Alteon
Networks Tigon 1 and Tigon 2 chipsets. There are a _lot_ of OEM'ed
gigabit ethernet adapters out there which use the Alteon chipset so
this driver covers a fair amount of hardware. I know that it works with
the Alteon AceNIC, 3Com 3c985 and Netgear GA620, however it should also
work with the DEC/Compaq EtherWORKS 1000, Silicon Graphics Gigabit
ethernet board, NEC Gigabit Ethernet board and maybe even the IBM and
and Sun boards. The Netgear board is the cheapest (~$350US) but still
yields fairly good performance.

Support is provided for jumbo frames with all adapters (just set the
MTU to something larger than 1500 bytes), as well as hardware multicast
filtering and vlan tagging (in conjunction with the vlan support in
-current, which I should merge into -stable soon). There are some hooks
for checksum offload support, but they're turned off for now since
FreeBSD doesn't have an officially sanctioned way to support checksum
offloading (yet).

I have not added the 'device ti0' entry to GENERIC since the driver
with all the firmware compiled in is quite large, and it doesn't really
fit into the category of generic hardware.
1999-04-06 17:08:31 +00:00