On Wed, 17 Apr 2013, victor yeo wrote:
> >> 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
>
> I think here is the problem: the bulk-in of length 0. This zero
> length packet is never sent out nor received by the host. What is this
> zero length packet?
A data packet has three parts:
a Packet ID (PID) byte, which is either DATA0 or DATA1 for
bulk transfers;
some variable number N of data bytes;
two Cyclic Redundancy Check (CRC) bytes.
A zero-length data packet is one in which N = 0. Such packets contain
exactly three bytes: a PID and two CRC bytes. See Sections 8.3 and
8.4.4 of the USB-2.0 specification.
> >> kagen2_set_halt 1 1
> >> 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
>
> In comparison, the CSW is sent out and received by the host.
Yes. You are right; the usbmon trace shows that the host did not
receive the zero-length packet.
> > It looks like the UDC driver get hung up right here, somewhere inside
> > the usb_ep_queue() routine.
>
> I think the usb_ep_queue() routine is re-entrant. If one instance of
> it hangs, the next instance will not be affected.
That doesn't matter. If send_status() calls start_transfer(), which
calls usb_ep_queue(), and usb_ep_queue() never returns, then
send_status() never returns and therefore the main loop in
fsg_main_thread() can't continue past the call to send_status(). It
never loops back for another call to get_next_command().
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
