On Wed, 17 Apr 2013, victor yeo wrote: > >> g_file_storage gadget: SCSI command: Unknown xa1; Dc=12, Du=0; Hc=12, Hi=512 > >> g_file_storage gadget: bulk-in, length 0: > >> [start_transfer] 43425355 12 > >> ept1 in queue len 0x0, buffer 0xc12ac000 > >> g_file_storage gadget: bulk-in set halt > > I think here is the problem: the bulk-in of length 0. This zero > length packet is never sent out nor received by the host. What is this > zero length packet? A data packet has three parts: a Packet ID (PID) byte, which is either DATA0 or DATA1 for bulk transfers; some variable number N of data bytes; two Cyclic Redundancy Check (CRC) bytes. A zero-length data packet is one in which N = 0. Such packets contain exactly three bytes: a PID and two CRC bytes. See Sections 8.3 and 8.4.4 of the USB-2.0 specification. > >> kagen2_set_halt 1 1 > >> g_file_storage gadget: sending command-failure status > >> g_file_storage gadget: sense data: SK x05, ASC x20, ASCQ x00; info x0 > >> g_file_storage gadget: bulk-in, length 13: > >> 00000000: 55 53 42 53 12 00 00 00 00 02 00 00 01 > >> [start_transfer] 53425355 12 > >> ept1 in queue len 0xd, buffer 0xc133c000 > >> 0: 0x53425355 > >> 4: 0x12 > >> 8: 0x200 > > In comparison, the CSW is sent out and received by the host. Yes. You are right; the usbmon trace shows that the host did not receive the zero-length packet. > > It looks like the UDC driver get hung up right here, somewhere inside > > the usb_ep_queue() routine. > > I think the usb_ep_queue() routine is re-entrant. If one instance of > it hangs, the next instance will not be affected. That doesn't matter. If send_status() calls start_transfer(), which calls usb_ep_queue(), and usb_ep_queue() never returns, then send_status() never returns and therefore the main loop in fsg_main_thread() can't continue past the call to send_status(). It never loops back for another call to get_next_command(). 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
