On Monday, February 25, 2013 04:29:55 PM Alan Stern wrote: > On Mon, 25 Feb 2013, Christian Lamparter wrote: > > > In fact this is both normal and required. Packets to any particular > > > endpoint must always be delivered in order. Therefore the URBs have > > > to complete in the same order as they were submitted. > > Yes, I know that ;). I guess I should have said: "It's strange that > > after such a long silence the urb tx trigger at 1519981417 seemd to > > unfreeze the pending urb. It's almost as if a urb completion event > > was lost and the urb_complete just had to wait until another tx urb > > on the same ep went by to free it. > > That's quite possible. The new URB may trigger something in the > xhci-hcd driver or in the xHCI hardware. Sarah (CC'ed), the maintainer > for xhci-hcd, is the person who would know best. Thanks (Hello Sarah). 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]) 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) Regards, Chr -- 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
