On Fri, Feb 22, 2013 at 11:07:37PM +0100, Christian Lamparter wrote: > Hello Seth, > > On Friday 22 February 2013 21:50:44 Seth Forshee wrote: > > I was given a D-Link wireless dongle by a colleague who said he was > > having trouble with the connection stalling. One thing I noticed right > > away when running iperf is that the tx BA sessions seem to be getting > > stopped and restarted pretty frequently. I've been doing some debugging, > > and here's what I'm seeing. > > > > On the air everything seems to go smoothly for a while, but then the > > D-Link adapter stops transmitting data frames for a while. It still > > sends CTS and BA frames in response to the AP, just no data frames. > > Eventually it sends the action frame with the DELBA request, but > > immediately before sending the action frame it sends a single data > > frame. This pattern repeats each time this happens. > > > > That final data frame is a bit curious, so I added some tracing to > > carl9170. It looks like this frame gets passed down to the hardware as > > the last in a batch of A-MPDU frames, but for some reason the hardware > > stops transmitting without sending this frame. carl9170 doesn't pass any > > more A-MPDU frames to the hardware while tx for that frame is pending, > > and when the action frame for the DELBA request finally comes along it > > seems to get things moving again. > > > > Do you have any idea what might be causing the hardware to stop > > transmitting with one frame left? Any suggestions on how to fix it? > Do you also see messages like "invalid plcp cck rate.", > "rx stream does not start with a first_mpdu frame tag." and/or > "plcp info/frame tail is clipped" or messages about "driver > reset"? No, none of these messages. > Can you tell me what version firmware are you using? usb 3-3: firmware API: 1.9.6 2012-07-07 > If your driver is up to date, you could try the > firmware attached to: > <https://bugzilla.redhat.com/show_bug.cgi?id=831953> This firmware exhibits the same behavior. > About the "frame gets passed down..." thing. Do you know > if this frame is received by the firmware or if it is > stuck in the usb-pipe? (if you have DEBUGFS support, you > can look at tx_ampdu_upload. If it's value stays the same > (that is >= 1. If it drops to 0, then it should be fine) > until the DELBA rolls around, then something is wrong with > the USB BUS). tx_ampdu_upload is one of the things I was monitoring. In one example, frames with sequence numbers 1282 - 1286 are put in the tx_pending queue, increasing tx_ampdu_upload to 5. All 5 frames are passed to carl9170_usb_tx() (this is what I mean when I say the frame gets passed down), but only the first 4 are transmitted, and tx_ampdu_upload decrements down to 1. It stays at 1 until the DELBA comes, at which point it finally gets transmitted and tx_ampdu_upload decrements to 0. So it sounds like there's a USB bus problem. I've verified that this problem shows up on multiple machines. > Note: Unfortunately, Control frames (BA + CTS + ACK) > don't share the tx queues with DATA or MGMT frames. > These frames are generated within the bowls of the > hardware MAC and they take "short paths" through > the tx arbiter (this is all done in the silicon). > [However, if you filter the monitor dumps again, you > could look for nullfuncs or Probe Requests originating > from the device. These should be a good indication > whenever the hardware or the driver is on the fritz.] > > Note2: It's too early to tell anything yet ;-) > But just in case you are planning to test the latest > wireless-testing.git or compat-driver: Here's a patch > which was just posted: > <http://www.spinics.net/lists/linux-wireless/msg103866.html> > It sorts out a disagreement between carl9170 and the > latest minstrel_ht changes. Without it, you'll definitely > get a very choppy connection (lots of WARNings and frame > drop). I'm currently testing with 3.8, so the minstrel_ht changes aren't an issue. Thanks, Seth -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
