Re: Linux USB file storage gadget with new UDC

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

 



Hi,

>> I think the get_next_command() calls start_transfer() to read the next
>> CBW. After unknown command 0xa1 is received, and if UDC driver doesn't
>> halt the endpoint, why the get_next_command() does not call
>> start_transfer() to read the next CBW? Somehow, i don't understand.
>
> I think that the previous call to start_transfer() never returned.
> Probably because the usb_ep_queue() routine got hung up.  Therefore
> get_next_command() wasn't executed.
>
> Here's an extract from the log you posted, showing the 0xa1 command:
>
>> [start_transfer] f 40a08
>> ept1 out queue len 0x200, buffer 0xc12ac000
>> g_file_storage gadget: bulk-out, length 31:
>> 00000000: 55 53 42 43 12 00 00 00 00 02 00 00 80 00 0c a1
>> 00000010: 08 2e 00 01 00 00 00 00 ec 00 00 00 f8 9e 34
>> bulk_out_complete --> 0, 31/31
>> 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?

>> 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.

> 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.

> At this point, the host got tired of waiting for the gadget to accept
> the next CBW, so it issued a port reset.

Yes, i fully agree!

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




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

  Powered by Linux