On Mon, Feb 25, 2013 at 11:13:57AM -0800, Sarah Sharp wrote: > On Mon, Feb 25, 2013 at 05:03:40PM +0100, Christian Lamparter wrote: > > On Monday, February 25, 2013 04:29:55 PM Alan Stern wrote: > > > On Mon, 25 Feb 2013, Christian Lamparter wrote: > > One detail that might be important (to keep in mind): > > > > Original report <http://www.spinics.net/lists/linux-wireless/msg103880.html>: > > > On the air everything seems to go smoothly for a while, but > > > then the D-Link adapter stops transmitting *DATA* frames for a while. [...] > > > Eventually it sends the action frame with the *DELBA* request, but > > > immediately before sending the action frame it sends a single *DATA* > > > frame (1). This pattern repeats each time this happens. > > > > Now if we take this and apply it to the usbmon recording in: > > <http://www.spinics.net/lists/linux-wireless/msg103915.html> > > > > > Normally the time between submission and callback for a given urb > > > is short. However, some are much longer, e.g.: > > > > > >ffff88012fe19500 1519981417 S Bo:3:003:1 -115 126 = 7e000000 ... <-- DATA > > > > > > [... long period where the device receives commands on EP4 and sends > > > wifi data to the host via EP2 - so it is working!] > > > > > >ffff880146c8af00 1522200650 S Bo:3:003:1 -115 62 = 3e000000 ... <-- DELBA > > >ffff88012fe19500 1522200720 C Bo:3:003:1 0 126 > <-- DATA urb completion > > >ffff880146c8af00 1522200756 C Bo:3:003:1 0 62 > <-- DELBA urb completion > > > > It would mean that the (delayed) urb with the *DATA* frame urb was not > > sent (?or received?) by the usb dongle until the *DELBA* came along (1) > > and triggered the TX for both (in quick succession). So, I think we > > should be looking for lost/unhandled interrupts/events. > > > > One more thing: So far this issue only occurs with: > > 00:14.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller [8086:1e31] (rev 04) (prog-if 30 [XHCI]) > > Which kernel version are you testing under? Can you please recompile > with CONFIG_USB_DEBUG and CONFIG_USB_XHCI_HCD_DEBUGGING turned on, and > send me dmesg? I should be able to see if there's an unhandled pending > event on the xHCI rings if the data URB stalls for longer than say, a > minute. I'll do this. > As for lost interrupts, the only issue we had with that particular xHCI > host had to do with lost isochronous transfers. We fixed that with a > quirk to avoid the BEI flag on that platform. But your data is being > sent via a bulk endpoint, so we shouldn't have any issues there. > > > However, it not all xhci-hcd are affected. I have not seen this with > > the NEC Corporation uPD720200 I have in my sandy bridge laptop: > > 19:00.0 USB controller [0c03]: NEC Corporation uPD720200 USB 3.0 Host Controller [1033:0194] (rev 04) > > Hmm, yeah, that kind of points to an Intel xHCI hardware issue. It's > too bad you don't have a USB analyzer (the high speed ones are about > $480). Can you send me a link so I can purchase the device and test it > with my analyzer? Hmm. This looks the same, but it sounds like there are multiple hardware versions sold under the same name so I'm not sure. The one I have is hardware version A2. http://www.amazon.com/D-Link-DWA-160-Extreme-N-Dual-Band-802-11n/dp/B00127OVHI Seth -- 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
