Re: Linux USB file storage gadget with new UDC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux