Re: usb_buffer_alloc

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On Tue, Mar 10, 2009 at 4:27 PM, Russell King - ARM Linux
<linux@xxxxxxxxxxxxxxxx> wrote:
> On Tue, Mar 10, 2009 at 10:16:16AM -0700, Paul Thomas wrote:
>> >I dug into this a further, and confirmed that the call to
>> >usb_buffer_alloc() is indeed returning the faulty address.  Here is
>> >the allocation stack:
>>
>> >vm_region_alloc
>> >__dma_alloc
>> >dma_alloc_coherent
>> >hcd_buffer_alloc
>> >usb_buffer_alloc
>>
>> >Now, vm_region_alloc makes use of CONSISTENT_BASE, which is where the
>> >address 0xffc08000 comes from.
>
> Okay, so you got _coherent_ memory.
>
>>  However, when the URB is submitted, a
>> >call to dma_cache_maint, and the virt_addr_valid() check triggers the
>> >BUG().
>
> And you've passed it via a function which wants to _remap_ the coherent
> memory using the dma_map_* calls.  That's totally invalid.  For
> dma_map_single, the DMA API document says:
>
> | Notes:  Not all memory regions in a machine can be mapped by this
> | API.  Further, regions that appear to be physically contiguous in
> | kernel virtual space may not be contiguous as physical memory.  Since
> | this API does not provide any scatter/gather capability, it will fail
> | if the user tries to map a non-physically contiguous piece of memory.
> | For this reason, it is recommended that memory mapped by this API be
> | obtained only from sources which guarantee it to be physically contiguous
> | (like kmalloc).
>
> And, since ARM is a non-coherent architecture unlike x86, the DMA
> supporting functions are a lot more complex.  (x86 they're basically
> no-ops.)  The result is that we _have_ the restriction that any
> remapped memory (such as via dma_alloc_coherent) can _never_ be passed
> via the streaming DMA API.  Only memory from kmalloc or get_free_page
> can.
>
> I can't say where the problem lies, but essentially what's happening in
> the USB stack (passing a coherent DMA buffer to the streaming DMA API)
> is a bug in the USB stack somewhere.
>

Russell,

Thanks for your response. A little more info, this is using the OHCI
HCD on the at91rm9200 processor. I've tested up to the 2.6.28 series
with (and without) the maxim.org.za patches.

thanks,
Paul

-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm
FAQ:        http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette:  http://www.arm.linux.org.uk/mailinglists/etiquette.php


[Linux ARM]     [Linux ARM MSM]     [Linux ARM Kernel]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

Add to Google Follow linuxarm on Twitter