Commit Graph

127 Commits

Author SHA1 Message Date
Bill Paul
9e4c647c74 Tweak these for what I hope is the last time: change the DRIVER_MODULE()
declaration for the interface driver from "foo" to "if_foo" but leave the
declaration for the miibus attached to the interface driver alone. This
lets the internal module name be "if_foo" while still allowing the miibus
instances to attach to "foo."

This should allow ifconfig to autoload driver modules again without
breaking the miibus attach.
1999-09-22 06:08:11 +00:00
Bill Paul
0355003f26 Un-do the changes to the DRIVER_MODULE() declarations in these drivers.
This whole idea isn't going to work until somebody makes the bus/kld
code smarter. The idea here is to change the module's internal name
from "foo" to "if_foo" so that ifconfig can tell a network driver from
a non-network one. However doing this doesn't work correctly no matter
how you slice it. For everything to work, you have to change the name
in both the driver_t struct and the DRIVER_MODULE() declaration. The
problems are:

- If you change the name in both places, then the kernel thinks that
  the device's name is now "if_foo", so you get things like:

if_foo0: <FOO ethernet> irq foo at device foo on pcifoo
if_foo0: Ethernet address: foo:foo:foo:foo:foo:foo

  This is bogus. Now the device name doesn't agree with the logical
  interface name. There's no reason for this, and it violates the
  principle of least astonishment.

- If you leave the name in the driver_t struct as "foo" and only
  change the names in the DRIVER_MODULE() declaration to "if_foo" then
  attaching drivers to child devices doesn't work because the names don't
  agree. This breaks miibus: drivers that need to have miibuses and PHY
  drivers attached never get them.

In other words: damned if you do, damned if you don't.

This needs to be thought through some more. Since the drivers that
use miibus are broken, I have to change these all back in order to
make them work again. Yes this will stop ifconfig from being able
to demand load driver modules. On the whole, I'd rather have that
than having the drivers not work at all.
1999-09-20 19:06:45 +00:00
Bill Paul
fac1f39b19 Grrr. Okay, changing the devnames was a bad idea. Put them back the way
they were.
1999-09-20 08:47:11 +00:00
Bill Paul
b95a9362a0 Fix the strings in the driver_t structs so that they match the new names
in the DRIVER_MODULES() declarations. *sigh*
1999-09-20 08:14:39 +00:00
David E. O'Brien
bd8a15ce8a Change the name we register with DRIVER_MODULE() to include the leading
"if_".

Reviewed by:	msmith, wpaul
1999-09-20 06:50:52 +00:00
Bill Paul
d1e8f983ef Remember to account for ETHER_ALIGN when setting the maxmimum packet
length for mini receive ring. The max length was MHLEN, however the mbufs
are actually shortened to MHLEN - ETHER_ALIGN to force payload alignment.

PR:		13793
1999-09-17 18:04:14 +00:00
Bruce Evans
3de9d6fbe4 Don't restrict our requests for contiguous memory to addresses >= 1MB.
This fixes, at least, panics in ncr_attach() on i386's with about 5MB
of memory.  The restriction was a hack to leave some low memory for ISA
DMA, but on i386's we now allocate pages from the top down, so all the
restriction did was cause our allocations to fail when there is no free
memory above 1MB.
1999-08-29 09:03:58 +00:00
Peter Wemm
c3aac50f28 $Id$ -> $FreeBSD$ 1999-08-28 01:08:13 +00:00
Bill Paul
2b028af745 Minor glitch in ti_newbuf_jumbo(): m_adj() was being called on
m instead of m_new.

Submitted by: Kenneth D. Merry <ken@kdm.org>
1999-08-14 15:45:03 +00:00
Bill Paul
070f62142c Roar! Finish what I started last night: somehow only the header file change
got committed.
1999-07-27 13:54:15 +00:00
Bill Paul
af1c062105 On FreeBSD/i386, when you use the SYS_RES_MEMORY resource to allocate
a PCI memory mapped region, rman_get_bushandle() returns what happens
to be a kernel virtual address pointing to the base of the PCI shared
memory window. However this is not the behavior on all platforms:
the only thing you should do with the bushandle is pass it to the
bus_spare_read()/bus_space_write() routines. If you actually do want
the kernel virtual address of the base of the PCI memory window, you
need to use rman_get_virtual().

The problem is that at the moment, rman_get_virtual() returns a physical
address, which is bad. In order to get the kernel virtual address we
need, we have to play with it a little.

Presumeably this behavior will be changed, but in the meantime the
Tigon driver won't work. So for the moment, I'm adding a kludge to
make things happy on the alpha: the correct kernel virtual address
is calculated from the value returned by rman_get_virtual(). This
should be removed once rman_get_virtual() starts doing the right
thing.

This should make the Tigon actuall work on the alpha now.
1999-07-27 03:54:48 +00:00
Peter Wemm
eda5a3370a Make this compile on the Alpha. I'm not 100% sure about this but I
think it's ok.  ti_bhandle is fetched from newbus on both the Alpha
and x86, the Alpha-only ti_vhandle is gone.
1999-07-25 06:46:19 +00:00
Bill Paul
571a80b261 Clean up the buffer allocation code a bit. Make sure to initialize certain
critical mbuf fields to sane values. Simplify the use of ETHER_ALIGN to
enforce payload alignment, and turn it on on the x86 as well as alpha
since it helps with NFS which wants the payload to be longword aligned
even though the hardware doesn't require it.

This fixes a problem with the ti driver causing an unaligned access trap
on the Alpha due to m_adj() sometimes not setting the alignment correctly
because of incomplete mbuf initialization.
1999-07-23 18:46:24 +00:00
Bill Paul
43a095a5fd Grrr. Return the rman_get_bustag()/rman_get_bushandle() lines to their
proper place in ti_attach(). I'm positive I typed them in there, but
they must have fallen victim to a drive-by cut & pasting.
1999-07-23 16:21:43 +00:00
Bill Paul
39d837d4b5 Dangit. Somehow the pmap_kextract hack for alpha snuck back into these
files. Change them back to alpha_XXX_dmamap().

Pointed out by: Andrew Gallatin
1999-07-23 02:18:01 +00:00
Bill Paul
89ca84e6db Convert the Alteon Tigon gigabit ethernet driver to newbus. Also upgrade
to the latest firmware release from Alteon (12.3.12).
1999-07-23 02:10:11 +00:00
Dag-Erling Smørgrav
6b5ca0d83e Rename bpfilter to bpf. 1999-07-06 19:23:32 +00:00
Bill Paul
7f971fc2ca Remove ti_refill_rx_rings() and associated stuff; replace dirty RX buffers
in ti_rxeof() instead. This doesn't really seem to provide much in the
way of a performance boost, and I'm pretty sure it can cause mbuf leakage
in some extreme cases.
1999-07-05 20:19:41 +00:00
Bill Paul
274342303b Add a transmit descriptor usage counter and use it to absolutely,
positively not let ti_encap() fill up the TX ring all the way and wrap
around. This fixes a potential transmit lockup where a really fast
machine (or particular TX traffic pattern) can overrun the end of the
ring.

Reported by: John Plevyak <jplevyak@inktomi.com>
1999-06-19 00:36:56 +00:00
Andrew Gallatin
50b8d1cce4 Allow chipset drivers to specify the direct-mapped DMA window's mask in
preparation for tsunami support.  Previous chipsets' direct-mapped DMA
mask was always 1024*1024*1024.  The Tsunami chipset needs it to be
2*1024*1024*1024

These changes should not affect the i386 port

Reviewed by:	Doug Rabson <dfr@nlsystems.com>
1999-05-26 23:01:57 +00:00
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
6263933e7a Upgrade firmware images Alteon's latest release (12.3.10). This fixes a
bug in the stats accounting (nicSendBDs counter was bogus when TX ring was
configured to be in host memory).

Update if_tireg.h to look for new firmware fix level.
1999-05-03 17:44:53 +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