On Sun, 13 May 2012, Oncaphillis wrote: > > proc_do_submiturb() does several allocations. Can you figure out which > > one this is? > > This also seems to be the transfer_buffer. At least it's the kmalloc > following directly after the bug report of the slug although I don't get > the same address. I assume that slug allocts a new address if it detects It's "slub", not "slug". > an error. I also see kfrees of 0x00000 adresses when freeing > ios_pkt and setup_packet but I assume that its o.k. for kfree. Yes. > The error seems to hit less often if I insert more and more printk. > seems like its a matter of timing. Could it be the transfer_buffer is > used as a start_point for DMA, the driver starts up the DMA and assumes > to early that it failed ? That coul fit to the loss of 2 byte sequences > we see. The corrupting byes always seem to be 9d 8d. 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. Alan Stern -- 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
