Am Montag, 18. Juni 2007 schrieb David Brownell:
> On Monday 18 June 2007, Alan Stern wrote:
> > On Mon, 18 Jun 2007, Oliver Neukum wrote:
> >
> > > Hi,
> > >
> > > I am looking at usb_sg_init().
> >
> > > 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.
> >
> > You could make usb_sg_wait just wait until the part already submitted
> > was finished, then go back and retry the remainder. I think that would
> > be simpler.
>
> Which resembles what that code excerpt is *supposed* to be doing.
> Although yield() is now known to behave rudely, so msleep(1) would
> be better. (Previously noted in the last week or so...)
I'll do that.
> It doesn't actually need to wait for anything more than enough
> memory becoming available. Which you can tell by succeeding on
> the next pass through the submit loop.
OK, it seems to me that I looked at the problem from the wrong
angle. Indeed this code will eventually succeed if enough memory is
available to submit the worst fragment.
However, we allocate all URBs before we submit any of them. This
seems to be almost designed to suck up all reserves without achieving
progress. I think there needs to be a fallback if the sg stuff cannot get
all the URBs it wants.
Regards
Oliver
-------------------------------------------------------------------------
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
