...@freebsd.org wrote:
On Friday, September 24, 2010 9:00:44 pm Neel Natu wrote:
Hi,
This patch fixes the bogus error message from bus_dmamem_alloc() about
the buffer not being aligned properly.
The problem is that the check is against a virtual address as opposed
bus_dmamem_alloc() about
the buffer not being aligned properly.
The problem is that the check is against a virtual address as opposed
to the physical address. contigmalloc() makes guarantees about
the alignment of physical addresses but not the virtual address
mapping it.
Any objections if I
Natu wrote:
Hi,
This patch fixes the bogus error message from bus_dmamem_alloc() about
the buffer not being aligned properly.
The problem is that the check is against a virtual address as opposed
to the physical address. contigmalloc() makes guarantees about
the alignment of physical
On Friday, September 24, 2010 9:00:44 pm Neel Natu wrote:
Hi,
This patch fixes the bogus error message from bus_dmamem_alloc() about
the buffer not being aligned properly.
The problem is that the check is against a virtual address as opposed
to the physical address. contigmalloc() makes
Hi John,
Thanks for reviewing this.
On Mon, Sep 27, 2010 at 8:04 AM, John Baldwin j...@freebsd.org wrote:
On Friday, September 24, 2010 9:00:44 pm Neel Natu wrote:
Hi,
This patch fixes the bogus error message from bus_dmamem_alloc() about
the buffer not being aligned properly.
The problem
Hi,
This patch fixes the bogus error message from bus_dmamem_alloc() about
the buffer not being aligned properly.
The problem is that the check is against a virtual address as opposed
to the physical address. contigmalloc() makes guarantees about
the alignment of physical addresses
Hi everyone,
It seems like there are starting to be some drivers that need to
allocate large chunks of DMA-able memory, and since bus_dmamem_alloc()
on most architectures is always physically contiguous, it may not work
for them.
It seems like we could use the new sglist routines to help us here
Hello,
I would like to know if it is safe to use the BUS_DMA_WAITOK flag with
bus_dmamem_alloc(), in the context of the device_attach routine? Many
drivers use BUS_DMA_NOWAIT.
I need a 32Ko buffer and on low memory my driver cannot attach
(bus_dmamem_alloc returns ENOMEM). Will BUS_DMA_WAITOK
On Friday 13 February 2009 9:22:05 am Patrick Lamaizière wrote:
Hello,
I would like to know if it is safe to use the BUS_DMA_WAITOK flag with
bus_dmamem_alloc(), in the context of the device_attach routine? Many
drivers use BUS_DMA_NOWAIT.
Yes, it is ok to use in an attach routine.
I need
haven't worked on it in a long time..
Of course the driver uses busdma to be as machine-independent as possible.
One problem I've encountered is that bus_dmamem_alloc is inadequate for my
needs. The CX2388x only understands 32-bit physical addreses, and the driver
This restriction is set
often the case with just MPEG TS,
but once you add analog video there's usually not enough room.
For case 1), I malloc(9) the buffers and then feed them to busdma, since
on most machines bus_dmamem_alloc just calls contigmalloc. Use of
malloc(9) is suboptimal as it may result in bounce
Hello,
I've written a FreeBSD driver for Conexant CX2388x-based PCI TV capture cards.
Of course the driver uses busdma to be as machine-independent as possible.
One problem I've encountered is that bus_dmamem_alloc is inadequate for my
needs. The CX2388x only understands 32-bit physical
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
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
On Thu, 17 Feb 2005, Gerald Heinig wrote:
GHHi hackers,
GH
GHI've come across weird behaviour in bus_dmamem_alloc() whilst trying to
GHallocate small memory blocks (less than PAGE_SIZE) which have to be
GHaligned to PAGE_SIZE.
GHMy segment size is 2048, my maximum number of segments is 1 (it MUST
the 16 page chunk making it unable to reallocatable
by you,
so the next bus_dmamem_alloc() looks for the next 16 page
contiguous
chunk. This continues until there is no more 16 page contiguous
chunks
available and the bus_dmamem_alloc() fails. FreeBSD does not have
a
physical memory
Gary Thorpe wrote:
Really, there's a lot of the kernel which could be pageable,
which would help this. But for this to work, all the code
in the paging path has to be marked non-pageable.
The way Windows handles this is to have seperate ELF sections
for pageable vs. unpageable vs.
I'm writting a PCI device driver that needs to allocate large
aligned chunks of DMA memory for the hardware's queues. After loading
and unloading the driver a number of times, bus_dmamem_alloc starts to
fail.
In the device attach, the allocation code looks like (error checking
removed for brevity
since the allocated space is larger that a physical page (65536 4096),
bus_dmamem_alloc() allocates physical contiguous memory. After repeated
allocations and frees, the physical memory pages will fragment and the
allocation will fail.
You may need to rethink your allocation strategy
On Fri, Nov 15, 2002 at 10:36:18AM -0600, mark tinguely wrote:
since the allocated space is larger that a physical page (65536 4096),
bus_dmamem_alloc() allocates physical contiguous memory. After repeated
allocations and frees, the physical memory pages will fragment and the
allocation
On Fri, Nov 15, 2002 at 10:36:18AM -0600, mark tinguely wrote:
since the allocated space is larger that a physical page (65536 4096),
bus_dmamem_alloc() allocates physical contiguous memory. After repeated
allocations and frees, the physical memory pages will fragment
bus_dmamem_alloc() looks for the next 16 page contiguous
chunk. This continues until there is no more 16 page contiguous chunks
available and the bus_dmamem_alloc() fails. FreeBSD does not have a
physical memory defragmenter.
Ok, I get it now. Thanks to all for the explanation. Would a physical
by you,
so the next bus_dmamem_alloc() looks for the next 16 page contiguous
chunk. This continues until there is no more 16 page contiguous chunks
available and the bus_dmamem_alloc() fails. FreeBSD does not have a
physical memory defragmenter.
Ok, I get it now. Thanks to all
23 matches
Mail list logo
