Patch: sym(4) "VTOBUS FAILED" panics on amd64, amd64/89550

[Jan Mikkelsen]

Hi,

Scott Long wrote:
> > I can't see any mention of virtual address alignment in the 
> bus_dma man
> > page.  Can it take care of virtual address alignment?  If so, how?
> >  
> 
> busdma makes no guarantees on virtual addresses.

Thanks for the confirmation.  I assume this is also true for contigmalloc.
 
> Sigh, sorry I never got this fixed.  The custom memory 
> allocator made me
> unhappy, and I never had time to dig into it.  Do real docs 
> on sym exist
> somewhere?  I'm not against sitting down and re-writing the physical
> memory handling to both work and conform to the FreeBSD APIs.

Yes.  This problem is caused by the custom allocator rather than any
"special" requirement for memory allocation.  It looks (to me) like the
custom allocator could just be ripped out and replaced with calls to
contigmalloc/bus_dma/malloc(9).  Ultimately the internal allocator will grow
a pool by calling contigmalloc or bus_dma (depending on the pool), so
calling those functions from the contexts in which the internal allocator is
called should be OK (or an existing bug). 

Calling malloc(9) might even be more appropriate than contigmalloc(9) where
the allocated memory does not get used for DMA.  The driver currently uses
bus_dma for memory that requires DMA, contigmalloc otherwise.

The work seems to be in maintaining a virtual to physical mapping for the
objects the driver cares about (ie: all the vtobus() calls).  It looks like
it might be possible to use a pmap_* call to do this, but that seems to
require a pmap_t.  Is there bus_dma approach other than remembering?

Is there a pointer to a document on the preferred memory management model
for FreeBSD drivers?

I might have a look at this on Monday.

Regards,

Jan.