On Wed, 25 Feb 2009 23:18:27 -0500, "Paul O'Keefe" <paul@xxxxxxxxxxxxx> wrote:
> > I'm wondering why Chris needs to use REAPURBNDELAY for
> > a non-interactive tool, especially by one which also uses futex!
>
> I don't believe he does. It's libusb. The code calls through a small
> object called USBWRAP which just wraps the exposed interfaces to libusb.
> The call goes to the libusb "usb_bulk_write" function which then calls
> usb_urb_transfer. That function is the owner of the calls to
> REAPURBNDELAY.
Interesting. Did you verify that the timeouts are set in correct
units there, seconds versus milliseconds? Remember, Alan Stern
suggested it.
> Because I feel this is a timing issue, I regret to inform you that the
> attached traces exhibit correct behavior when both usbmon and strace are
> run together. Thus so, however the file may yield some clues.
> Immediately running the command "btool -t" in the same window where I
> previously ran "strace -tt -o <file> btool -t" concurrently with the
> usbmon exhibits the same failure.
Well, here's what's going on. Even in the "ok" trace, not everything
is ok. Sometimes, this happens:
23:09:34.650645 open("/dev/bus/usb/007/008", O_RDWR) = 3
23:09:34.650725 ioctl(3, USBDEVFS_CONTROL, 0xbfae59dc) = 1
23:09:34.651019 ioctl(3, USBDEVFS_CLAIMINTERFACE, 0xbfae59f4) = 0
23:09:34.651091 ioctl(3, USBDEVFS_CLEAR_HALT, 0xbfae5934) = 0
23:09:34.651376 ioctl(3, USBDEVFS_CLEAR_HALT, 0xbfae5934) = 0
23:09:34.651656 gettimeofday({1235621374, 651686}, NULL) = 0
23:09:34.651717 ioctl(3, USBDEVFS_SUBMITURB, 0xbfae5884) = 0
23:09:34.651842 ioctl(3, USBDEVFS_REAPURBNDELAY, 0xbfae58c8) = -1 EAGAIN (Resource temporarily unavailable)
23:09:34.651899 select(4, NULL, [3], NULL, {0, 1000}) = 0 (Timeout)
23:09:34.653046 gettimeofday({1235621374, 653067}, NULL) = 0
23:09:34.653098 ioctl(3, USBDEVFS_REAPURBNDELAY, 0xbfae58c8) = -1 EAGAIN (Resource temporarily unavailable)
..... then we flop around for a while (see the timeouts above),
..... and then we unlink:
23:09:34.751511 select(4, NULL, [3], NULL, {0, 1000}) = 0 (Timeout)
23:09:34.752716 gettimeofday({1235621374, 752755}, NULL) = 0
23:09:34.752813 ioctl(3, USBDEVFS_REAPURBNDELAY, 0xbfae58c8) = -1 EAGAIN
(Resource temporarily unavailable)
23:09:34.752900 ioctl(3, USBDEVFS_DISCARDURB, 0xbfae5884) = 0
23:09:34.753183 ioctl(3, USBDEVFS_REAPURB, 0xbfae58c8) = 0
Boom, done. Next URB transfers normally:
23:09:34.753788 gettimeofday({1235621374, 753830}, NULL) = 0
23:09:34.753894 ioctl(3, USBDEVFS_SUBMITURB, 0xbfae5784) = 0
23:09:34.754138 ioctl(3, USBDEVFS_REAPURBNDELAY, 0xbfae57c8) = 0
I was unable to make sure what piece of the usbmon trace corresponds
to what request by libusb exactly, but we see approximately this:
-- First, the control (status of some kind) and the halt clears:
f1f75c00 1.650754 S Ci:7:008:0 s 80 08 0000 0000 0001 1 <
f1f75c00 1.650944 C Ci:7:008:0 0 1 = 01
f1f75c00 1.651115 S Co:7:008:0 s 02 01 0000 0087 0000 0
f1f75c00 1.651315 C Co:7:008:0 0 0
f1f75c00 1.651403 S Co:7:008:0 s 02 01 0000 0009 0000 0
f1f75c00 1.651540 C Co:7:008:0 0 0
-- Submit an input:
f1f75c00 1.651759 S Bi:7:008:7 - 16384 <
-- Unlink:
f1f75c00 1.753052 C Bi:7:008:7 -2 0
<------ notice the timeout of 100ms
-- Next, a normal transfer, although it's an out:
f1f75c00 1.753941 S Bo:7:008:9 - 16 = 00001000 01ff0000 a818da8d 6c020000
f1f75c00 1.754045 C Bo:7:008:9 0 16 >
-- But wait, input works too:
f1f75c00 1.754373 S Bi:7:008:7 - 16384 <
f1f75c00 1.755179 C Bi:7:008:7 0 16 = 00001000 02ff0000 a818da8d 6c020000
So, I suspect that for some reason the device needs a few milliseconds
to settle after the halt clear. If next transfer hits right, it stops
responding completely (like in your busted trace), or eventually recovers
(like in the trace above). The issue is confused by libusb being retarded.
Such is the theory for now anyway.
Please try to add a delay after halts into the btool and see it that helps.
-- Pete
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
