Kenneth D. Merry 49dfe4a2d4 Fix an event handling bug with the mps(4) driver.
This bug manifested itself after repeated device arrivals and
departures.  The root of the problem was that the last entry in the
reply array wasn't initialized/allocated.  So every time we got
around to that event, we had a bogus address.

There were a couple more problems with the code that are also fixed:

 - The reply mechanism was being treated as sequential (indexed by
   sc->replycurindex) even though the spec says that the driver
   should use the ReplyFrameAddress field of the post queue
   descriptor to figure out where the reply is.  There is no
   guarantee that the reply descriptors will be used in sequential
   order.

 - The second word of the reply post queue descriptor wasn't being
   checked in mps_intr_locked() to make sure that it wasn't
   0xffffffff.  So the driver could potentially come across a
   partially DMAed descriptor.

 - The number of replies allocated was one less than the actual
   size of the queue.  Instead, it was the size of the number of
   replies that can be used at one time.  (Which is one less than
   the size of the queue.)

mps.c:		When initializing the entries in the reply free
		queue, make sure we initialize the full number that
		we tell the chip we have (sc->fqdepth), not the
		number that can be used at any one time (sc->num_replies).

		When allocating replies, make sure we allocate the
		number of replies that we've told the chip exist,
		not just the number that can be used simultaneously.

		Use the ReplyFrameAddress field of the post queue
		descriptor to figure out which reply is being
		referenced.  This is what the spec says to do, and
		the spec doesn't guarantee that the replies will be
		used in order.

		Put a check in to verify that the reply address passed
		back from the card is valid.  (Panic if it isn't, we'll
		panic when we try to deference the reply pointer in any
		case.)

		In mps_intr_locked(), verify that the second word of the
		post queue descriptor is not 0xffffffff in addition to
		verifying that the unused flag is not set, so we can
		make sure we didn't get a partially DMAed descriptor.

		Remove references to sc->replycurindex, it isn't needed
		now.

mpsvar.h:	Remove replycurindex from the softc, it isn't needed now.

Reviewed by:	scottl
2010-12-10 21:45:10 +00:00
2010-12-03 22:59:54 +00:00
2010-12-08 17:34:07 +00:00
2010-12-02 17:36:47 +00:00
2010-01-09 18:53:03 +00:00
2010-12-06 10:24:06 +00:00
2009-12-31 10:00:37 +00:00
2008-06-05 19:47:58 +00:00
2010-11-13 22:38:33 +00:00
2010-12-04 18:52:05 +00:00
2010-11-14 11:32:56 +00:00

This is the top level of the FreeBSD source directory.  This file
was last revised on:
$FreeBSD$

For copyright information, please see the file COPYRIGHT in this
directory (additional copyright information also exists for some
sources in this tree - please see the specific source directories for
more information).

The Makefile in this directory supports a number of targets for
building components (or all) of the FreeBSD source tree, the most
commonly used one being ``world'', which rebuilds and installs
everything in the FreeBSD system from the source tree except the
kernel, the kernel-modules and the contents of /etc.  The ``world''
target should only be used in cases where the source tree has not
changed from the currently running version.  See:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html
for more information, including setting make(1) variables.

The ``buildkernel'' and ``installkernel'' targets build and install
the kernel and the modules (see below).  Please see the top of
the Makefile in this directory for more information on the
standard build targets and compile-time flags.

Building a kernel is a somewhat more involved process, documentation
for which can be found at:
   http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig.html
And in the config(8) man page.
Note: If you want to build and install the kernel with the
``buildkernel'' and ``installkernel'' targets, you might need to build
world before.  More information is available in the handbook.

The sample kernel configuration files reside in the sys/<arch>/conf
sub-directory (assuming that you've installed the kernel sources), the
file named GENERIC being the one used to build your initial installation
kernel.  The file NOTES contains entries and documentation for all possible
devices, not just those commonly used.  It is the successor of the ancient
LINT file, but in contrast to LINT, it is not buildable as a kernel but a
pure reference and documentation file.


Source Roadmap:
---------------
bin		System/user commands.

cddl		Various commands and libraries under the Common Development
		and Distribution License.

contrib		Packages contributed by 3rd parties.

crypto		Cryptography stuff (see crypto/README).

etc		Template files for /etc.

games		Amusements.

gnu		Various commands and libraries under the GNU Public License.
		Please see gnu/COPYING* for more information.

include		System include files.

kerberos5	Kerberos5 (Heimdal) package.

lib		System libraries.

libexec		System daemons.

release		Release building Makefile & associated tools.

rescue		Build system for statically linked /rescue utilities.

sbin		System commands.

secure		Cryptographic libraries and commands.

share		Shared resources.

sys		Kernel sources.

tools		Utilities for regression testing and miscellaneous tasks.

usr.bin		User commands.

usr.sbin	System administration commands.


For information on synchronizing your source tree with one or more of
the FreeBSD Project's development branches, please see:

  http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/synching.html
Description
freebsd with flexible iflib nic queues
Readme 2.6 GiB
Languages
C 60.1%
C++ 26.1%
Roff 4.9%
Shell 3%
Assembly 1.7%
Other 3.7%