Date: Mon, 29 Nov 1999 08:42:20 +1100 From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: Peter Wemm <peter@netplex.com.au> Cc: alpha@FreeBSD.ORG Subject: Re: de0: abnormal interrupt: transmit underflow Message-ID: <99Nov29.083512est.40335@border.alcanet.com.au> In-Reply-To: <19991126131515.C2EB21C6D@overcee.netplex.com.au> References: <jeremyp@gsmx07.alcatel.com.au> <19991126131515.C2EB21C6D@overcee.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On 1999-Nov-27 00:15:15 +1100, Peter Wemm wrote:
> 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.
^M
>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.
Given exactly the same warning message in Compaq Tru64 (aka Digital
UNIX aka OSF/1), it looks to be a hardware bug, rather than a driver
error (unless we have managed to replicate a bug in DEC's code[*]). A
fault in the FIFO management seems the most likely.
Since the Tx underflows generate rubbish on the wire, is there any way
to initialise the chips so they start with 1024 byte FIFO's when
running at 100mbps? This would somewhat increase latency, but would
reduce the number of garbage ethernet frames generated.
Peter
[*] Though I've read about experiments showing that this is more common
than would be expected.
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?99Nov29.083512est.40335>