On 05/13/2012 02:30 PM, Alan Stern wrote:
transfer_buffer_is_ used for DMA. However the DMA access should always be finished before the buffer is deallocated. The DMA starts when proc_do_submiturb() calls usb_submit_urb(), and the DMA will end before async_completed() is called. You can add printk statements to those routines to trace the flow of control.
No - I don't see any such out of sync events. My output with added printk looks like this: <snip> proc_do_submiturb uurb->type==1:USBDEVFS_URB_TYPE_INTERRUPT proc_do_submiturb alloc tb:0xffff880055e8d068 async_completed tb:0xffff880055e8d068 last tb:0xffff88001a2af480 free_async free tb:0xffff880055e8d068 proc_do_submiturb uurb->type==3:USBDEVFS_URB_TYPE_BULK proc_do_submiturb alloc tb:0xffff880075324690 async_completed tb:0xffff880075324690 last tb:0xffff880055e8d068 free_async free tb:0xffff880075324690 proc_do_submiturb uurb->type==1:USBDEVFS_URB_TYPE_INTERRUPT ============================================================================= BUG kmalloc-512 (Not tainted): Poison overwritten ----------------------------------------------------------------------------- INFO: 0xffff880055e8d068-0xffff880055e8d069. First byte 0x9d instead of 0x6b </snip> "tb" denotes the current transfer_buffer and "last tb" the one previously freed. free_async alway seems to follow nicely after a call to async_completed. The only suspicious thing I can see is, that it's always an uurb->type==USBDEVFS_URB_TYPE_BULK preceding the memory corruption. This occurred 4 times in an over night run and was alway preceded by the type==3 urb. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html