Re: Linux USB file storage gadget with new UDC

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

 



Hi,

>> I made some changes regarding req.actual. Now the UDC driver still
>> cannot process SCSI_WRITE_10 command. Please see the attached UDC
>> driver log when i try to write to a text file. There should be three
>> SCSI commands in the log: SCSI_REQUEST_SENSE, SCSI_TEST_UNIT_READY and
>> SCSI_WRITE_10. SCSI_WRITE_10 is not received properly.
>
> No, it isn't.  Here's what the log says:
>
>> EP1 OUT IRQ 0x28
>> ep1_out: RX DMA done : NULL REQ on OUT EP-1
>> [start_transfer] 53425355 10d
>> ept1 out queue len 0x200, buffer 0xc1304000
>> g_file_storage gadget: bulk-out, length 31:
>
> This is from bulk_out_complete, when the WRITE(10) was received.
>
>> EP1 OUT IRQ 0x28
>> epnum 1 in 0 len 0 512 0
>> g_file_storage gadget: bulk-out, length 0:
>
> This line indicates a bug.  It means the UDC driver called
> bulk_out_complete again, even though the previous request was no longer
> queued and no new requests had been submitted yet.
>
> It is likely that this bug occurs because you don't use a spinlock in
> kagen2_ep_queue.  Does the interrupt handler routine use a spinlock?

Spinlock is Not used in interrupt handler routine.

>[start_transfer] 53425355 10d
>ept1 out queue len 0x200, buffer 0xc1304000
>g_file_storage gadget: bulk-out, length 31:

Is the kagen2_ep_queue function gotten interrupted here? So the
kagen2_ep_queue and interrupt routine need spinlock for
synchronisation?

>EP1 OUT IRQ 0x28
>epnum 1 in 0 len 0 512 0
>g_file_storage gadget: bulk-out, length 0:

> Maybe you haven't noticed this, but the REQUEST SENSE and TEST UNIT
> READY commands weren't received correctly either.  The last three bytes
> in each command should be 0, but they aren't.  They are: c3 63 4a.
> Where did those values come from?

Yes, i haven't noticed the c3 63 4a. Clearly the last three bytes
should be zero. Maybe the UDC driver has a bug (Do the last 3 bytes
matter for file gadget? ). Here is the usbmon trace that corresponds
to the UDC log. It is the proof that the last three bytes are zero.

Thanks,
victor

Attachment: scsi_write_10_again02.log
Description: Binary data


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

  Powered by Linux