[Bug 231782] a USB frame from an interrupt endpoint may be missed

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231782

--- Comment #2 from Ludovic Rousseau <ludovic.rousseau+freebsd at gmail.com> ---
I do not always reproduce the problem. I do not yet know what is needed to make
the problem to happen. After that it is easy to reproduce but sometimes I get a
normal execution again with no problem. Strange.

For this issue I do not use libusb_cancel_transfer(). No transfer is cancelled
here.

I used usbdump to dump the USB traffic.
I can reproduce the problem even when usbdump is running. Good.

When I have the issue *nothing* is logged by usbdump. The USB frame that should
be received is not dumped. And then libUSB does not see it either.

I do not have a USB hardware analyser to confirm the USB frame is really
travelling on the USB bus. Since I do not have the issue on GNU/Linux and I
have the problem on FreeBSD 10.4 with, at least, 3 different models of USB
smart card reader I guess the problem is not in the USB devices.

The missing frame is something like:
15:01:49.961874 usbus0.2
DONE-INTR-EP=00000083,SPD=FULL,NFR=1,SLEN=4,IVAL=16,ERR=0
 frame[0] READ 2 bytes
 0000  50 02 -- -- -- -- -- --  -- -- -- -- -- -- -- --  |P.              |
 flags 0x16 <SHORT_XFER_OK|SHORT_FRAMES_OK|PROXY_BUFFER|0>
 status 0xcb821
<OPEN|STARTED|SHORT_FRAMES_OK|SHORT_XFER_OK|BDMA_ENABLE|BDMA_SETUP|CAN_CANCEL_IMMED|DOING_CALLBACK|0>

It looks like the problem is not in libUSB but in a lower layer.

It looks like the problem happens more often when using a USB3 port (blue
connector) than a USB2 port.
I will join the results of lshal for USB related parts.

How can I help debug this issue?

-- 
You are receiving this mail because:
You are the assignee for the bug.