Re: Question regarding short transfers

On Tuesday 22 May 2007, Alan Stern wrote:
> On Tue, 22 May 2007, Curran, Dominic wrote:
> 
> > 
> > Lets say the Hosts Mass Storage driver wants to READ 12K:
> > 
> > I believe that the Host Controller driver (e.g. ehci_hcd) might see
> > something like this coming from usbcore:
> > 
> > 1) BULK OUT urb (31 bytes) [Contains READ10 command]
> > 2) BULK IN  urb (4K)       [data]
> > 3) BULK IN  urb (8K)       [data]
> > 4) BULK IN  urb (13 bytes) [status]
> 
> Correct.  However 1) must complete before 2) and 3) are submitted, and 
> 3) must complete before 4) is submitted.  This is not a fundamental 
> limitation; it's just the way usb-storage currently works.
>
> > I have two questions regarding what happens when the transfer gets
> > terminated early:
> > 
> > 
> > 1) What happens if the device terminates the transfer after the 4KB
> > (with a zero-length packet)?  
> > 
> > Does the HC driver...
> > - set status to 0 in the 4K urb (& actual_length=4096) and
> 
> Yes.
> 
> > - flush all other queued urbs for that EP (in this case the 8K urb) by
> > completing them with an error status ?  If so what is the status ?
> 
> Not exactly.  The 8K URB completes with an error status -EREMOTEIO.  

Because the URB_SHORT_NOT_OK was set, and it saw a zero length packet.

The usb-storage driver explicitly sets URB_SHORT_NOT_OK because that
zero length packet would be an error.  Actually, any short packet
would be an error -- not just a ZLP.  The host asked for 12KB, and
any short packet would mean the peripheral sent less than that,
which would be an error.


> However if there were any other URBs in the endpoint queue at that 
> time, the HCD would not flush them.  The flushing would be done by the 
> completion handler for the 8K URB; it would call usb_unlink_urb() for 
> all the remaining URBs.
> 
> 
> > 2) What happens if the device terminates the transfer during the 4KB
> > (after say 3700 bytes received, with a short packet)?  
> > 
> > Thus:
> > urb->transfer_buffer_length = 4096
> > urb->actual_length          = 3700
> > 
> > I believe that the HC driver should do the following test:
> > 
> > if( (urb->actual_length < urb->transfer_buffer_length) &&
> > 	(urb->transfer_flags & URB_SHORT_NOT_OK) )
> >  	urb->status = -EREMOTEIO;
> > 
> > So if URB_SHORT_NOT_OK is set then -EREMOTEIO will be returned And if
> > URB_SHORT_NOT_OK is not set the 0 will be returned.
> > 
> > Is this correct ?
> 
> Yes.  The same thing would happen to the 8K URB in your first question.
> 
> > Again I assume that the 8K urb should be completed immediately ?
> > If so with what status ?
> 
> No.  The 4K URB's completion handler would see the -EREMOTEIO error and 

TYPO -- 8K, not 4K ...

> would unlink the 8K URB, which would then complete with status 
> -ECONNRESET.

Well, you're consistent with the typo; but the -ECONNRESET
path would be accurate if instead of an 8KB urb there were
in fact two 4KB ones.

 
> > I'm having trouble understand the EHCI code; In the EHCI driver where
> > are these situation handled ?  qh_completions() ?
> 
> Part of your trouble is because some of these situations are handled 
> outside the EHCI driver.  Take a look at the usb_sg_* routines in 
> drivers/usb/core/message.c.  Also read the kerneldoc comments in 
> drivers/usb/core/urb.c and read Documentation/usb/error-codes.txt.

Right.

- Dave

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel