Hi, >> 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. Thanks! Indeed, the req->buf pointer was the one causing the crash problem. It happened when combining multiple 512 bytes data. I have fixed this bug. Now my UDC driver is almost ready. That is probably one more SCSI command timeout problem remaining, i am adding more printk to UDC driver and studying it. Thanks, victor -- 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
