Maybe we can retry at this situation.
On 6/18/07, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I am looking at usb_sg_init().
>
> void usb_sg_wait (struct usb_sg_request *io)
> {
> int i, entries = io->entries;
>
> /* queue the urbs. */
> spin_lock_irq (&io->lock);
> for (i = 0; i < entries && !io->status; i++) {
> int retval;
>
> io->urbs [i]->dev = io->dev;
> retval = usb_submit_urb (io->urbs [i], GFP_ATOMIC);
>
> /* after we submit, let completions or cancelations fire;
> * we handshake using io->status.
> */
> spin_unlock_irq (&io->lock);
> switch (retval) {
> /* maybe we retrying will recover */
> case -ENXIO: // hc didn't queue this one
> case -EAGAIN:
> case -ENOMEM:
> io->urbs[i]->dev = NULL;
> retval = 0;
> i--;
> yield ();
> break;
>
> In essence this leaves handling a persistent failure to the generic
> scsi layer, which will timeout and abort the request. Is there any objection
> to report the URB where it failed to the immediate user and let him
> retry the remainder or handle the error any other way?
> I dimly remember discussing this routine in the past.
>
> Regards
> Oliver
> _______________________________________________
> Usb-storage mailing list
> [EMAIL PROTECTED]
> https://lists.one-eyed-alien.net/mailman/listinfo/usb-storage
>
-------------------------------------------------------------------------
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/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
