Oliver Neukum wrote:
Am Freitag, 10. Januar 2003 22:16 schrieb Duncan Sands:
Hi Oliver, I decided to see how other drivers deal with this usb_unlink_urb
issue. The first thing I looked was devio.c. And guess what, it looks
like it assumes that the completion handler has completed by the time
usb_unlink_urb finishes:
...
Unlinking is tricky, and my understanding of the current rules are:
- For a successful synchronous unlink, the completion handler did fire
before the unlink call returned. Easily proven for HCDs that go through
the "hcd.c" logic (*), otherwise you have to take it on faith. (And
some older HCD code might bugs here, like not reporting completions.)
- For a successful asynchronous unlink, the only rule is that the
completion handler _will_ be called with urb->status == -ECONNRESET.
Maybe before usb_unlink_urb() returns, maybe after. (I've certainly
seen "before" in certain fault recovery scenarios, and SMP ought to
allow it too, although "after" is more usual.)
- For _un_successful unlinks of either type, look at the returned status
to figure out what's up. For example, "-EBUSY" (now) says that the
urb was going through a normal (including non-cancellation fault)
return process, -EINVAL and -ENODEV also give useful status.
The "devio.c" code quoted didn't handle the unsuccessful unlink case,
which I suspect is pretty typical.
That are good, or bad depending on viewpoint.
IIRC we had this discussion already, possibly several times. Has the general
consensus changed ? It seems that the old objections about freeing the
URB from the completion handler are no longer valid, due to reference
counting. IMO the completion handler should be waited for.
I've not been following this in detail. My own recollection of the
main reason not to free urbs in completion handlers -- in drivers that
know the urb isn't otherwise used in that driver -- is that it would
sometimes oops "usb-uhci". (Secondarily, "automagic resubmit" made
some completions not be real handoffs: the urb was still half-owned
by the HCD ... no longer an issue in 2.5!)
- Dave
(*) However, there seems to be a bug in current "uhci-hcd" code here.
It reproduced very easily for me using "testusb -t10", which now
works using the "usbtest" driver on 2.5.56 ... "test 10" covers the
control queueing code paths, and can be used with any device, so
anyone who wants should be able to try reproducing this.
Getting protocol stalls (routine!) seemed to confuse its fault recovery
logic. I didn't have time to look at it much, Johannes and Dan have
some more details, but the last straw (unrecoverable test hang)
was several urbs that never completed; but their unlinks succeeded.
Perhaps related, there were strong hints that the completions were
reported out of order ... likely a later update to that particular
test will notice that issue too.
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
