On Mon, 27 May 2013, victor yeo wrote: > > I can't say much more without seeing the code. However, you should not > > need to wait for the hardware to do something -- instead the interrupt > > handler routine should be called when the hardware is finished. > > Yes, it is silly. The hardware interrupt is not being generated for > every SCSI command received, so the driver has to poll. I put the > polling code in a thread, and this dilemma is fixed. Are you sure about this? If it is correct, you should _fix_ the interrupt problem. Don't try to work around it by creating a new thread. Figure out why there isn't an interrupt. Does your driver forget to set an interrupt-enable bit? > I still observe the SCSI_WRITE_10 command time out sometimes. When > time out happens, the gadget log shows: > > g_file_storage gadget: invalid CBW: len 512 sig 0x6f007442 > g_file_storage gadget: bulk-in set wedge > > Is it because the gadget expects 31 byte command, but 512 byte data is > received instead? No. It is because kagen2_ep_queue returned _before_ a new command was received, probably as a result of your polling thread. Since there was no new command, the data in the buffer was wrong. > The full UDC/gadget log is attached. Hope it is useful. If not, i will > add in more printk statements. You can see the problem in the log: > g_file_storage gadget: bulk-in, length 13: > 00000000: 55 53 42 53 50 00 00 00 00 00 00 00 00 > [start_transfer] 53425355 50 > ept1 in queue len 0xd, buffer 0xc0c3c000 > 0: 0x53425355 > 4: 0x50 > 8: 0x0 > bulk_in_complete --> 0, 13/13 That was the end of the previous command. Now the gadget waits for a new command to arrive. > [start_transfer] 6f007442 7000 > ept1 out queue len 0x200, buffer 0xc1338000 > before kagen2_ep_queue > after kagen2_ep_queue > kagen2_ep_queue 512 512 512 > [kagen2_ep_queue] 6f007442 7000 kagen2_ep_queue returned but there was no interrupt. This means no new data was received, so the old data is still in the buffer. > g_file_storage gadget: bulk_out_complete --> 0, 512/31 > g_file_storage gadget: invalid CBW: len 512 sig 0x6f007442 > g_file_storage gadget: bulk-in set wedge That 0x6f007442 is the old data from the previous command, as you can see from the log messages (it is the same data that was present when kagen2_ep_queue was called). 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
