Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 24 Jan 1999 10:13:32 +0800
From:      Peter Wemm <peter@netplex.com.au>
To:        Matthew Dillon <dillon@apollo.backplane.com>
Cc:        N <niels@bakker.net>, current@FreeBSD.ORG
Subject:   Re: panic: found dirty cache page 0xf046f1c0 
Message-ID:  <199901240213.KAA01206@spinner.netplex.com.au>
In-Reply-To: Your message of "Sat, 23 Jan 1999 17:46:21 PST." <199901240146.RAA54333@apollo.backplane.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
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 majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901240213.KAA01206>