On Fri, 12 Apr 2013, victor yeo wrote: > Thanks, i print out additional information in gadget driver and UDC > driver. Here are another problem. In usbmon trace, the time difference > between first SCSI_INQUIRY command and the second TEST_UNIT_READY > command is large. So i check the driver log file. When SCSI_INQUIRY is > received, start_transfer() is called, then UDC ep_queue function is > called, then bulk_out_complete() is called. This sequence is repeated > many times. In fact, this problem starts even _before_ the INQUIRY command is received. The log shows that the UDC driver calls the bulk_out_complete routine over and over, even though no packet was received and ka2000_ack_irq didn't run. The same thing happens after the INQUIRY is received. The UDC driver is not supposed to call bulk_out_complete until a transfer has completed. After the gadget was reset, the problem didn't occur any more. > What is the reason that SCSI_INQUIRY is not processed by > gadget driver? Is it due to some problem in UDC driver? The INQUIRY _was_ processed by the gadget driver. Yes, the UDC driver has a problem; see above. > After that, i can see when the unknown command 0xa1 is received, the > UDC driver sets the Halt feature. Look at line 1339 of the UDC log file: > g_file_storage gadget: SCSI command: MODE SENSE(6); Dc=6, Di=192; Hc=6, Hi=192 > g_file_storage gadget: bulk-in, length 16: > 00000000: 0f 00 00 00 08 0a 04 00 ff ff 00 00 ff ff ff ff > [start_transfer] f 40a08 > ept1 in queue len 0x10, buffer 0xc12ac000 > 0: 0xf > 4: 0x40a08 > 8: 0xffff > c: 0xffffffff > ka2000_ack_irq(32) > bulk_in_complete --> 0, 16/16 At this point the gadget driver tries to do a set-halt: > g_file_storage gadget: bulk-in set halt > kagen2_set_halt 1 1 When the Halt feature is set, the UDC is supposed to send a STALL packet to the host -- but it did not. Instead it sent this 13-byte bulk-IN packet. > g_file_storage gadget: bulk-in, length 13: > 00000000: 55 53 42 53 08 00 00 00 b0 00 00 00 00 > [start_transfer] 53425355 8 > ept1 in queue len 0xd, buffer 0xc133c000 > 0: 0x53425355 > 4: 0x8 > 8: 0xb0 > bulk_in_complete --> 0, 13/13 The same thing happened when the 0xA1 command was received: > 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 > kagen2_set_halt 1 1 Right here, a STALL packet should have been sent. It wasn't. > 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 > bulk_in_complete --> 0, 13/13 Instead this packet was sent. 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
