Hi, >> 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 Thanks! This packet is the CSW to the unknown SCSI command 0xa1. So it should not be sent at all, and the UDC driver should send the STALL packet instead of this CSW? Just curious, after this 0xa1 is received and bulk-in endpoint is halted. The Linux host tries to send TEST_UNIT_READY command, and UDC driver could not receive it because endpoint is halted and in reset condition. Seems like the set Halt feature is working (but STALL packet is not sent). 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
