Actually my current thought is that the bulk queuing ought
to have those exact semantics ... and it's such "fault" handling
that's exactly where I mentioned (privately) that I see the
problems coming, similarly on the write side and in terms
of cancellation. I don't think our HCs do that "right", either
in the spec sense (see next) or the pragmatic "code does
reasonable things" sense (consider your scenario).
A scan of the usb spec (2.0) turns up a few reference to
such behaviors. 5.3 says that when a non-ISO pipe gets
a stall or error, the current IRP (translate as URB :) is
"aborted/retired", ditto all other outstanding ("queued")
ones. I believe that none of our HC drivers handle that
requirement. (And usbcore should likely handle the
additional requirement to reject requests to halted pipes.)
Similarly, 10.5.2.2 says that when the "client" (device
driver) talks to the USBD (usbcore+hcd) to abort a
pipe, "all of the IRPs scheduled for a pipe" are retired
and returned to the client; same when the pipe is reset.
(Umm ... we don't seem to have that primitive, not that
it's a requirement according to 10.5.3.2, unlike aborting
an individual pipe.) Though usb_unlink_urb() isn't much
like a usb_abort_pipe()... it'd be cleaner in the case of
queued URBs though!
I just did a quick grep of the drivers, and I notice that not
many drivers use the BULK_QUEUE flag:
- bluetooth, write side only
- se401, read side (but only for one URB? NOP...)
- serial/empeg, read and write (quick glance suggests
only one read is ever queued at a time though)
- serial/io_edgeport, write side only
- seriial/visor, write side only
- usbnet, read and write (still disabled as unreliable)
That suggests that the BULK_QUEUE semantics could
be bugfixed to mean that error behavior. Alternatively,
another flag could be defined (ugh) for those semantics.
- Dave
----- Original Message -----
From: "Matthew Dharm" <[EMAIL PROTECTED]>
To: "David Brownell" <[EMAIL PROTECTED]>
Cc: "USB Developers" <[EMAIL PROTECTED]>
Sent: Sunday, November 25, 2001 1:29 AM
Subject: Re: [linux-usb-devel] URB with scatter-gather?
The problem is the short transfer.
Consider queuing 4 1K URBs. The device decides to only send us 2.5K of
data, which will complete the first 2 URBs and then terminate the 3rd on a
short packet.
But that's not an error. So the 4th URB will still run. And, since these
are all queued up, the code doesn't have a chance to cancel the 4th URB
fast enough.
And that can cause problems, including strange delays and transferring the
status data into a userspace buffer.
For what usb-storage needs, the scatter-gather segments really need to be a
single URB, with all the semantics therein.
Matt
On Sat, Nov 24, 2001 at 03:35:15PM -0800, David Brownell wrote:
> How about something simpler ... a convenience function
> that knows how to use the existing bulk queuing. It'd
> be a simple layer, no changes needed to the fragile host
> controller driver code. Something maybe like:
>
> int usb_submit_bulk_sg (
> // what device and endpoint
> struct usb_device *dev,
> int pipe,
> // mem alloc flags (used internally)
> int mem_flags,
> ...
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
