Re: [linux-usb-devel] ehci_hcd map_single: unable to map unsafe buffer on a standard NSLU2

David Brownell wrote:
>> Here is an occurrence of it:
>> WARNING: at arch/arm/mm/consistent.c:364 dma_free_coherent()
>> [<c0025d8c>] (dump_stack+0x0/0x14) from [<c0027034>] 
>> (dma_free_coherent+0x38/0x200)
>> [<c0026ffc>] (dma_free_coherent+0x0/0x200) from [<c002b5bc>] 
>> (dma_unmap_single+0x144/0x164)
>> [<c002b478>] (dma_unmap_single+0x0/0x164) from [<bf003b9c>] 
>>     
>
> Obviously, whoever implemented dma_unmap_single() in terms of calls
> to dma_free_coherent() is the source of this particular problem.
>
>
>   
Right, and it is defined in arch/arm/common/dmabounce.c:
/*
 * see if a mapped address was really a "safe" buffer and if so, copy
 * the data from the safe buffer back to the unsafe buffer and free up
 * the safe buffer.  (basically return things back to the way they
 * should be)
 */

void
dma_unmap_single(struct device *dev, dma_addr_t dma_addr, size_t size,
                        enum dma_data_direction dir)
{
        dev_dbg(dev, "%s(ptr=%p,size=%d,dir=%x)\n",
                __func__, (void *) dma_addr, size, dir);

        BUG_ON(dir == DMA_NONE);

        unmap_single(dev, dma_addr, size, dir);
}

I am trying to understand dmabounce, why this problem occurs, and how to 
correct it
I hope with the help of linux-arm people...

>> (usb_hcd_giveback_urb+0xb0/0x108 [usbcore])
>>  r7:c08633e0 r6:c1190800 r5:c08633e0 r4:00000001
>> [<bf003aec>] (usb_hcd_giveback_urb+0x0/0x108 [usbcore]) from 
>> [<bf02a6b4>] (ehci_urb_done+0x78/0x80 [ehci_hcd])
>>  r6:c11908bc r5:c11908bc r4:c08633e0
>> [<bf02a63c>] (ehci_urb_done+0x0/0x80 [ehci_hcd]) from [<bf02c290>] 
>> (ehci_work+0x474/0x79c [ehci_hcd])
>>  r5:c084e2a0 r4:ffc28180
>> [<bf02be1c>] (ehci_work+0x0/0x79c [ehci_hcd]) from [<bf02df50>] 
>> (ehci_watchdog+0x64/0x6c [ehci_hcd])
>> [<bf02deec>] (ehci_watchdog+0x0/0x6c [ehci_hcd]) from [<c003fcb0>] 
>> (run_timer_softirq+0x14c/0x1e0)
>>  r5:00000100 r4:c02914a0
>> [<c003fb64>] (run_timer_softirq+0x0/0x1e0) from [<c003c028>] 
>> (__do_softirq+0x5c/0xd0)
>>  r7:c02a7314 r6:0000000a r5:c0291284 r4:00000001
>> [<c003bfcc>] (__do_softirq+0x0/0xd0) from [<c003c3f4>] (irq_exit+0x44/0x4c)
>>  r6:00000000 r5:c0278144 r4:00000005
>> [<c003c3b0>] (irq_exit+0x0/0x4c) from [<c0021048>] 
>> (__exception_text_start+0x48/0x60)
>> [<c0021000>] (__exception_text_start+0x0/0x60) from [<c0021a24>] 
>> (__irq_svc+0x24/0x80)
>> Exception stack(0xc0271f64 to 0xc0271fac)
>> 1f60:          c0885580 00000002 c0270000 00000000 c0022f50 c0270000 
>> c001ff50
>> 1f80: c02a7314 0001e0ec 690541f1 0001dee4 c0271fc0 c0271fac c0271fac 
>> c0022d30
>> 1fa0: c0022d38 60000013 
>> ffffffff                                             
>>  r6:00000020 r5:0000001f r4:ffffffff
>> [<c0022cf8>] (cpu_idle+0x0/0x54) from [<c01e5ad8>] (rest_init+0x48/0x58)
>>  r5:c028b828 r4:c029446c
>> [<c01e5a90>] (rest_init+0x0/0x58) from [<c0008bd8>] 
>> (start_kernel+0x280/0x2ec)
>> [<c0008958>] (start_kernel+0x0/0x2ec) from [<00008030>] (0x8030)
>>     
>
>