On Wed, 2009-02-25 at 12:18 -0700, Pete Zaitcev wrote:
> You need to interrupt it to get strace to write out the output.
> The attachment was truncated:
>
> gettimeofday({1235547424, 341658}, NULL) = 0
> ioctl(3, USBDEVFS_REAPURBNDELAY, 0xbfd69bf8) = 0
> futex(0x8106964, FUTEX_WAIT_PRIVATE, 5, NULL) = 0
> futex(0x8106948, FUTEX_WAIT_PRIVATE, 2, NULL) = 0
> futex(0x8106948, FUTEX_WAKE_PRIVATE, 1) = 0
> gettimeofday({1235547424, 342853}, NULL) = 0
> ioctl(3, USBDEVFS_SUBMITURB, 0xbfd699a4) = 0
> ioctl(3, USBDEVFS_REAPURBNDELAY, 0xbfd699e8) = 0
> futex(0x8106964, FUTEX_WAIT_PRIVATE, 7, NULL <------------ here
>
> What survived was not consistent with the previously posted usbmon
> log in any way. It would be best to get both from the same run.
> Also, strace -tt should help to corellate the events (usbmon does
> not print the absolute time as strace, but we can subtract stamps
> and see which event is which).
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.
>
> 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.
--
Paul
Attachment:
traces.tar.bz2
Description: application/bzip-compressed-tar
