Subject: Re: bge(4) (DEGXA-TX) no-go on the AlphaServer ES40
To: NetBSD/alpha Discussion List <port-alpha@NetBSD.ORG>
From: Jason Thorpe <email@example.com>
Date: 11/24/2004 15:15:42
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
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 <firstname.lastname@example.org>
content-type: application/pgp-signature; x-mac-type=70674453;
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)
-----END PGP SIGNATURE-----