Hi, >> 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. Looking at the log, the UDC driver queue function is called repeatedly by start_transfer() before SCSI_INQUIRY is received. Is this ok? [start_transfer] ebfffffe e5943010 ept1 out queue len 0x200, buffer 0xc133c000 bulk_out_complete --> 0, 0/31 >> 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? > > No. As long as the Halt feature is set for the bulk-in endpoint, the > UDC should send STALL packets. When the host clears the Halt feature, > then the UDC should send the CSW packet. > >> 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. > > That sounds very wrong. The bulk-IN endpoint was halted, but the TEST > UNIT READY command is sent to the bulk-OUT endpoint. There should be > no problem receiving it. When debugging the UDC driver halt problem, i disable setting the halt feature for bulk-in endpoint and does not call fsg_disconnect() when reset interrupt occurs. Now when unknown SCSI command 0xa1 is received, the usbmon trace still shows the same error, and subsequent TEST_UNIT_READY is not received by UDC driver, and (-104) is connection reset error. It seems that UDC and gadget driver somehow still reset the USB connection? Driver has to reset the USB connection when unknown SCSI command is received? f3a2b7c0 486132750 S Bo:2:060:1 -115 31 = 55534243 12000000 00020000 80000ca1 082e0001 00000000 ec000000 000000 f3a2b7c0 486132805 C Bo:2:060:1 0 31 > f2c92340 486132814 S Bi:2:060:1 -115 512 < f2c92340 486236946 C Bi:2:060:1 -121 13 = 55534253 12000000 00020000 01 f3a2b7c0 486237000 S Bi:2:060:1 -115 13 < f3a2b7c0 493408020 C Bi:2:060:1 -104 0 ..... f3a2b7c0 493652682 S Bo:2:060:1 -115 31 = 55534243 13000000 00000000 00000600 00000000 00000000 00000000 000000 f3a2b7c0 493652755 C Bo:2:060:1 0 31 > f3a2b7c0 493652761 S Bi:2:060:1 -115 13 < f3a2b7c0 503652077 C Bi:2:060:1 -104 0 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
