Re: carl9170 A-MPDU transmit problem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux