On Wed, 25 Nov 2009, aditya uttam wrote:
> > The only reason you might see a problem would be if you called
> > usb_unlink_urb() and then tried to resubmit the URB before the
> > completion handler was invoked.
>
> NO. We are resubmitting the URB only after Completion handler was
> called. We are getting -104 as the URB status in completion handler.
>
> One more warning I forgot to mention in my last mail is, I am getting
> the message
> "Unlink after no-IRQ? Controller is probably using the wrong IRQ"
That message is harmless. It appears because dummy-hcd uses a timer
instead of IRQs.
> Does this show any effect on invoking the completion callbacks for the
> rest of URBs?
No.
> Please note that I am using dummy HCD and gadget driver.
Your gadget driver must be doing something wrong. When I tried testing
dummy-hcd by unlinking an URB and afterward reading from the same
endpoint, it worked perfectly. Here's the important part of the usbmon
log:
ef784160 639101508 S Bo:11:002:2 -115 31 = 55534243 0a000000 00100000 80000a28 00000000 00000008 00000000 000000
ef784160 639105125 C Bo:11:002:2 0 31 >
e8d636e0 639105171 S Bi:11:002:1 -115 4096 <
e8d636e0 699505122 C Bi:11:002:1 -104 0
ef784160 699505574 S Bo:11:002:2 -115 31 = 55534243 0b000000 00000000 00000600 00000000 00000000 00000000 000000
ef784160 699509135 C Bo:11:002:2 0 31 >
ef784160 699509227 S Bi:11:002:1 -115 13 <
ef784160 699513113 C Bi:11:002:1 0 13 = 55534253 0b000000 00000000 00
ef784160 699513447 S Bo:11:002:2 -115 31 = 55534243 0c000000 00100000 80000a28 00000000 00000008 00000000 000000
ef784160 699517122 C Bo:11:002:2 0 31 >
e8d63790 699517726 S Bi:11:002:1 -115 4096 <
e8d63790 699529119 C Bi:11:002:1 0 4096 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ef784160 699529150 S Bi:11:002:1 -115 13 <
ef784160 699533119 C Bi:11:002:1 0 13 = 55534253 0c000000 00000000 00
This was using a patched version of g_file_storage together with a
patched version of usb-storage. As you can see, the first 4096-byte
bulk-IN transfer from ep1 timed out after 64 seconds and was unlinked,
giving a -104 status code. The following 13-byte read from ep1 worked
normally, and then the 4096-byte read was retried.
Below is the patch I used for the test. You can try it yourself.
Remember to wait the full 64 seconds for the transfer to time out.
Alan Stern
Index: usb-2.6/drivers/usb/gadget/file_storage.c
===================================================================
--- usb-2.6.orig/drivers/usb/gadget/file_storage.c
+++ usb-2.6/drivers/usb/gadget/file_storage.c
@@ -1561,6 +1561,13 @@ static int do_read(struct fsg_dev *fsg)
unsigned int partial_page;
ssize_t nread;
+ static int first;
+
+ if (first == 0) {
+ first = 1;
+ return -EINTR;
+ }
+
/* Get the starting Logical Block Address and check that it's
* not too big */
if (fsg->cmnd[0] == SC_READ_6)
Index: usb-2.6/drivers/usb/storage/transport.c
===================================================================
--- usb-2.6.orig/drivers/usb/storage/transport.c
+++ usb-2.6/drivers/usb/storage/transport.c
@@ -835,7 +835,7 @@ Retry_Sense:
/* We must release the device lock because the pre_reset routine
* will want to acquire it. */
mutex_unlock(&us->dev_mutex);
- result = usb_stor_port_reset(us);
+ result = 0;
mutex_lock(&us->dev_mutex);
if (result < 0) {
--
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
