From owner-freebsd-alpha Fri Nov 26 5:15:32 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id AF15714F9F for ; Fri, 26 Nov 1999 05:15:16 -0800 (PST) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id C2EB21C6D; Fri, 26 Nov 1999 21:15:15 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.1.1 10/15/1999 To: peter.jeremy@alcatel.com.au Cc: Thomas Graichen , alpha@FreeBSD.ORG Subject: Re: de0: abnormal interrupt: transmit underflow In-Reply-To: Message from Peter Jeremy of "Fri, 26 Nov 1999 07:10:31 +1100." <99Nov26.070333est.40323@border.alcanet.com.au> Date: Fri, 26 Nov 1999 21:15:15 +0800 From: Peter Wemm Message-Id: <19991126131515.C2EB21C6D@overcee.netplex.com.au> Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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