On Mon, 15 Apr 2013, victor yeo wrote: > >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 This is not a good question. You don't have to worry about start_transfer; it is part of file_storage.c and it works correctly. The problem is: Why does bulk_out_complete get called so many times? The UDC driver should not call bulk_out_complete if no bulk-out packets have been received. > 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. Why are you disabling this? You should fix it, not disable it. > 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? The reset is done by the host, not by the UDC or the gadget driver. I don't know why the subsequent TEST UNIT READY was not received. I can't tell what is happening inside the gadget and UDC just by reading the usbmon log (which was recorded on the host). 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
