Date: Fri, 18 Feb 2005 08:30:42 +0100 (CET) From: Harti Brandt <hartmut.brandt@dlr.de> To: Gerald Heinig <gheinig@syskonnect.de> Cc: hackers@freebsd.org Subject: Re: bus_dmamem_alloc strangeness Message-ID: <20050218082720.S17278@beagle.kn.op.dlr.de> In-Reply-To: <4214D6A0.9010803@syskonnect.de> References: <4214D6A0.9010803@syskonnect.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 17 Feb 2005, Gerald Heinig wrote:
GH>Hi hackers,
GH>
GH>I've come across weird behaviour in bus_dmamem_alloc() whilst trying to
GH>allocate small memory blocks (less than PAGE_SIZE) which have to be
GH>aligned to PAGE_SIZE.
GH>My segment size is 2048, my maximum number of segments is 1 (it MUST be
GH>contiguous), my max. total segment size is also 2048 and my alignment
GH>constraint is 4k (PAGE_SIZE). However, the DMA memory I'm getting from
GH>bus_dmamem_alloc() is NOT aligned to 4k.
GH>
GH>The relevant code in sys/i386/i386/busdma_machdep.c is:
GH>
GH>=============================================================
GH>
GH> if ((dmat->maxsize <= PAGE_SIZE) &&
GH> dmat->lowaddr >= ptoa((vm_paddr_t)Maxmem)) {
GH> *vaddr = malloc(dmat->maxsize, M_DEVBUF, mflags);
GH> } else {
GH> /*
GH> * XXX Use Contigmalloc until it is merged into this facility
GH> * and handles multi-seg allocations. Nobody is doing
GH> * multi-seg allocations yet though.
GH> * XXX Certain AGP hardware does.
GH> */
GH> *vaddr = contigmalloc(dmat->maxsize, M_DEVBUF, mflags,
GH> 0ul, dmat->lowaddr, dmat->alignment? dmat->alignment :
GH>1ul,
GH> dmat->boundary);
GH> }
GH>==============================================================
GH>
GH>My lowaddr is BUS_SPACE_MAXADDR and I'm allocating 2k blocks which have to be
GH>4k-aligned, which would imply the first if branch.
GH>
GH>Surely the code should adhere to the alignment restrictions and not simply
GH>allocate memory without checking, or am I missing something here?
I discovered this problem when I wrote my ATM drivers years ago. My
workaround is to make sure that size >= alignment for all memory blocks by
just allocating larger blocks. This seems just to work up to now.
harti
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050218082720.S17278>