On Mon, 20 May 2013, victor yeo wrote: > When copying a file to the USB gadget, sometimes the USB gadget will > hang, sometimes the USB gadget will crash, sometimes the copy is ok. > > From the UDC driver log, when the USB gadget crashes, the host is > sending 16384 bytes of data. It seems that bulk_out_complete() is not > able to handle it. > > [<c03282ec>] (dev_printk+0x0/0x3c) from [<bf035924>] > (bulk_out_complete+0xc4/0x1a8 [g_file_storage]) > r3:152a0e00 r2:a020d0e5 > [<bf02fac4>] (kagen2_ep_queue+0x0/0x680 [kagen2_udc]) from > [<bf035f9c>] (bulk_in_complete+0x24c/0x1010 [g_file_storage]) > > The meaning of printk of "kagen2_ep_queue 512 16384 512" in UDC driver log: > ka_req->req.actual is 512 > ka_req->req.length is 16384 > length from hardware FIFO is 512 > > Please see the attached UDC driver log and corresponding usbmon trace.
I think the log says that bulk_out_complete() crashed when trying to dereference a NULL pointer. Maybe req->buf, maybe req->context, maybe something else. But you already know that bulk_out_complete() crashed; you don't need me to tell you that. What you _do_ need is to find out why the crash occurred. This means finding out which pointer is NULL. To do that, you need to add printk statements. I keep telling you this, but you don't go ahead and do it. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
