From owner-freebsd-stable  Fri Jun 30 11:53:32 2000
Delivered-To: freebsd-stable@freebsd.org
Received: by hub.freebsd.org (Postfix, from userid 618)
	id AF46637B5FB; Fri, 30 Jun 2000 11:53:29 -0700 (PDT)
Subject: Re: Strangeness with 4.0-S
In-Reply-To: <20000625090856.A96022@area51.v-wave.com> from Chris Wasser at "Jun 25, 2000 09:08:56 am"
To: cwasser@v-wave.com (Chris Wasser)
Date: Fri, 30 Jun 2000 11:53:29 -0700 (PDT)
Cc: freebsd-stable@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL54 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-Id: <20000630185329.AF46637B5FB@hub.freebsd.org>
From: wpaul@FreeBSD.ORG (Bill Paul)
Sender: owner-freebsd-stable@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> I know I've asked about this several times before, but have yet to get any real solid answer (also searched the mailing
> list archives) .... I've tried several different brands of network cards under FreeBSD 4.0:
> 
> 3Com 3c905C-TX 10/100
> Linksys LNE100TX
> Kingston 21143 Tulip 10/100
> Netgear FA310TX 10/100
> 
> Whenever I use these cards @ 100base-T full duplex (although it's significantly less pronounced in the tulip) transferring a
> 7GB tarball (my test file) across a switched full-dupe network, I always end up with:
> 
> dc0: TX underrun -- increasing TX threshold
> xl0: transmission error: 90

Alright, I'll explain this *again*. Most PCI bus master ethernet cards
allow you to start transmitting data onto the wire before it's all been
loaded into the FIFO memory. In other words, data starts moving from the
host to the ethernet controller chip, and then the controller starts
sending it out onto the wire after a certain number of bytes are available.
The idea is that by the time those bytes have been sent, more data will
have been transfered from the host. This is faster than having to DMA
all of the data into the FIFO and then start transmission (plus it means
you can have a smaller FIFO).

The problem is that when you have a lot of bus master devices, or the
system is just plain busy, you will get a condition where the data can't
get from the host to the NIC fast enough to keep things flowing smoothly.
This is the underrun condition that the driver is warning you about. To
compensate, the driver increases the threshold, which means the chip will
wait for more data to be loaded into the FIFO before starting transmission.
If the underruns persist, the driver will eventually set the chip for
"store and forward" mode, at which point you shouldn't see any more
underruns.

The driver starts out with the lowest possible threshold since this gives
you the best performance, but if the host can't keep up, it has no choice
but to back off. This is *not* a fatal error. The driver should just reset
the chip and keep going. With that many bus master devices in the system,
it's not unusual to see some transmit underruns. Don't be too concerned
about them. It is not a "problem" that needs to be fixed. If the messages
really annoy you, comment them out of the driver code.

(I'm starting to regret putting them in there in the first place. Here
I was thinking I was being nice to people by letting them know what the
driver is doing, and everybody panics the moment they see them.)

-Bill


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message