Re: bus_dmamem_alloc strangeness
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
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bus_dmamem_alloc strangeness
On Thu, 17 Feb 2005, Gerald Heinig wrote: Hi hackers, I've come across weird behaviour in bus_dmamem_alloc() whilst trying to allocate small memory blocks (less than PAGE_SIZE) which have to be aligned to PAGE_SIZE. My segment size is 2048, my maximum number of segments is 1 (it MUST be contiguous), my max. total segment size is also 2048 and my alignment constraint is 4k (PAGE_SIZE). However, the DMA memory I'm getting from bus_dmamem_alloc() is NOT aligned to 4k. You should e-mail Scott Long ([EMAIL PROTECTED]) about this directly. I believe that he has been working on related changes to busdma recently, but I'm not sure which branches have received his improvements. Mike "Silby" Silbersack ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
bus_dmamem_alloc strangeness
Hi hackers,
I've come across weird behaviour in bus_dmamem_alloc() whilst trying to
allocate small memory blocks (less than PAGE_SIZE) which have to be
aligned to PAGE_SIZE.
My segment size is 2048, my maximum number of segments is 1 (it MUST be
contiguous), my max. total segment size is also 2048 and my alignment
constraint is 4k (PAGE_SIZE). However, the DMA memory I'm getting from
bus_dmamem_alloc() is NOT aligned to 4k.
The relevant code in sys/i386/i386/busdma_machdep.c is:
=
if ((dmat->maxsize <= PAGE_SIZE) &&
dmat->lowaddr >= ptoa((vm_paddr_t)Maxmem)) {
*vaddr = malloc(dmat->maxsize, M_DEVBUF, mflags);
} else {
/*
* XXX Use Contigmalloc until it is merged into this facility
* and handles multi-seg allocations. Nobody is doing
* multi-seg allocations yet though.
* XXX Certain AGP hardware does.
*/
*vaddr = contigmalloc(dmat->maxsize, M_DEVBUF, mflags,
0ul, dmat->lowaddr, dmat->alignment? dmat->alignment : 1ul,
dmat->boundary);
}
==
My lowaddr is BUS_SPACE_MAXADDR and I'm allocating 2k blocks which have
to be 4k-aligned, which would imply the first if branch.
Surely the code should adhere to the alignment restrictions and not
simply allocate memory without checking, or am I missing something here?
Cheers,
Gerald
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
