[Xen-devel] Re: [linux-usb-devel] Error recovery in Xen's paravirtualizing USB driver for Linux

[Harry Butterworth <harry@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>]

On Wed, 2005-12-07 at 14:35 -0500, Alan Stern wrote:

> >     I did have a problem with URBs getting reordered on their way
> > between the front-end and the back-end which led to miscompares where
> > the correct bulk data was written on the USB key but at the wrong LBA. I
> > fixed this by maintaining submission ordering in the URB queue from
> > front-end to back-end.
> 
> Clearly this is necessary for any queue, not just queues of USB URBs.

Some queues, for example sets of SCSI queue simple commands, are allowed
to be reordered.  This is useful for rotational position optimisation on
single disk drives and concurrency on RAID arrays.  Ordering makes sense
for USB though---it just didn't click with me immediately.

> Failing isn't the right approach.  The back-end should unlink all those 
> URBs but keep them available, so that they can be resubmitted if 
> necessary.  When the front-end learns about the error, it has the option 
> of unlinking the URBs or not -- if it doesn't unlink them then the 
> back-end should resubmit them.  Likewise for URBs received from the front 
> end before the flag is cleared; they should be kept on the queue so that 
> they can be submitted when the front-end's completion routine returns.

Thanks.  This is exactly the information I was looking for.

> Suspend/resume is liable to cause trouble.  For instance, what happens to 
> the various front-ends if the back-end decides to suspend a USB device?

I don't know.  Could you explain this scenario in more detail (imagine
that none of the 800 page USB spec sunk in when I read it :-).  What
should happen in this case?

-- 
Harry Butterworth <harry@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel