Date: Fri, 26 Nov 1999 21:15:15 +0800 From: Peter Wemm <peter@netplex.com.au> To: peter.jeremy@alcatel.com.au Cc: Thomas Graichen <graichen@innominate.de>, alpha@FreeBSD.ORG Subject: Re: de0: abnormal interrupt: transmit underflow Message-ID: <19991126131515.C2EB21C6D@overcee.netplex.com.au> In-Reply-To: Message from Peter Jeremy <jeremyp@gsmx07.alcatel.com.au> of "Fri, 26 Nov 1999 07:10:31 %2B1100." <99Nov26.070333est.40323@border.alcanet.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Jeremy wrote:
> On 1999-Nov-26 04:58:57 +1100, Thomas Graichen wrote:
> >anyone an idea what exactly this means ?
> >
> >de0: abnormal interrupt: transmit underflow (raising TX threshold to 96|256)
> >de0: abnormal interrupt: transmit underflow (raising TX threshold to 128|512
)
> >de0: abnormal interrupt: transmit underflow (raising TX threshold to 160|102
4)
> >
> >... but i think this has more to do with the networking here
> >than with FreeBSD/alpha - but maybe its also related to the
> >de driver for the alpha - any ideas ?
>
> The Tulip driver in Digital UNIX does the same as well. I thought I'd
> seen an explanation for it somewhere, but can't find it right now. (I
> think it's related to the DMA buffer thresholds).
OK, the Tulip series chips have a recieve and transmit FIFO that has the
busmaster DMA interface on one side and the ethernet engine on the other.
Recieving is not so much of a problem as the fifo is big enough to hold at
least an entire frame, and it's emptied to main memory as soon as
practical.
Transmission however is another problem. The busmaster engine starts
filling the fifo as soon as it's given the go-ahead. As soon as it reaches
the threshhold, the ethernet engine begins transmission on the wire.
Obviously you want to do this as quickly as possible to get the latency
down. But.. if the busmaster engine can't (for some reason) get data from
memory quick enough, and the fifo runs out of data while the ethernet
engine is transmitting, that is a problem as the packet is already partly
on the wire and suddenly is stopped mid flight leading to a corrupt packet.
A recieve overflow wouldn't be so bad as it doesn't cause debris on the
wire. A transmitter underflow does cause corrupt packets though.
Here's where it gets interesting.. The tulip series (and a few others, but
not all of the 100mbit cards) suffer from underflows. Main memory should
be plenty fast enough to keep up, as it's a good 500+mbyte/sec, and we only
need in the order of 12kbyte/sec to keep the transmitter busy. The PCI
busmaster latency timers and so on could cause starvation but I've seen
this problem on machines with one sole PCI busmaster active and no
(obvious) PCI configuration problems.
It's as though the chips have a bug and "forget" about keeping the fifo
full. I half thought I saw Bill Paul say he was suspicious that it's
something to do with the descriptor layout and that keeping the transmitter
running from a contiguous mbuf cluster rather than collecting the frame
from multiple mbuf fragments might be the solution. I don't know if my
interpretation was right or if I was imagining it, or if it's been found
not to be the case.
BTW, 'switching to store and forward mode' which is the last step of the
underflow correction means that it dma's the entire frame into the fifo
before going near the wire. It's kinda suspicious when it's set to
"1024" byte though... it fills the fifo to 1024 bytes (out of 1500) and starts
transmission. Even given this much of a head-start, it's still not been able
to keep up...
Cheers,
-Peter
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19991126131515.C2EB21C6D>