Subject: Re: bge(4) (DEGXA-TX) no-go on the AlphaServer ES40
To: NetBSD/alpha Discussion List <port-alpha@NetBSD.ORG>
From: Jason Thorpe <>
List: port-alpha
Date: 11/24/2004 15:15:42
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed

On Nov 19, 2004, at 12:06 PM, Greg A. Woods wrote:

> I suppose that's one good possibility.  The machine does seem to stay
> relatively stable even after the device is hung and so it's unlikely to
> be a more catastrophic bug such as a wild pointer scribbling all over.

Yah, with 16G of RAM, you will be using SGMAPs for DMA.  Although, it 
might be worth figuring out if we can use direct-mapped DMA windows 
here, since the bge and wm devices are DAC-capable.  I'll have to 
review the Tsunami documentation to see what is possible in this 

In any case, there are a couple of potential ways to work around the 
resource shortage:

1. Keep a "spare" Rx map that is loaded when the new mbuf is allocated. 
  If that fails, we free the newly-allocated mbuf and drop the packet, 
reusing the old map and mbuf in the ring.  If that succeeds, we then 
unload the old map, swap the maps (old map becomes spare map).

2. Defer creating the Rx maps until the interface is brought UP, and 
create them with BUS_DMA_ALLOCNOW so that all of the DMA resources 
they'll need will be pre-allocated.  This would have the advantage 
that, if there are not enough resources, you would know as soon as you 
tried to bring the interface UP.  When the interface was set to !UP, 
the driver would destroy the maps.

I've implemented (1), but am kind of leaning towards (2).  Thoughts 
from the audience?

         -- Jason R. Thorpe <>

content-type: application/pgp-signature; x-mac-type=70674453;
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

Version: GnuPG v1.2.3 (Darwin)