Matthew Dillon wrote:
> :But that was a week ago, and it's a *busy* news server (that's not hitting
> :swap), I was just curious about the error messages from the de driver.
> :
> : -- Niels.
>
> The transmit underflow messages:
>
> 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|1024
)
>
> can typically be ignored. It simply means that the DEC card has too smal
l
> a transmit FIFO and is getting DMA underflows. Stupid card.
As I understand it, what's happening is that it's reacting to pci bus
congestion by raising the preread threshholds. It degenerates to fetching
the entire frame into on-card (or chip) memory before beginning
transmission.
On my system I can understand it, it's a 2xP5 with a shared L2 cache on a
Neptune chipset - something that isn't known for speed. Once you get two
processors hammering the system bus, *plus* mix in an EISA scsi
controller, I could well imagine the memory bus getting thrashed.
I'm not sure how to read the messages. Looking at the if_pn driver as
well, it looks like both start with a FIFO threshold of 72 bytes. I think
that '160|1024' (for example) means start transmitting when the FIFO has
fetched 160 bytes and don't stop fetching unless we hit 1024 bytes in the
fifo.
Store and forward mode (I believe) is a degenerate case where it fetches
the entire packet into the buffer before beginning transmission.
Bill Paul's if_pn driver doesn't react to an underflow at all.. it stays
at 72/128 permanently.
For what it's worth, the de cards are the only ones I've found that can
work at all on this system at 100Mbit. The realtek 8139 cards (cheap!)
went belly-up on the spot, no suprise there. I don't have an fxp card to
test.
> -Matt
Cheers,
-Peter
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
