Re: [libusb] Ideas on Intermittent Pipe error [Errno 32]

[Alan S. <st...@ro...>]

On Sat, 4 Feb 2017, Russ Butler wrote:

> Hi Alan,
> 
> Thanks for the info on usbmon. I was able to capture this occurring with it. The log is attached. It ran for ~3 hours before this failure occurred. Let me know if you have any ideas on the cause.

I assume you're referring to line 986 of the log:

ffff8802b1112c00 833994475 C Ii:1:055:1 -32:1 0

One possibility is bad hardware -- an intermittent problem either in 
the hub or in the cable connection.  You said you used a USB analyzer 
on the upstream side of the hub (because you monitored SSPLIT and 
CSPLIT transactions).  Have you tried the downstream side?

More information is needed before it can be fully diagnosed.  What does
/sys/kernel/debug/usb/devices contain?  (You may need to mount a
debugfs filesystem on /sys/kernel/debug first.)

Judging by the log, your test program sends out messages to a bunch of
endpoints and waits for all of them to complete, then sends out a bunch
more, and so on.  You may get better results if you send the next
message for each endpoint as soon as the previous one completes,
instead of waiting for all the outstanding messages to complete.  That
would be more typical of the way interrupt endpoints are used in
practice.

Alan Stern

PS: You may want to move this conversation off the libusb-devel mailing
list, since it clearly has nothing to do with libusb.  A more
appropriate forum would be lin...@vg....

> 
> Thanks,
> Russ
> 
> -----Original Message-----
> From: Alan Stern [mailto:st...@ro...]
> Sent: Friday, December 16, 2016 10:55 AM
> To: Russ Butler
> Cc: lib...@li...
> Subject: Re: [libusb] Ideas on Intermittent Pipe error [Errno 32]
> 
> On Fri, 16 Dec 2016, Russ Butler wrote:
> 
> > Hello,
> >
> > I'm getting an intermittent pipe error when using libusb 1.0.20 on
> > Ubuntu 16.04. I also tried the latest code from master - b14d0a4 and
> > had this same problem. The code I'm using communicates over interrupt
> > endpoints and as a stress test does this repeatedly to multiple
> > devices. I initially came across this problem when using pyusb, but
> > since then I have been able to reproduce this with a C program using
> > libusb directly.
> >
> > I also captured this event on a USB analyzer and the interrupt
> > endpoints in use are not stalled (the API indicates that
> > libusb_interrupt_transfer returns LIBUSB_ERROR_PIPE if the endpoint is
> > halted). It appears that the transaction is getting canceled, since in
> > the USB logs show an IN transaction is started (log has SSPLIT IN) but
> > is never finished (no CSPLIT OUT).
> >
> > In the issue below is the debug output from when this problem occurs.
> > Any ideas on how I could narrow this problem down?
> 
> It wouldn't hurt to capture a usbmon trace.  (See the instructions in the kernel source file Documentation/usb/usbmon.txt.)  usbmon is different from an analyzer trace because it gives you the kernel's perspective on what is happening.
> 
> Another thing you can do is turn on usbfs snooping:
> 
> echo true >/sys/module/usbcore/parameters/usbfs_snoop
> 
> The output will appear in the kernel log (use dmesg).  This will give the details of interactions between libusb and the kernel.
> 
> Alan Stern
> 
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
>