Date: Fri, 30 Jun 2000 11:53:29 -0700 (PDT) From: wpaul@FreeBSD.ORG (Bill Paul) To: cwasser@v-wave.com (Chris Wasser) Cc: freebsd-stable@FreeBSD.ORG Subject: Re: Strangeness with 4.0-S Message-ID: <20000630185329.AF46637B5FB@hub.freebsd.org> In-Reply-To: <20000625090856.A96022@area51.v-wave.com> from Chris Wasser at "Jun 25, 2000 09:08:56 am"
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000630185329.AF46637B5FB>