Commit Graph

14 Commits

Author SHA1 Message Date
Mike Silbersack
c7c3f58e12 Import some relevant changes from Via's if_fet driver:
1.  Detect the revision of the Rhine chip we're using.
2.  Use the force reset command on revisions which support
    it whenever the normal reset command fails.

This should solve a wide range of "my vr0 locks up with reset
failed messages" problems.  (Although the root causes should
be eventually tracked down.)

Tested by:	grenville armitage <garmitage@swin.edu.au>
Obtained from:	Via's if_fet driver
MFC after:	3 days
Approved by:	re
2002-11-25 05:15:27 +00:00
Mike Silbersack
f3b2d59e18 Improve handling of TX errors. Early reports indicate that this
elimiates the driver lockup problem reported by many.

Concepts used were taken from Via's if_fet driver.  Verification
and implementation were done by Thomas Nystrom.

Submitted by:	Thomas Nystrom <thn@saeab.se>
MFC after:	3 days
2002-08-15 04:04:53 +00:00
Mike Silbersack
16afddabdc Make sure to set both sets of registers which control the RX and TX buffer
sizes.  Previously, the end result was at the mercy of the card's default
setting.  This change will reduce the number of buffer underruns for
some users.

PR:		kern/37929
Submitted by:	Thomas Nystrom <thn@saeab.se>
MFC after:	7 days
2002-07-31 19:58:36 +00:00
Bill Paul
11c2ec4153 Close PR 22208: bring chip out of suspend mode, because Windows might
have put the chip to sleep at shutdown. This is really only for the
VT6102, but it doesn't hurt the older chips.
2001-05-14 19:13:02 +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
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
1be1972c4b Close PR# 19617: add support for VIA VT6102 NICs to VIA Rhine driver. 2000-07-05 21:37:21 +00:00
Bill Paul
ae3b8c19b1 Convert the VIA Rhine driver to miibus. 1999-09-19 22:03:31 +00:00
Peter Wemm
c3aac50f28 $Id$ -> $FreeBSD$ 1999-08-28 01:08:13 +00:00
Bill Paul
08339b4fa4 Convert the VIA Rhine driver to newbus and set it up to be compiled as
a module. Also modified the code to work on FreeBSD/alpha and added
device vr0 to the alpha GENERIC config.

While I was in the neighborhood, I noticed that I was still using
#define NFPX 1 in all of the Makefiles that I'd copied from the fxp
module. I don't really use #define Nfoo X so it didn't matter, but
I decided to customize this correctly anyway.
1999-08-10 17:15:20 +00:00
Bill Paul
727c88e9da Tweak the Macronix driver to hopefully make it more reliable:
- Change to the same transmit scheme as the PNIC driver.
- Dynamically set the cache alignment, and set burst size the same as
  the PNIC driver in mx_init().
- Enable 'store and forward' mode by default. This is the slowest option
  and it does reduce 100Mbps performance somewhat, but it's the most
  reliable setting I can find. I'm more interested in having the driver
  work reliably than trying to squeeze the best performance out of it.
  The reason I'm doing this is that on *some* systems you may see a lot
  of transmit underruns (which I can't explain: these are *fast* test
  systems) and these errors seem to cause unusual and decidedly
  non-tulip-like behavior. In normal 10Mbps mode, performance is fine
  (you can easily saturate a 10Mbps link).

Also tweak some of the other drivers:

- Increase the size of the TX ring for the Winbond, ASIX, VIA Rhine
  and PNIC drivers.
- Set a larger value for ifq_maxlen in the ThunderLAN driver. The setting
  of TL_TX_LIST_CNT - 1 is too low (the ThunderLAN driver only allocates
  20 transmit descriptors, and I don't want to fiddle with that now
  because the ThunderLAN's descriptor structure is an oddball size
  compared to the others).
1999-05-06 15:32:52 +00:00
Bill Paul
141ae16656 Add support for still more cheapo 10/100 cards: Delta Electronics and
Addtron appear to have their own VIA Rhine II and RealTek 8139 boards
with custom PCI vendor and device IDs. This commit updates the PCI
vendor and device lists in the vr and rl drivers so that we can probe
the additional devices.

Found by: nosing around the PCI vendor and device code list at:
	http://www.halcyon.com/scripts/jboemler/pci/pcicode
1999-02-23 15:38:25 +00:00
Bill Paul
6c70e5b472 Tweak the vr_start() and vr_rxeof() routines a little to improve
performance and reliability a little. There was a condition before
where transmission would stall during periods of heavy traffic
exchange between two hosts. Also set the 'want interrupt' bit in
receive descriptor control words.
1999-01-10 18:51:49 +00:00
Bill Paul
726ff6a158 An early Christmas present: add driver support for a whole bunch of
PCI fast ethernet adapters, plus man pages.

if_pn.c: Netgear FA310TX model D1, LinkSys LNE100TX, Matrox FastNIC 10/100,
         various other PNIC devices

if_mx.c: NDC Communications SOHOware SFA100 (Macronix 98713A), various
         other boards based on the Macronix 98713, 98713A, 98715, 98715A
         and 98725 chips

if_vr.c: D-Link DFE530-TX, other boards based on the VIA Rhine and
         Rhine II chips (note: the D-Link and certain other cards
         that actually use a Rhine II chip still return the PCI
         device ID of the Rhine I. I don't know why, and it doesn't
         really matter since the driver treats both chips the same
         anyway.)

if_wb.c: Trendware TE100-PCIE and various other cards based on the
         Winbond W89C840F chip (the Trendware card is identical to
         the sample boards Winbond sent me, so who knows how many
         clones there are running around)

All drivers include support for ifmedia, BPF and hardware multicast
filtering.

Also updated GENERIC, LINT, RELNOTES.TXT, userconfig and
sysinstall device list.

I also have a driver for the ASIX AX88140A in the works.
1998-12-04 18:01:24 +00:00