Hi, >> I think the get_next_command() calls start_transfer() to read the next >> CBW. After unknown command 0xa1 is received, and if UDC driver doesn't >> halt the endpoint, why the get_next_command() does not call >> start_transfer() to read the next CBW? Somehow, i don't understand. > > I think that the previous call to start_transfer() never returned. > Probably because the usb_ep_queue() routine got hung up. Therefore > get_next_command() wasn't executed. > > Here's an extract from the log you posted, showing the 0xa1 command: > >> [start_transfer] f 40a08 >> ept1 out queue len 0x200, buffer 0xc12ac000 >> g_file_storage gadget: bulk-out, length 31: >> 00000000: 55 53 42 43 12 00 00 00 00 02 00 00 80 00 0c a1 >> 00000010: 08 2e 00 01 00 00 00 00 ec 00 00 00 f8 9e 34 >> bulk_out_complete --> 0, 31/31 >> 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? >> 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. > 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. > At this point, the host got tired of waiting for the gadget to accept > the next CBW, so it issued a port reset. Yes, i fully agree! 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