Re: [linuxwifi] [RFC] iwlwifi: enable TX AMPDU for some iwldvm

["Grumbach, Emmanuel" <emmanuel.grumbach@intel.com>]

On Tue, 2019-03-12 at 15:44 -0600, Kevin Locke wrote:
> On Tue, 2019-03-12 at 20:48 +0000, Grumbach, Emmanuel wrote:
> > On Tue, 2019-03-12 at 14:31 -0600, Kevin Locke wrote:
> > > On Tue, 2019-03-12 at 19:47 +0000, Grumbach, Emmanuel wrote:
> > > > We had issues with reclaim path upon BACK. This is of course a
> > > > firmware problem...
> > > 
> > > Does that suggest the issue may have been fixed by a firmware
> > > update?
> > > For reference, I'm currently using "firmware version 9.221.4.1
> > > build
> > > 25532" from the firmware-iwlwifi Debian package (version
> > > 20190114-1).
> > > 
> > > If it would be helpful, I could attempt to bisect the firmware
> > > revisions to find the one that fixed it (assuming I can reproduce
> > > the
> > > issue with a previous firmware version).
> > 
> > Well.. Sorry, I wasn't very "technical".
> > So the problem was really that we stopped getting BACK
> > notifications
> > from the firmware and that caused a reclaim stall which in turn was
> > caught by a Tx queue stuck timer firing in the driver.
> > I was never able to reproduce this. What I can do is to enable A-
> > MPDU
> > on my old system that has this same device, just to see what
> > happens.
> 
> Thanks for the additional details and for offering to try it out,
> that
> would be great!

Just to align on expectations, I don't feel like enable A-MPDU by
default regardless of what will come out of this. People stopped
complaining after we disabled A-MPDU and the very very very few people
that did need more throughput knew how to enable them with the module
parameter. So, I don't plan to re-enable A-MPDU by default.

> 
> > While chasing this bug, I even found another one which bought me a
> > few
> > moments of fame:
> > 
> > commit d6ee27eb13beab94056e0de52d81220058ca2297
> > Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
> > Date:   Wed Jun 6 09:13:36 2012 +0200
> > 
> >     iwlwifi: don't mess up the SCD when removing a key
> > 
> > and in the commit message of that very commit:
> > 
> >     This doesn't seem to fix the higher queues that get stuck
> >     from time to time.
> > 
> > There were no new versions of the firmware released since then.
> > I tried to skim through bugzilla, but couldn't find the bugs I was
> > handling then.
> 
> Ah.  You are right about the firmware version.  I should have
> checked.
> 
> I see what you mean.  I found several reports for TX queue stuck
> issues in Bugzilla.  Perhaps this is one (or one of its many dups):
> https://bugzilla.kernel.org/show_bug.cgi?id=56581
> 

And those were very very time consuming. I don't want to go there
again. These are very old devices (they were described as old in 2014
already...).

> Let me know if there is anything I can do to help search or test.
> 
> Thanks again,
> Kevin