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>

sys/pci/if_xlreg.h

@@ -29,7 +29,7 @@
  * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
  * THE POSSIBILITY OF SUCH DAMAGE.
  *
- *	$Id: if_xlreg.h,v 1.12 1998/08/13 21:29:06 wpaul Exp $
+ *	$Id: if_xlreg.h,v 1.1 1998/08/16 17:14:59 wpaul Exp $
  */
 
 #define XL_EE_READ	0x0080	/* read, 5 bit address */
@@ -429,7 +429,7 @@ struct xl_list_onefrag {
 };
 
 #define XL_MAXFRAGS		63
-#define XL_RX_LIST_CNT		4
+#define XL_RX_LIST_CNT		16
 #define XL_TX_LIST_CNT		10
 #define XL_MIN_FRAMELEN		60