--Apple-Mail-27-624374182
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 
regard.

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 <thorpej@shagadelic.org>


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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)

iD8DBQFBpRYeOpVKkaBm8XkRAj/CAJoCyhPLa88kyddVaHOgtKIVo50X0ACgiCfj
EvFKsDbfJISnwlLa3aUFJVg=
=cm0D
-----END PGP SIGNATURE-----

--Apple-Mail-27-624374182--