Commit Graph

45 Commits

Author SHA1 Message Date
Sam Leffler
5120abbfb4 Drop the driver lock around calls to if_input to avoid a LOR when
the packets are immediately returned for sending (e.g.  when bridging
or packet forwarding).  There are more efficient ways to do this
but for now use the least intrusive approach.

Reviewed by:	imp, rwatson
2003-11-14 19:00:32 +00:00
Matthew N. Dodd
cdeb7b18af - Avoid calling pci_get_device() more than once in a single function.
- Provide a mechanism to prevent the use of MMIO.
- Prevent the use of MMIO for all 3c575 cardbus cards.
2003-09-14 16:33:48 +00:00
Bill Paul
e4cffe95c7 Support for large frames for VLANs was added by tweaking the packet size
register, present only on 3c90xB and later NICs. This meant that you could
not use a 1500 byte MTU with VLANs on original 3c905/3c900 cards (boomerang
chipset). The boomerang chip does support large frames though, just not
in the same way: you can set the 'allow large frames' bit in the MAC
control register to receive frames up to 4K in size.

Changes:

- Set the 'allow large frames' bit for boomerang chips and increase
  the packet size register for cyclone and later chips. This allows
  us to use IFCAP_VLAN_MTU on all supported xl(4) NICs.
- Actually set the IFCAP_VLAN_MTU flag in the capabilities word
  in xl_attach().
- Change the method used to detect older boomerang chips. My 3c575C
  cardbus NIC was being incorrectly identified as 3c90x chip instead
  of 3c90xB because the capabilities word in its EEPROM reports
  a bizzare value. In addition to checking for the supportsNoTxLength
  bit, also check for the absence of the supportsLargePackets bit.
  Both of these cases denote a 3c90xB chip.
- Make RX and TX checksums configurable via the SIOCSIFCAP ioctl.
- Avoid an unecessary le32toh() in xl_rxeof(): we already have the
  received frame size in the lower 16 bits of rxstat, no need to
  read it again.

Tested with 3c905-TX, 3c900-TPO, 3c980C and 3c575C NICs.
2003-07-10 05:24:33 +00:00
Mike Silbersack
16a930f6cb Instead of relying on a compile time define to determine whether the xl
driver should use port or memory based IO, determine it dynamically
at runtime, preferring MMIO where possible.  This helps us support newer
arches which dislike port based access better.

Tested on i386 & sparc64, with 3c900, 905, 905b, and 905C cards.
(in varying combinations by both jake and myself)
2003-03-18 06:29:51 +00:00
Maxime Henrion
44250c5cd8 - Fix mbuf leak when we successfully allocate a new mbuf but fail to
bus_dmamap_load() it.
- Make it so reusing mbufs when we can't allocate (or map) new ones
  actually works.  We were previously trying to reuse a mbuf which
  was already bus_dmamap_unload()'ed.

Reviewed by:	silby
2003-02-18 18:50:54 +00:00
Mike Silbersack
e02d5926c3 Correctly identify the 3C920B chipset; although it may ship with some Nforce2
boards, it's definitely not an Nvidia chip.

Info from: Nvidia's Linux Network driver & pciids.sourceforge.net
2003-01-22 17:14:33 +00:00
Thomas Moestl
a712d94e68 Make the xl driver work on sparc64:
- Add conversions to/from little endian for fields that the NIC accesses
  by DMA as required.
- Add some bus_dmamap_sync() calls, and correct some existing ones.
- Read the receiver information from the EEPROM in an endian-neutral
  manner.
- Load all RX and TX descriptors in a single DMA map up front, and
  get the bus addresses of individual descriptors by address arithmetic;
  this fixes multiple use of the descriptor tags, which would have
  undesired effects.
It seems that xl still does not work on e250 boxen, for reasons which
are not clear yet.

Reviewed by:	mux
2003-01-19 00:23:59 +00:00
David E. O'Brien
f9b7742405 Partial support for the nVidia nForce2 chipset's on-board Broadcom/Altima PHY
and 3com MAC.  Specifications for the Altima PHY are available at:
   http://www.altimacom.com/products/ac101L.html

Submitted by:	Mikko S. Hyvarinen <morphy@morphy.iki.fi>
2003-01-12 21:03:38 +00:00
Mike Silbersack
9363b90153 Add support for the 3c555 miniPCI chipset.
Submitted by:	johannes <johannes@paradise.net.nz>
PR:		46603
MFC after:	3 days
2003-01-06 00:46:03 +00:00
Maxime Henrion
e7c30f884f Convert the xl(4) driver to the busdma API. This should make
it possible to use this driver under ia64, sparc64 (though
there may be endianness issues with this one) and other archs.

Tested on:	i386, alpha (gallatin)
2002-12-17 00:08:49 +00:00
Mike Silbersack
26c138c5e2 Add some magic bits necessary to turn the transmitter on for some
(newer) 556B chips.

Requested & tested by:	Dinesh Nambisan <dinesh@nambisan.net>
Magic bits found by:	Dave Dribin & Donald Becker

MFC After:	3 days
2002-10-22 02:33:50 +00:00
Peter Wemm
962deac027 Turn off the premature locking in xl. The driver tries to use the mutexes
as spl replacements, but you cant sleep while holding mutexes.

This change has been made on many other drivers.
2002-10-14 23:58:46 +00:00
Mike Silbersack
dcf11ee64e Fix a problem where stats overflow interrupts would cause
a major slowdown, and re-enable stats overflow interrupts.

For future reference, the bug was in our code, and not
some bug in the 3com chips.

Reviewed by:	wpaul
MFC after:	2 days
2001-12-17 22:24:19 +00:00
Bill Paul
d93d282620 Add support for the 3c656B cardbus adapter. This is one half of a
dual function card. It needs pretty much the same flags as the 656C,
except that it seems to need both the INVERT_MII_PWR and INVERT_LED_PWR
flags set. Tested with cardbus in -current as of today.

Also added support for the 3c656, which looks to be the same as
the 656B, except it doesn't need the EEPROM_8BIT flag. I think. This
one is untested, but the added support should not break any of the
other cards.
2001-08-28 00:40:18 +00:00
Bill Paul
7d1b125b93 Close PR #27742: allow the xl driver to receive VLAN tagged frames by
setting the 'max packet size' register in window 3. This only
works for cards based on the cyclone or newer chipsets (i.e. it
won't work with the original 3c905/boomerang cards).

There is a trick which will work with the boomerang, which is to turn
on the 'large packets ok' bit in the MAC control register, however this
lets the chip accept any frame up to 4K in length, which is larger than
the mbuf cluster buffers we use to receive frames. If somebody sends us
such a frame and the chip DMAs it to us, it could write past the end
of the cluster buffer and clobber something.

PR: kern/27742
2001-05-31 22:08:45 +00:00
Bill Paul
84b86890ae Disable the 'stats counter overflow' interrupts since they can happen
much more often that expected and negatively impact performance when
running at 100mbps. I need to figure out if there's a better way to
handle this, but for now this shouldn't hurt anything.
2001-05-11 20:15:41 +00:00
Bosko Milekic
9ed346bab0 Change and clean the mutex lock interface.
mtx_enter(lock, type) becomes:

mtx_lock(lock) for sleep locks (MTX_DEF-initialized locks)
mtx_lock_spin(lock) for spin locks (MTX_SPIN-initialized)

similarily, for releasing a lock, we now have:

mtx_unlock(lock) for MTX_DEF and mtx_unlock_spin(lock) for MTX_SPIN.
We change the caller interface for the two different types of locks
because the semantics are entirely different for each case, and this
makes it explicitly clear and, at the same time, it rids us of the
extra `type' argument.

The enter->lock and exit->unlock change has been made with the idea
that we're "locking data" and not "entering locked code" in mind.

Further, remove all additional "flags" previously passed to the
lock acquire/release routines with the exception of two:

MTX_QUIET and MTX_NOSWITCH

The functionality of these flags is preserved and they can be passed
to the lock/unlock routines by calling the corresponding wrappers:

mtx_{lock, unlock}_flags(lock, flag(s)) and
mtx_{lock, unlock}_spin_flags(lock, flag(s)) for MTX_DEF and MTX_SPIN
locks, respectively.

Re-inline some lock acq/rel code; in the sleep lock case, we only
inline the _obtain_lock()s in order to ensure that the inlined code
fits into a cache line. In the spin lock case, we inline recursion and
actually only perform a function call if we need to spin. This change
has been made with the idea that we generally tend to avoid spin locks
and that also the spin locks that we do have and are heavily used
(i.e. sched_lock) do recurse, and therefore in an effort to reduce
function call overhead for some architectures (such as alpha), we
inline recursion for this case.

Create a new malloc type for the witness code and retire from using
the M_DEV type. The new type is called M_WITNESS and is only declared
if WITNESS is enabled.

Begin cleaning up some machdep/mutex.h code - specifically updated the
"optimized" inlined code in alpha/mutex.h and wrote MTX_LOCK_SPIN
and MTX_UNLOCK_SPIN asm macros for the i386/mutex.h as we presently
need those.

Finally, caught up to the interface changes in all sys code.

Contributors: jake, jhb, jasone (in no particular order)
2001-02-09 06:11:45 +00:00
Warner Losh
303b52daac Add device ID for the 3c565C card. I followed exactly the 3c575c, but
further tweaks may be necessary down the road.  This does nothing with
the serial side of the card.
2000-12-01 19:41:14 +00:00
MIHIRA Sanpei Yoshiro
defc432c55 add support for 3Com 3c575TX Fast Etherlink XL.
Device information for 3C575-TX is from NetBSD,
sys/dev/cardbus/if_ex_cardbus.c file.

Reviewed by:	wpaul, imp
2000-11-02 06:49:38 +00:00
Warner Losh
dc1aef34f1 Add support for cardbus card's chips. This will make the 3c575 cards
work once the rest of the cardbus infrastructure has been committed.

Submitted by: Jonathan Chen <jon@spook.org>
2000-10-16 23:16:02 +00:00
Bill Paul
d1ce910572 First round of converting network drivers from spls to mutexes. This
takes care of all the 10/100 and gigE PCI drivers that I've done.
Next will be the wireless drivers, then the USB ones. I may pick up
some stragglers along the way. I'm sort of playing this by ear: if
anyone spots any places where I've screwed up horribly, please let me
know.
2000-10-13 17:54:19 +00:00
Bill Paul
4e2499823f Add support for the 3Com 556 and 556B mini-pci adapters used on some
laptops. I've checked that this still works with the other cards and
it works with the 3c556 that I have access to, but I want to check that
it works with the 556B mentioned in PR #20878 before I close out the PR
and merge to -stable.
2000-08-28 20:40:03 +00:00
Bill Paul
968b1a711d Update the xl driver to recognize yet another 3c905B/3c905C class NIC:
the 3c450-TX HomeConnect. Like the 3cSOHO100-TX OfficeConnect, this NIC
uses the same ASIC as the 3c905B/3c905C but is targeted for a particular
market segment (home users). It is somewhat less expensive than the
3c905B/3c905C ($49, according to the 3Com web site), comes with its
own custom driver kit and is bundled with various goofy Windows software
packages designed to demonstrate the niftyness of home networking (networked
game demos, etc...).

Changes are:

- Add PCI ID to list in if_xlreg.h.
- Update xl_devs table in if_xl.c.
- Update xl_choose_xcvr() to consider the HomeConnect the
  same as all the other 10baseT/100baseTX cards.
1999-12-16 18:33:57 +00:00
Bill Paul
b08cfb55ef Make some small tweaks:
- When setting/clearing promisc mode, just update the filter, don't
  reset the whole interface.

- Call xl_init() in xl_ifmedia_upd() when setting miibus media modes. This
  fixes a problem with the 3c905B-COMBO where switching from 10base5/AUI
  or 10base2/BNC to a 10/100 mode doesn't always work right.

- Attempt to reset the interface in xl_init() so that we know we're getting
  the receive and transmit rings reset properly.
1999-10-14 21:49:17 +00:00
Bill Paul
1b4226d3e4 Add an alternate transmit strategy for 3c90xB adapters based on the transmit
strategy used in the 3Com Linux driver. The new strategy is to use transmit
descriptor polling -- that is, the NIC polls the descriptors to see when
new packets are available for transmission. The advantage to the new scheme
is that no register accesses are needed in the transmit routine. The old
scheme requires several register accesses to stall the TX engine, update the
TX DMA list pointer register, then unstall the TX engine. Hopefully the new
scheme will provide improved transmit performance with less CPU overhead.

This only affects the 3c90xB or 3c90xC cards, not the 3c90x cards. This
means the original 3c900 and 3c905 cards are unaffected. Newer cards include
the 3c900B series, the 3c905B, 3c980, 3c980B, 3c905C and 3c905C, and the
3cSOHO100-TX OfficeConnect.
1999-09-20 00:24:11 +00:00
Bill Paul
81569a614d 3Com has produced their own Linux driver for the 3c90x/3c90xB series cards.
It's GPL'ed of course, but looking over it tonight I learned of Yet Another
Fast EtherLink XL Adapter: the 3c980C server adapter. This is basically
an updated version of the 3c980 that uses the Tornado ASIC instead of the
earlier Hurricane ASIC. The only change here is to add the new PCI device
ID (0x9805) and corresponding table entries.
1999-09-15 07:19:34 +00:00
Bill Paul
1ef8fbeabf Convert the 3Com XL driver to miibus. This one is a little tricky
due to the fact that there are non-MII cards supported by the same
driver and I don't have all of the cards available for testing. There's
also the 3c905B-COMBO which has MII, AUI and BNC media ports all in one
package. Supporting the COMBO is difficult because we have to add the
10base5 and 10base2 media types to the same ifmedia struct as the
MII-attached types, however there is no way to force the miibus and
child PHYs into existence before xl_attach() completes, so there is
no ifmedia struct available in xl_attach(). What we do inistead is
use the mediainit method as a callback: when a child PHY is attached,
it calls the miibus mediainit routine which selects a default media.
This routing also calls the NIC driver's mediainit method (if it
implements one) at which point we can safely add the other media
types.
1999-08-29 15:52:19 +00:00
Peter Wemm
c3aac50f28 $Id$ -> $FreeBSD$ 1999-08-28 01:08:13 +00:00
Bill Paul
d1b67c3735 Convert the xl driver to newbus. It is now possible to make this driver
into a loadable module, and all of the platform dependencies are gone
(except for the alpha_XXX_dmamap() thing, which is another issue -- I
still don't know how to use the busdma stuff with a network driver).

Also increase the delay in xl_reset(); testing on a 486/66 with a 3c905C
shows that reading the EEPROM fails immediately after a reset. Waiting
a little longer after the reset completes seems to fix it.
1999-07-20 21:23:17 +00:00
Bill Paul
a62accda5a Head for the hills friends and neighbors, 3Com has yet another 3c90X
chipset. First you thrilled to the 3c905, then you trembled at the
3c905B, now gaze in wonder at: the 3c905C! This appears to be another
3c90X series chip called the Tornado (PCI ID 0x10B7/0x9200) and should
be equivalent (from the driver API perspective) to the 3c905B, so all
we have to do is add the PCI ID to the list.
1999-05-30 18:09:17 +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
b346e4e2e4 Dynamically increase TX start threshold if TX underruns are detected. 1999-05-05 17:05:07 +00:00
Bill Paul
0a9766ee3a Bunch of updates:
- Try to unbreak what I broke by screwing with the tx queuing again.
  I'm waiting for a few more people to test out this code and report back
  before I move it into current. Hopefully it will be soon. Basically I
  reverted to the old TX queuing strategy.

- Add experimental support for the 3c900B-FL (10mbps ST fiber). The card
  should be detected properly and the 10baseFL mode supported, but again
  I'm still waiting for word from a tester to see if this actually works.
  It shouldn't affect the other cards though; all the differences are in
  media selection.

- Set the TX start threshold register to get better performance.

- Increase the size of the RX and TX rings. UDP performance was pretty
  bad because the TX ring was too small. Should be substantially better
  now (I can saturate the link with either TCP or UDP now).

- Change some of the #defines to reflect proper 3Com ASIC names (boomerang,
  cyclone, krakatoa, hurricane).

- Simplify and reorganize interrupt handler; ack all interrupts right
  away and then process them. This avoids a potential race condition.
  (Noted by Matt Dillon.)

- Reorganize the bridging code to eliminate using a goto to jump into
  the middle of an if() {} clause. Sorry, that just made my brain itch.

- Use m_adj() in xl_rxeof().

- Make the payload alignment in xl_newbuf() the default (instead of
  just conditionally defined for the alpha) to improve NFS performance
  (avoids need for nfs_realign()).
1999-04-30 16:15:43 +00:00
Bill Paul
ae1a2d45d9 - Close PR #11136: add PCI ID for another new cyclone device: the
3c900B-TPC (twisted pair and coax). Treated similarly to the
  3c900B-COMBO, except no AUI port.

- Fix media selection so that it's possible to select the AUI and BNC
  ports on the 3c905B-COMBO. This board is now fully supported.

- Change TX queueing strategy to hopefully be more efficient by avoiding
  register accesses in xl_start(). Should provide small performance
  improvement and a little better reliability.
1999-04-15 03:18:33 +00:00
Bill Paul
980e28f69a Add support for the 3cSOHO100-TX, which is a "hurricane" chipset
(cut-down version of the "cyclone" for the small office/home office
"cheap bastard" market). Basically the same as a 3c905B but without
Wake-on-LAN, ROM socket, etc...
1999-04-12 20:38:45 +00:00
Bill Paul
863e79b09e Some small updates:
- Wait longer for the reset to complete in xl_attach() to try and avoid
  'command never completed' warnings.

- Clean up a few odds and ends in xl_attach().

- Add PCI ID for the 3c905B-COMBO (a new card). Right now this is
  treated as a 3c905B; I need to dig up one of these cards for testing
  before I can make the AUI and BNC ports work.

- Add a hack to force reading the I/O address directly from the PCI
  registers if pci_map_port() fails. I SHOULD NOT HAVE TO DO THIS:
  SOMEBODY WITH MORE PCI CLUES THAN I SHOULD INVESTIGATE WHY THIS
  HAPPENS.
1999-04-11 17:44:44 +00:00
Bill Paul
8fe2c75e31 Make the xl and pn drivers work on FreeBSD/alpha and add them to
sys/alpha/conf/GENERIC.

Note: the PNIC ignores the lower few bits of the RX buffer DMA address,
which means we have to add yet another kludge to make it happy. Since
we can't offset the packet data, we copy the first few bytes of the
received data into a separate mbuf with proper alignment. This puts
the IP header where it needs to be to prevent unaligned accesses.

Also modified the PNIC driver to use a non-interrupt driven TX
strategy. This improves performance somewhat on x86/SMP systems where
interrupt delivery doesn't seem to be as fast with an SMP kernel as
with a UP kernel.
1999-03-27 20:41:25 +00:00
Bill Paul
447c20659b Close PR #8384:
Revert the transmission packet queueing strategy changes. Clearly I missed
something while debugging this, although I never encountered any problems
on my test machines.

Also make one other minor change: jack up the TX reclaim threshold for
3c90xB adapters in order to stave off 'transmission error: 82' errors.

Document the existence of the tx reclaim register (for inspecting the
current reclaim threshold) in register window 5 (if_xlreg.h).
1998-10-22 15:52:25 +00:00
Bill Paul
1c403cb2b6 Modify the transmit packet queuing strategy a bit to be a little less
agressive. With the old code, if a descriptor chain was already on its
way to the chip, xl_start() would try to splice new chains onto the end
of the current chain by stopping the transmitter, modifying the tail
pointer of the current chain to point to the head of the new chain, then
restart the transmitter. The manual says you're allowed to do this and
it works, but I'm not too keen on it anymore.

The new code waits until the eixsting chain has been sent and then
queues the next waiting chain in the 'transmit ok' handler.

Performance still looks good one way or the other.
1998-10-19 22:08:56 +00:00
Bill Paul
62034864f7 Add support for yet another "cyclone" board, with PCI device id 0x905A.
This is a 100BaseFX board with SC fiber media connectors. I don't actually
have one of these but I've been told it works with the xl driver.

Submitted by: Jason Wright from the openbsd group
1998-10-09 03:59:24 +00:00
Bill Paul
97e28a9d67 Apply patch graciously provided by Jason Wright <jason@thought.net> from
the OpenBSD group to fix a problem with the default ifmedia not being
set properly in some cases with a 3c905B, leading to a panic in ifmedia_set().

Also apply a patch to force the transmit start routine to check the
transmitter to make sure it isn't wedged if the outbound tx queue appears
full. This seems to cure some problems with 'watchdog timeout' errors
cropping up in some cases. I tried to do this before by checking for the
IFF_OACTIVE flag on entry to xl_start(), but if the IFF_OACTIVE flag is
set, ether_output() won't even call xl_start(). It should work now.

Lastly, increase the size of the TX queue from 10 descriptors to 16 to
hopefully make it less likely that the TX queue will fill up.
1998-09-25 17:34:19 +00:00
Bill Paul
7d8b3c341b Modify the xl_mediacheck() routine to also test for the case where the
XCVR value read from the EEPROM is completely wrong. I've had one report
of a 3c900 card that returns an xcvr value of 14, which is impossible
(the manual states that all vales above 8 are reserved). If the value
is out of the expe

Add PCI vendor ID for the 3c980-TX server adapter card, which apparently
also uses the cyclone chip. Graciously supplied Mats O Jansson
<maja@cntw.com>.

Also noted by Mats, the 10mpbs cyclone adapters should be named 3c900B,
not 3c905B. I haven't actually encountered a 10mbps only cyclone adapter
yet, nor anybody who has one, but this makes sense given the naming
scheme used for the older boomerang adapters.
1998-09-04 16:22:15 +00:00
Bill Paul
128a646cd1 - #define mask of enabled interrupts/indications in if_xlreg.h instead of
constructing local copy in xl_init()
- disable interrupts on entry to xl_intr(), re-enable them on exit.
- fix a few typos in some comments
1998-08-24 17:51:38 +00:00
Bill Paul
ea9c501856 Increase the number of descriptors (and, as a consequence, the number
of associated mbuf clusters) in the RX ring from 4 to 16. On my
really fast PI 400Mhz test machines, 4 descriptors (and associated
mbuf clusters) is enough to achieve decent performance without any
RX overruns. However, one person reported problems with the following
scenario:

- P90 system running FreeBSD with a 3c905B-TX adapter, slow IDE hard
  disk (Quantum Bigfoot?)
- PII 266 with SCSI disks running LoseNT and also with a 3c905B-TX
- Both machines connected together via crossover cable at 100Mbps
  full-duplex
- LoseNT machine writing largs amounts of data (2.5 GB work of
  files each in the neighborhood of 1 to 2 MB in size) via samba to
  the FreeBSD machine

In this case, the LoseNT machine is sending data very fast. Apparently
there weren't any problems initially because the user was writing to
one particular disk which was relatively fast, however after this disk
filled up and the user started writing to the second slower disk, RX
overruns would occur and sometimes the RX DMA engine would stall after
a 100 to 500MB had been transfered. The xl_rxeof() handler is supposed
to detect this condition and restart the upload engine; I'm not sure
why it doesn't, unless interrupts are being lost and the rx handler
isn't getting called.

This is still an improvement over the Linux driver, which uses 32
descriptors in its receive ring. :)

Problem reported by: Heiko Schaefer <hschaefer@fto.de>
1998-08-21 16:58:48 +00:00
Bill Paul
e30938ce3a Import the (Fast) Etherlink XL driver. I'm reasonally confident in its
stability now. ALso modify /sys/conf/files, /sys/i386/conf/GENERIC
and /sys/i386/conf/LINT to add entries for the XL driver. Deactivate
support for the XL adapters in the vortex driver. LAstly, add a man
page.

(Also added an MLINKS entry for the ThunderLAN man page which I forgot
previously.)
1998-08-16 17:14:59 +00:00