Date: Sun, 24 Sep 2006 08:30:06 +1000 From: "Jan Mikkelsen" <janm@transactionware.com> To: "'Scott Long'" <scottl@samsco.org> Cc: freebsd-stable@freebsd.org Subject: RE: Patch: sym(4) "VTOBUS FAILED" panics on amd64, amd64/89550 Message-ID: <000f01c6df5f$d260e350$0202a8c0@transactzbkv04> In-Reply-To: <451368CA.1030404@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, Scott Long wrote: > > I can't see any mention of virtual address alignment in the=20 > bus_dma man > > page. Can it take care of virtual address alignment? If so, how? > > =20 >=20 > busdma makes no guarantees on virtual addresses. Thanks for the confirmation. I assume this is also true for = contigmalloc. =20 > Sigh, sorry I never got this fixed. The custom memory=20 > allocator made me > unhappy, and I never had time to dig into it. Do real docs=20 > 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).=20 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?000f01c6df5f$d260e350$0202a8c0>