Re: iwlagn aggregation problem when stations are removed/re-added quickly

[wwguy <wey-yi.w.guy@intel.com>]

On Wed, 2011-06-08 at 04:07 -0700, Johannes Berg wrote:
> On Fri, 2011-05-13 at 15:56 -0700, Daniel Halperin wrote:
> 
> > I'm running an experiment where a client connects to the AP (both HT
> > iwlagn devices), starts a large transfer that gets aggregation going,
> > disassociates, and then reassociates and restarts the transfer.
> > 
> > When mac80211 stops the queue (as part of the client's disassocation
> > process), it goes into the following code:
> > 
> >                IWL_DEBUG_HT(priv, "Stopping a non empty AGG HW QUEUE\n");
> >                 priv->stations[sta_id].tid[tid].agg.state =
> >                                 IWL_EMPTYING_HW_QUEUE_DELBA;
> >                 spin_unlock_irqrestore(&priv->sta_lock, flags);
> > 
> > but if the station is removed right away the packets stay in the
> > queue. Indeed, when the client reconnects, the packets are then
> > delivered! But then the queue gets stuck and the AP issues a firmware
> > reset, which doesn't actually get traffic flowing again. Below,
> > there's a log with IWL_DL_HT set. It may be something racy; adding
> > DL_INFO and DL_MAC80211 I haven't been able to reproduce the bug yet
> > in a few tries.
> > 
> > I suspect this will also be a problem with P2P, and not just my klugey
> > use of AP mode. Any suggestions as to how to fix?
> 
> Sorry I'm replying this late. I'm not sure what the best way to fix it
> would be, but it makes sense that this would happen. Maybe we can flush
> the aggregation queue (asking the ucode to drop all frames) when the
> station is removed, but I'm not sure how we'd do that -- Wey-Yi do you
> know if that's possible?
> 
flush the queue might be a good solution, I was being told (I don't
remember who and when which is bad), the "tx flush" command is needed
especially for P2P

btw, there are 2 type of "tx flush", flush all the frames in uCode, or
just flush the frames in specified queue.

Thanks
Wey