Bug 566696

Hmmm...well apparently I have a knack for only buying equpment that works.  FWIW I have not seen this on my TEW-652BRP AP (or the WNR854T) in 802.11n-only mode when used with the iwlagn driver (on various hardware).  FWIW my APs are using channels in the 2GHz range.

How much testing have you done with the patch from below?

http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2160#c4

I take it back -- I do get the "iwlagn 0000:a0:00.0: iwl_tx_agg_start on ra = 00:23:69:35:d1:3f tid = 0" error (different MAC in my case), but my connections seems to be fine.

FWIW, I'm not sure that iwl_tx_agg_start message is actually an error.  The code uses IWL_WARN, but it seems more informational than anything.

OK, sorry -- you are saying this is specific to iwl5x00 -- I'll try to reproduce there.

iwlagn 0000:a0:00.0: iwl_tx_agg_start on ra = 00:23:69:35:d1:3f tid = 0
is not an error, I have it also on 2.6.31 where everything was just fine.

I run patch on 2.6.33-rc7, but I only checked if it fix the issue, not really test. I would like to put it or some better version into 2.6.32 stable tree, if Reinette agree. Intel and upstream users should give it enough testing.

Parameters:2.4GHz, Channel width: 20MHz only, Standard channel: auto, Security mode: WPA2-Personal, Encryption: AES.

This bug happens when both 2.4GHz and 5GHz wireless networks are enabled on my AP (it is dual band). After disabling 5GHz bandwidth, bug disappears.

That is an interesting observation.  What if you select a specific 5GHz channel (rather than auto)?  I presume that selecting a specific 2GHz channel would be equivalent to disable 5GHz...

Reinette posted "iwlwifi: sanity check before counting number of tfds can be free" patch which most likely fix that bug. I'm going to test.

Nope. Applying both:
[PATCH 2/3] iwlwifi: sanity check before counting number of tfds can be free
[PATCH 3/3] iwlwifi: error checking for number of tfds in queue
They do not fix.

Alright, (as expected) I can't recreate this on my (2GHz-only) AP in 802.11n-only mode w/ iwl5100 device running a -189.el5-based kernel.  I will rely on Stansilaw to continue pursuing this upstream and hope/anticipate that RHEL5's current closeness to the upstream codebase will yield a patch that fixes (or at least helps) both RHEL5 and upstream.

Created attachment 395506 [details]
Upstream fixes backported to RHEL5

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

I can't reproduce this either.  I tested on snap2 client x86_64 on iwl5000
against an 802.11n only open access point.  I was able to open a browser and
connect to a web server over wireless.

To reproduce is you need to have dual band AP. Maybe even my particular AP model, (WRT610N V1). I think you can believe me, that patch fix the issue :) If QE want to do something regard this bug, may just test if it not cause any regression.

in kernel-2.6.18-191.el5
You can download this test kernel from http://people.redhat.com/jwilson/el5

Please update the appropriate value in the Verified field
(cf_verified) to indicate this fix has been successfully
verified. Include a comment with verification details.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2010-0178.html