I see the same behavior with my Thinkpad T61.
This is slightly different than the [also flawed] behavior I saw with Fedora 11 on the same hardware.  That behavior was consistent with Bug 493018, which intermittently cut out but would eventually restore.  

In Fedora 12 the iwlagn 0000:03:00.0: ERROR: No TX rate available errors are continuous and essentially immediate, rendering the interface useless. 
One thing to note is that this seems to affect the handling of networking beyond just the chosen interface.  If I shut down wireless in NetworkManager and plug in a cable that also fails to work.  I have to first rmmod the iwlagn module and then plug in a cable before I can do any sort of networking again.

Also it should be worth noting that this not seem to be a problem of 5ghz per se, just 802.11n running 5ghz.  I use an [Intel] 802.11a AP at work with no problems all day.  It is only when I come home and associate with my Linksys 610n in 5ghz mode that I run into trouble.

btw, I did not see this at all until I upgraded from the 2.6.31.6-162.fc12.x86_64 kernel to the 2.6.31.6-166.fc12.x86_64 kernel.  If I try to go back to 162 now it fails as well though (perhaps because I have the newer kernel-firmware pkg?).

Same problem. I tried it at home and at work at 5ghz and just constant ERROR: No TX rate available. I can confirm that when F12 was initially released, it did not work. Then some upgrades later it did work. Then it stopped working again after another upgrade. Looking at the 2.6.32 changelog, there were a couple of commits which pointed to this problem... I tried to install the 2.6.32 kernel, but it didn't play nice with my graphics.

commit b58ef214b7db57cfcbca0e1edae08566cdfd56b7
Author: Daniel C Halperin <daniel.c.halperin>
Date:   Fri Aug 28 09:44:46 2009 -0700

    iwlwifi: remove incorrect uses of ieee80211_get_tx_rate to prevent TX stall
    
    Refactor and correct rate selection for outgoing transmitted
    packets.
    
    First, note that HT rates in the mac80211 rate table do not provide valid
    indices when ieee80211_get_tx_rate is called; the check to see if we could to
    abort a transmission early in iwl_tx_skb() would thus occasionally read invalid
    memory and occasionally stall transmission (if the erroneous byte was 0xff).
    We remove that code; the check wasn't valid anyway.
    
    Second, iwl_tx_cmd_build_rate() also called ieee80211_get_tx_rate to be used
    for sending management packets, which do not use the uCode station table.  This
    patch refactors that function and adds comments to enhance legibility, replaces
    the call to ieee80211_get_tx_rate() with a direct lookup, and adds error
    handling in case the table entry is invalid.
    
    Signed-off-by: Daniel C Halperin <daniel.c.halperin>
    Signed-off-by: Reinette Chatre <reinette.chatre>
    Signed-off-by: John W. Linville <linville>

I can confirm this using a iwl5300 card; the drivers from 2.6.32 do indeed fix it (http://www.orbit-lab.org/kernel/compat-wireless-2.6-stable/v2.6.32/compat-wireless-2.6.32.2.tar.bz2 for people who want to test without rebuild/installing a different kernel).

(Problem only happens with 80211n + 5GHZ band)

(In reply to comment #3)
> I can confirm this using a iwl5300 card; the drivers from 2.6.32 do indeed fix
> it
> (http://www.orbit-lab.org/kernel/compat-wireless-2.6-stable/v2.6.32/compat-wireless-2.6.32.2.tar.bz2
> for people who want to test without rebuild/installing a different kernel).
> 
> (Problem only happens with 80211n + 5GHZ band)  

Have to correct myself; the error message is not displayed but the symptoms are the same (connection stalls).

(In reply to comment #4)
> (In reply to comment #3)
> > I can confirm this using a iwl5300 card; the drivers from 2.6.32 do indeed fix
> > it
> > (http://www.orbit-lab.org/kernel/compat-wireless-2.6-stable/v2.6.32/compat-wireless-2.6.32.2.tar.bz2
> > for people who want to test without rebuild/installing a different kernel).
> > 
> > (Problem only happens with 80211n + 5GHZ band)  
> 
> Have to correct myself; the error message is not displayed but the symptoms are
> the same (connection stalls).  

OK; rebooting after installing the new driver fixed everything (just reloading the module did not seem to be enough).

Just downloaded a big file while surfing the net an everything seems fine (stable connection + good performance)

(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > I can confirm this using a iwl5300 card; the drivers from 2.6.32 do indeed fix
> > > it
> > > (http://www.orbit-lab.org/kernel/compat-wireless-2.6-stable/v2.6.32/compat-wireless-2.6.32.2.tar.bz2
> > > for people who want to test without rebuild/installing a different kernel).
> > > 
> > > (Problem only happens with 80211n + 5GHZ band)  
> > 
> > Have to correct myself; the error message is not displayed but the symptoms are
> > the same (connection stalls).  
> 
> OK; rebooting after installing the new driver fixed everything (just reloading
> the module did not seem to be enough).
> 
> Just downloaded a big file while surfing the net an everything seems fine
> (stable connection + good performance)  

This seems to depend on the phase of the moon or in other words, it is random it might work but the next time the connection drops after some minutes.

Seems like everytime it happens it is "stuck" at 162MB/s iw reports:

iw wlan0 station dump
Station 00:xx:xx:xx:xx (on wlan0)
	inactive time:	957 ms
	rx bytes:	98786
	rx packets:	327
	tx bytes:	18885
	tx packets:	122
	signal:  	-80 dBm
	tx bitrate:	162.0 MBit/s MCS 12 40Mhz

Can someone confirm this?

Yep, I can confirm, I'm seeing the same thing.

I see this too.  I rarely get a functional 5GHz connection for more than a few seconds.  If it survives past that, it seems pretty solid.

Just a note, this seems to be fixed in the 2.6.32 builds (i.e current kernels from koji).

Andy, all


Do You confirm issue is fixed on 2.6.32 based kernel? You can update kernel using:

yum --enablerepo="updates-testing" update kernel

I can confirm that it works.

It seems to have solved the problem for me as well.

This specific problem seems to be resolved by the new kernel, but wifi is very flaky after resuming (and I'm seeing bluetooth regressions).

(In reply to comment #14)
> This specific problem seems to be resolved by the new kernel, but wifi is very
> flaky after resuming 

Please open bugzilla for that and assign it to me.

> (and I'm seeing bluetooth regressions).

We can have opened bz for that, if not open new one and cc me.

I'm not having any wifi flakiness problems and my laptop doesn't have bluetooth.

Otherwise, everything seems to be working great with the new kernel.  haven't had any connect issues since upgrading earlier today.  nice that it gives the connection speed now.

(In reply to comment #15)
> > This specific problem seems to be resolved by the new kernel, but wifi is very
> > flaky after resuming 
> 
> Please open bugzilla for that and assign it to me.

I haven't managed to reproduce it enough to be able to clearly report anything.

> > (and I'm seeing bluetooth regressions).
> 
> We can have opened bz for that, if not open new one and cc me.    

I filed it as bug 570291.

Since F12 update kernel to 2.6.32 I'm closing this bug.

FYI, after updating to the 2.6.32 kernel on F12 this problem does go away HOWEVER I still lose connections to my 5GHz a/n network.  Instead of seeing tons of:

Mar 18 12:52:12 pgpdev kernel: iwlagn 0000:03:00.0: ERROR: No TX rate available.

I now see:

Mar 18 13:50:58 pgpdev kernel: iwlagn 0000:03:00.0: iwl_tx_agg_start on ra = 00:25:9c:ce:f5:71 tid = 0

And then the network is unusable.

Switching from my 5GHz a/n network to my 2.4GHz g network and I'm fine.  So this only happens on 5GHz a/n.

AP is a WTN610N running DD-WRT configured with WPA2/PSK/AES(CCMP)

I've submitted Bug #574885 on that issue...