I had to initialize the ifnet a bit earlier in attach so that the
if_printf()'s in vr_reset() didn't explode with a page fault.
- Use M_ZERO with contigmalloc() rather than an explicit bzero.
struct ifnet or the layer 2 common structure it was embedded in have
been replaced with a struct ifnet pointer to be filled by a call to the
new function, if_alloc(). The layer 2 common structure is also allocated
via if_alloc() based on the interface type. It is hung off the new
struct ifnet member, if_l2com.
This change removes the size of these structures from the kernel ABI and
will allow us to better manage them as interfaces come and go.
Other changes of note:
- Struct arpcom is no longer referenced in normal interface code.
Instead the Ethernet address is accessed via the IFP2ENADDR() macro.
To enforce this ac_enaddr has been renamed to _ac_enaddr.
- The second argument to ether_ifattach is now always the mac address
from driver private storage rather than sometimes being ac_enaddr.
Reviewed by: sobomax, sam
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
using the Rhine's internal shift registers which are designed
for the job. This reduces the amount of time we wait around shifting
bits, and seems to work better with some chips.
Also, provide a workaround for some newer cards which report fake PHYs
at multiple addresses. (As more cards are ID'd, I'm sure this part
of the code will have to be expanded to cover more cases.)
Submitted by: Thomas Nystrom <thn@saeab.se>
MFC after: 1 week
under load.
This patch has been tested by Thomas and other for more than a month now,
and all (known) hangs seem to be solved.
Thomas's explanation of the patch:
* Fix the problem with the printing of the RX-error.
* Code from if_fet do better deal with the RX-recovery including a
timeout of the RX-turnoff.
* The call to vr_rxeof before vr_rxeoc have been moved to a point
where the RX-part of the chip is turned off. Otherwise there is a
window where new data could have been written to the buffer chain
before the RX-part is turned off. If this happens the chip will see
a busy rx-buffer. I have no evidence that this have occured but
god knows what the chip will do in this case!
* I have added a timeout of the TX-turnoff. I have checked and in
my 900 MHz system the flags for turnoff (both RX & TX) is seen at
the first check in the loop.
* I could see that I got the VR_ISR_DROPPED interrupt sometimes and
started to thinking about this. I then realized that no recovery is
needed for this case and therefore I only count it as an rxerror
(which was not done before).
* Finally I have changed the FIFO RX threshhold to 128 bytes. When I
did this the VR_ISR_DROPPED interrupt went away. Theory: The chip
will receive a complete frame before it tries to write it out to
memory then the RX threshold is set to store'n'forward. IF the frame
is large AND the next rx frame also is large AND the bus is busy
transfering a TX frame to the TX fifo THEN the second received
frame wont fit in the FIFO and is then dropped. By having the RX
threshold set to 128 the RX fifo is emptied faster.
MFC after: 5 days
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
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
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
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)
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.
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.
- 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).
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
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.
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.
