On Thu, Aug 6, 2009 at 9:14 PM, Alan Stern<stern@xxxxxxxxxxxxxxxxxxx> wrote:
>> As I explained in my previous emails, I have implemented the multiple
>> threads (two threads) in the gadget driver and it is working fine when
>> the storage driver issues commands sequentially. However, when the
>> storage driver issues the multiple commands (currently 2 commands at a
>> time) to the gadget driver, the gadget is not able to handle them. The
>> issue is like this, in the gadget driver, one thread sends the status
>> on the bulk in pipe which is for 10 bytes where as storage requested 4
>> bytes and 10 bytes from two different threads. The gadget driver is
>> expecting 10 bytes first but the bulk_in callback gets 4 bytes which
>> results in a crash.
>
> I don't understand. Can you explain the problem more clearly?
The gadget driver has two threads. First thread sends 10 bytes of data
on bulk-in pipe. Second thread sends 4 bytes of data on same bulk-in
pipe. After the bulk-in transfer is finished bulk-in callback is
called for 4 bytes of data instead of 10 bytes data. So there is a
mismatch of actual data sent to received data length. The below code
fails.
bulk_in_complete()
{
.
.
//Here req->actual is not equal req->length
if (req->status || req->actual != req->length)
DBG(fsg, "%s --> %d, %u/%u\n", __func__,
req->status, req->actual, req->length);
.
.
}
The debug message I get here is "bulk-in --> 4/10". The storage driver
callback is invoked and gets EOVERFLOW(-75) as URB status.
The bulk-in complete is expecting 10 bytes but the callback is invoked
with 4 bytes. The storage driver has multiple threads as gadget driver
where it can send multiple commands from each thread.
So, is there any way I can synchronize data on same pipe in the gadget driver.
>
> I really don't understand why you are doing this. What reason is there
> to have more than one thread? Is it really much faster to submit two
> I/O operations at a time than to wait for the first operation to finish
> before submitting the second?
>
I have implemented the multiple threads in the gadget driver code to
handle the multiple commands in the gadget driver code. The storage
driver issues the multiple commands to the device without waiting for
the response from the device for each command. That is the reason, I
have implemented the threads in the gadget driver code to handle the
multiple commands. While processing one thread one command, the main
thread receives the another command and passes it to the another,
second, thread. Here, the first thread and the second thread uses the
same pipe. For making the storage driver asynchronous, these
modifiations are required in the gadget driver code. Please refer to
same thread dated on 22-July-2009 which describes about the design.
Thanks and regards,
Madhavi M.
--
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
