Bug 833117

Summary: kernel 3.4.0 iwlwifi flaky
Product: [Fedora] Fedora Reporter: Andy Wang <dopey>
Component: kernelAssignee: Stanislaw Gruszka <sgruszka>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 17CC: aronparsons, brom, bugtracker, c.david86, dopey, gansalmon, inkybutton, irosenhagen, itamar, jforbes, johannes, jonathan, j.romildo, jvpgomes, jwboyer, jwulf, kernel-maint, kevin, lmedinas, madhu.chinakonda, matt, mavit, meijer.o, omaciel, pwouters, redhat, rkennke, sgruszka, sontek, stefan.kirrmann, tjwhaynes, tom.jenkinson, uckelman, wmealing, xkaf
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: first=3.4.0 tested=3.4.2-4 iwlwifi
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 825491 Environment:
Last Closed: 2012-11-16 15:02:43 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
errors I'm getting none

Description Andy Wang 2012-06-18 15:50:38 UTC 
+++ This bug was initially created as a clone of Bug #825491 +++

kernel-3.4.0-1.fc18.x86_64 on a f17 userspace. 

connection comes up fine on boot and works for a while, Then I get in dmesg: 

[ 3696.915129] iwlwifi 0000:03:00.0: Queue 2 stuck for 2000 ms.
[ 3696.915136] iwlwifi 0000:03:00.0: Current SW read_ptr 215 write_ptr 228
[ 3696.915189] iwlwifi 0000:03:00.0: Current HW read_ptr 215 write_ptr 228
[ 3696.915193] iwlwifi 0000:03:00.0: On demand firmware reload
[ 3696.915629] ieee80211 phy0: Hardware restart was requested
[ 3696.915720] iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S
[ 3696.915910] iwlwifi 0000:03:00.0: Radio type=0x0-0x3-0x1

The connection goes dead. However, NetworkManger doesn't see this at all, and happily tells me I am still connected and all is well. 

Then, asking it to reconnect to the same AP it says it's already connected to: 

[ 3870.479980] wlan0: deauthenticating from 20:4e:7f:8b:27:bd by local choice (reason=3)
[ 3870.493387] cfg80211: Calling CRDA to update world regulatory domain
[ 3870.500889] cfg80211: World regulatory domain updated:
[ 3870.500893] cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[ 3870.500896] cfg80211:   (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 3870.500898] cfg80211:   (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[ 3870.500900] cfg80211:   (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[ 3870.500902] cfg80211:   (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 3870.500904] cfg80211:   (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 3870.500925] cfg80211: Calling CRDA for country: US
[ 3870.506099] cfg80211: Regulatory domain changed to country: US
[ 3870.506102] cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[ 3870.506105] cfg80211:   (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm)
[ 3870.506107] cfg80211:   (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm)
[ 3870.506109] cfg80211:   (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 3870.506111] cfg80211:   (5490000 KHz - 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 3870.506114] cfg80211:   (5650000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 3870.506116] cfg80211:   (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm)
[ 3873.329609] wlan0: authenticate with 20:4e:7f:8b:27:bd
[ 3873.334028] wlan0: send auth to 20:4e:7f:8b:27:bd (try 1/3)
[ 3873.336642] wlan0: authenticated
[ 3873.337605] wlan0: associate with 20:4e:7f:8b:27:bd (try 1/3)
[ 3873.341069] wlan0: RX AssocResp from 20:4e:7f:8b:27:bd (capab=0x401 status=0 aid=9)
[ 3873.341075] wlan0: associated
[ 3873.359574] cfg80211: Calling CRDA for country: US
[ 3873.364681] cfg80211: Regulatory domain changed to country: US
[ 3873.364686] cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[ 3873.364691] cfg80211:   (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm)
[ 3873.364695] cfg80211:   (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm)
[ 3873.364699] cfg80211:   (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 3873.364703] cfg80211:   (5490000 KHz - 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 3873.364707] cfg80211:   (5650000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 3873.364711] cfg80211:   (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm)

And then it works again for a while. 

A ping to the access point IP during the failure showed: 


64 bytes from 192.168.21.1: icmp_req=3181 ttl=64 time=48.1 ms (DUP!)
64 bytes from 192.168.21.1: icmp_req=3183 ttl=64 time=3079 ms
64 bytes from 192.168.21.1: icmp_req=3184 ttl=64 time=2200 ms
64 bytes from 192.168.21.1: icmp_req=3185 ttl=64 time=1207 ms
64 bytes from 192.168.21.1: icmp_req=3186 ttl=64 time=207 ms
64 bytes from 192.168.21.1: icmp_req=3187 ttl=64 time=3.02 ms
64 bytes from 192.168.21.1: icmp_req=3188 ttl=64 time=2.63 ms
64 bytes from 192.168.21.1: icmp_req=3189 ttl=64 time=3.21 ms
64 bytes from 192.168.21.1: icmp_req=3190 ttl=64 time=3.30 ms
64 bytes from 192.168.21.1: icmp_req=3190 ttl=64 time=48.9 ms (DUP!)
64 bytes from 192.168.21.1: icmp_req=3191 ttl=64 time=4.39 ms
64 bytes from 192.168.21.1: icmp_req=3191 ttl=64 time=48.0 ms (DUP!)
64 bytes from 192.168.21.1: icmp_req=3192 ttl=64 time=2.65 ms
64 bytes from 192.168.21.1: icmp_req=3193 ttl=64 time=3.46 ms
64 bytes from 192.168.21.1: icmp_req=3193 ttl=64 time=47.7 ms (DUP!)
64 bytes from 192.168.21.1: icmp_req=3194 ttl=64 time=5.09 ms
64 bytes from 192.168.21.1: icmp_req=3194 ttl=64 time=48.4 ms (DUP!)
64 bytes from 192.168.21.1: icmp_req=3197 ttl=64 time=955 ms
64 bytes from 192.168.21.1: icmp_req=3198 ttl=64 time=32.5 ms
64 bytes from 192.168.21.1: icmp_req=3199 ttl=64 time=1740 ms
64 bytes from 192.168.21.1: icmp_req=3200 ttl=64 time=743 ms
64 bytes from 192.168.21.1: icmp_req=3199 ttl=64 time=1833 ms (DUP!)
64 bytes from 192.168.21.1: icmp_req=3200 ttl=64 time=880 ms (DUP!)
From 192.168.21.106 icmp_seq=3249 Destination Host Unreachable
...then all unreachable until the connection was restarted... 

dmesg | grep iwl: 


[   10.220282] iwlwifi 0000:03:00.0: pci_resource_len = 0x00002000
[   10.220284] iwlwifi 0000:03:00.0: pci_resource_base = ffffc900117ec000
[   10.220286] iwlwifi 0000:03:00.0: HW Revision ID = 0x35
[   10.220413] iwlwifi 0000:03:00.0: irq 43 for MSI/MSI-X
[   10.367549] iwlwifi 0000:03:00.0: loaded firmware version 9.221.4.1 build 25532
[   10.367805] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEBUG enabled
[   10.367807] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEBUGFS enabled
[   10.367809] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEVICE_TRACING disabled
[   10.367811] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEVICE_TESTMODE disabled
[   10.367813] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_P2P disabled
[   10.367816] iwlwifi 0000:03:00.0: Detected Intel(R) Centrino(R) Ultimate-N 6300 AGN, REV=0x74
[   10.367926] iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S
[   10.377838] iwlwifi 0000:03:00.0: device EEPROM VER=0x436, CALIB=0x6
[   10.377844] iwlwifi 0000:03:00.0: Device SKU: 0x1F0
[   10.377847] iwlwifi 0000:03:00.0: Valid Tx ant: 0x7, Valid Rx ant: 0x7
[   10.377868] iwlwifi 0000:03:00.0: Tunable channels: 13 802.11bg, 24 802.11a channels
[   10.389566] ieee80211 phy0: Selected rate control algorithm 'iwl-agn-rs'
[   12.411883] iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S
[   12.412267] iwlwifi 0000:03:00.0: Radio type=0x0-0x3-0x1
[   12.659343] iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S
[   12.659531] iwlwifi 0000:03:00.0: Radio type=0x0-0x3-0x1

Happy to gather more info or try things out.

--- Additional comment from kevin on 2012-05-26 19:36:04 EDT ---

possible dupes/similar: 

https://bugzilla.redhat.com/show_bug.cgi?id=767855
https://bugzilla.redhat.com/show_bug.cgi?id=804259
https://bugzilla.redhat.com/show_bug.cgi?id=805285

The last of which points to: 

http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2359

--- Additional comment from sgruszka on 2012-05-30 03:56:36 EDT ---

wd_disable=1 module option should help, another options that worth to check is 11n_disable=1 . 

> 64 bytes from 192.168.21.1: icmp_req=3181 ttl=64 time=48.1 ms (DUP!)
That is a new thing I see with iwlwifi. This ICMP DUP probably mean that we incorrectly increase SEQ number for retransmitted frames, so peer pass two same ICMP payload to upper layer and we get two responses.

--- Additional comment from kevin on 2012-05-31 23:11:04 EDT ---

I'll give wd_disable=1 a go. 

I'd prefer to have N working if possible, since I have this nifty N access point. ;)

--- Additional comment from kevin on 2012-06-08 17:48:41 EDT ---

wd_disable=1 doesn't seem to help any.

--- Additional comment from sontek on 2012-06-08 20:14:17 EDT ---

I can confirm that i'm also having this issue and my access point in not wireless-n

--- Additional comment from sgruszka on 2012-06-09 01:31:34 EDT ---

> [ 3696.915129] iwlwifi 0000:03:00.0: Queue 2 stuck for 2000 ms.
> [ 3696.915136] iwlwifi 0000:03:00.0: Current SW read_ptr 215 write_ptr 228
> [ 3696.915189] iwlwifi 0000:03:00.0: Current HW read_ptr 215 write_ptr 228

Apparently wd_disable=1 should make those messages gone, check if this parameter is enabled correctly by:

cat /sys/module/iwlwifi/parameters/wd_disable

--- Additional comment from johannes on 2012-06-09 03:54:10 EDT ---

These two commits are on their way to fix this (at least so we hope):

http://git.kernel.org/?p=linux/kernel/git/linville/wireless.git;a=commitdiff;h=d012d04e4d6312ea157b6cf19e9689af934f5aa7

http://git.kernel.org/?p=linux/kernel/git/linville/wireless.git;a=commitdiff;h=d6ee27eb13beab94056e0de52d81220058ca2297

--- Additional comment from fedora on 2012-06-09 16:42:56 EDT ---

(In reply to comment #7)
> These two commits are on their way to fix this (at least so we hope):

They are not in 3.4.2 afaics, so it's no real wonder 3.4.2-1.fc17.x86_64 didn't fix the connection problems for me :-/ 

(just posting it here for completeness; 03:00.0 Network controller [0280]: Intel Corporation Centrino Ultimate-N 6300 [8086:4238] (rev 35); Thinkpad T420, Sandy Bridge)

--- Additional comment from sontek on 2012-06-09 17:24:00 EDT ---

03:00.0 Network controller: Intel Corporation Centrino Advanced-N 6205 (rev 34)

--- Additional comment from fedora on 2012-06-10 07:29:16 EDT ---

(In reply to comment #7)
> These two commits are on their way to fix this (at least so we hope):

I built a f17 kernel with those; see
http://koji.fedoraproject.org/koji/taskinfo?taskID=4145432

Haven't tested them myself yet, as I'll for the next few hours won't be close to the machine where I see the problem. Cose to mentioned it here anyway, maybe someone wants to give it a try. Use at your own risk; seems the patches were applied, but I'm not doing this every day, so maybe I did a stupid mistake somewhere and the patches were not applied properly.

--- Additional comment from fedora on 2012-06-10 07:32:04 EDT ---

Created attachment 590731 [details]
patch to add patches mentioned ion comment 7 to the F17 kernel package

Just FYI, in case anybody cares, the patch to the kernel package for F17

--- Additional comment from fedora on 2012-06-10 11:43:56 EDT ---

(In reply to comment #10)
> I built a f17 kernel with those; see
> http://koji.fedoraproject.org/koji/taskinfo?taskID=4145432

Seems(¹) they work fine(²) and fix this issue for me.

(¹) I fear the current connection will break ten seconds after I submit this

(²) had some trouble at first, but I guess my Wifi router and or the hardware in my laptop was mixed up. Now it just works fine and I haven't had any problems for nearly two hours(¹)

--- Additional comment from kevin on 2012-06-10 20:40:02 EDT ---

Seems much better here with that kernel/patches. 

Up 6 hours or so where I have been running backups over the wireless... looking good so far.

--- Additional comment from sontek on 2012-06-10 21:53:21 EDT ---

Are there easy commands I can run to try it out as well?

--- Additional comment from sgruszka on 2012-06-11 05:00:51 EDT ---

Josh, please apply patches from comment 7 as fix for this bug. They are needed on older Fedoras as well, and could fix some other iwlwifi bugzillas.

--- Additional comment from jwboyer on 2012-06-11 07:55:12 EDT ---

(In reply to comment #15)
> Josh, please apply patches from comment 7 as fix for this bug. They are
> needed on older Fedoras as well, and could fix some other iwlwifi bugzillas.

OK.

F16 should be rebasing to 3.4.2 sometime later this week.  I'll make sure to ask that they carry these patches over.

F15 is going EOL in 2 weeks.  It's not being rebased to 3.4.  I can add these patches there, but they might not make it into a build that gets submitted before it goes EOL.

--- Additional comment from jwboyer on 2012-06-11 08:09:15 EDT ---

Applied to rawhide and F17.

--- Additional comment from fedora on 2012-06-11 13:46:07 EDT ---

Just FYI, the kernels mentioned in comment 10 seem to make things better for me, but I still see problems -- especially when I move my laptop or when the distance to the wifi router is big; for example I encounter disconnection every 20 to 30 minutes when I'm on my balcony, where wifi used to work just fine nearly always with 3.3 :-/

I have no time for debugging the issue further right now, but I just wanted to let everybody know

--- Additional comment from kevin on 2012-06-11 14:34:48 EDT ---

Yeah, I got one hangup this morning here too after many hours of operation... 

So, I think it's _much_ better with the patches, but there's still some issue somewhere.

--- Additional comment from sontek on 2012-06-11 17:49:37 EDT ---

I can confirm if I'm in my room (further away from router) the connection doesn't work at all in 3.4 but if I'm close to the router it works just fine.

In 3.3 it works just fine from my room.

--- Additional comment from sgruszka on 2012-06-12 03:18:06 EDT ---

We could reopen this bug, but I prefer to do not mix different problems in one bug report, what make mess in comments and increase difficulty to find important information. Please clone this bug report into another one and provide description of that remaining problem there (i.e. step to reproduce, etc).

--- Additional comment from meijer.o on 2012-06-14 15:05:14 EDT ---

I reopen the bug, as I believe it is not fixed. My internetconnection is very unstable (fibre to the home, very fast internet connection.)

I tested the kernel mentioned in comment 10

ProBook 4530s

lspci
24:00.0 Network controller: Intel Corporation Centrino Advanced-N 6230 (rev 34)


3.3.8-1.fc16.x86_64 #1 SMP Mon Jun 4 20:49:02 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux on Fedora 17
All perfect 75Mbit/sec. (fibre to the home)


3.4.0-1.fc17.x86_64 #1 SMP Sun Jun 3 06:35:17 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux  Slow and comes to halt

[  172.104791] wlan0: no IPv6 routers present 
[  179.046905] iwlwifi 0000:24:00.0: Queue 12 stuck for 10000 ms. 
[  179.046910] iwlwifi 0000:24:00.0: Current SW read_ptr 92 write_ptr 224 
[  179.046951] iwlwifi 0000:24:00.0: Current HW read_ptr 92 write_ptr 224 
[  179.046953] iwlwifi 0000:24:00.0: On demand firmware reload 
[  179.047343] ieee80211 phy0: Hardware restart was requested 
[  179.047385] iwlwifi 0000:24:00.0: L1 Disabled; Enabling L0S 
[  179.053856] iwlwifi 0000:24:00.0: Radio type=0x1-0x2-0x0 

Max 5Mbit/sec and comes to zero on hardware restart. 



Linux localhost.localdomain 3.4.2-2.knurd.fc17.x86_64 #1 SMP Sun Jun 10 08:43:31 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux see Comment nr. 10

Becomes very slow, drops from 10Mbit/sec to less then  1Mbit/sec after a few tests on speedtest.net.

Hope you can fix this bug for me. I provide further information if needed

Best regards,

Otto Meijer

--- Additional comment from updates on 2012-06-15 02:24:38 EDT ---

kernel-3.4.2-4.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/kernel-3.4.2-4.fc17

--- Additional comment from updates on 2012-06-15 02:25:47 EDT ---

kernel-3.4.2-1.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/kernel-3.4.2-1.fc16

--- Additional comment from meijer.o on 2012-06-15 15:36:34 EDT ---

kernel-3.4.2-4.fc17 did not fix it,

Internet connextion very slow and flaky with this kernel,

uname -a
3.4.2-4.fc17.x86_64 #1 SMP Thu Jun 14 22:22:05 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux 
[  384.906225] wlan0: associated 
[  389.177132] iwlwifi 0000:24:00.0: Queue 12 stuck for 10000 ms. 
[  389.177143] iwlwifi 0000:24:00.0: Current SW read_ptr 88 write_ptr 118 
[  389.177182] iwlwifi 0000:24:00.0: Current HW read_ptr 88 write_ptr 118 
[  389.177188] iwlwifi 0000:24:00.0: On demand firmware reload 
[  389.177660] ieee80211 phy0: Hardware restart was requested 
[  389.177728] iwlwifi 0000:24:00.0: L1 Disabled; Enabling L0S 
[  389.184250] iwlwifi 0000:24:00.0: Radio type=0x1-0x2-0x0 
[  390.354884] cfg80211: Calling CRDA to update world regulatory domain 
[  390.358275] cfg80211: World regulatory domain updated: 
[  390.358282] cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) 

Same error?

Best regards,

Otto

--- Additional comment from updates on 2012-06-15 19:49:18 EDT ---

Package kernel-3.4.2-4.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing kernel-3.4.2-4.fc17'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-9501/kernel-3.4.2-4.fc17
then log in and leave karma (feedback).

--- Additional comment from dopey on 2012-06-16 17:50:28 EDT ---


$ uname -r
3.4.2-4.fc17.x86_64


As noted in Comment 25 this is still not fixed

[ 9168.354006] iwlwifi 0000:03:00.0: Queue 2 stuck for 2000 ms.
[ 9168.354017] iwlwifi 0000:03:00.0: Current SW read_ptr 208 write_ptr 209
[ 9168.354075] iwlwifi 0000:03:00.0: Current HW read_ptr 208 write_ptr 209
[ 9168.354081] iwlwifi 0000:03:00.0: On demand firmware reload
[ 9168.354610] ieee80211 phy0: Hardware restart was requested
[ 9168.354716] iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S
[ 9168.354915] iwlwifi 0000:03:00.0: Radio type=0x0-0x3-0x1


And also, performance gets progessively worse over time.

--- Additional comment from rkennke on 2012-06-17 10:47:09 EDT ---

This bug is still not fixed for me with 3.4.2-4.fc17, network breaks down every now and then. Even worse, the workaround which used to be wd_disable=1 is also broken now (https://bugzilla.redhat.com/show_bug.cgi?id=831571).

--- Additional comment from updates on 2012-06-17 18:22:58 EDT ---

kernel-3.4.2-4.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

--- Additional comment from dopey on 2012-06-18 10:02:48 EDT ---

This issue is definitely not fixed.  Can this bug be re-opened and looked at again?

--- Additional comment from fedora on 2012-06-18 10:06:48 EDT ---

(In reply to comment #30)
> This issue is definitely not fixed.

Something was fixed.

>  Can this bug be re-opened and looked at again?

Quoting comment 21:

"""
We could reopen this bug, but I prefer to do not mix different problems in one bug report, what make mess in comments and increase difficulty to find important information. Please clone this bug report into another one and provide description of that remaining problem there (i.e. step to reproduce, etc).
"""

I agree with that.
Comment 1 Andy Wang 2012-06-18 15:52:14 UTC 
As per comments from bug 825491 cloning and opening a new bug.
I still have the exact same symptoms as the original bug reporter.  Unfortunately, i have no idea how to reproduce this other than to start transferring stuff over wifi and wait for it to occur.

--- Additional comment from dopey on 2012-06-16 17:50:28 EDT ---


$ uname -r
3.4.2-4.fc17.x86_64


As noted in Comment 25 this is still not fixed

[ 9168.354006] iwlwifi 0000:03:00.0: Queue 2 stuck for 2000 ms.
[ 9168.354017] iwlwifi 0000:03:00.0: Current SW read_ptr 208 write_ptr 209
[ 9168.354075] iwlwifi 0000:03:00.0: Current HW read_ptr 208 write_ptr 209
[ 9168.354081] iwlwifi 0000:03:00.0: On demand firmware reload
[ 9168.354610] ieee80211 phy0: Hardware restart was requested
[ 9168.354716] iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S
[ 9168.354915] iwlwifi 0000:03:00.0: Radio type=0x0-0x3-0x1


And also, performance gets progessively worse over time.
Comment 2 Luis Medinas 2012-06-18 17:12:22 UTC 
I belive this was fixed in 3.4.3 see the changelog: http://www.kernel.org/pub/linux/kernel/v3.0/ChangeLog-3.4.3
Comment 3 Thorsten Leemhuis 2012-06-18 17:40:11 UTC 
(In reply to comment #2)
> I belive this was fixed in 3.4.3 see the changelog:
> http://www.kernel.org/pub/linux/kernel/v3.0/ChangeLog-3.4.3

Not that I can see, as Fedora already carried some (most?; didn't check) of the patches that were merged there in its 3.4.2 kernel

FWIW, I'm still seeing problems in 3.5.0-0.rc2.git0.3.fc18.x86_64
Comment 4 Peter Robinson 2012-06-19 20:20:18 UTC 
I'm still seeing the same issue with kernel-3.4.2-4.fc17.x86_64 and the following NIC

02:00.0 Network controller: Intel Corporation Centrino Advanced-N 6200 (rev 35)
Comment 5 Stanislaw Gruszka 2012-06-20 06:26:54 UTC 
There are iwlwifi parameters that could workaround this bug wd_disable and 11n_disable.
Comment 6 Stanislaw Gruszka 2012-06-20 06:37:21 UTC 
Actually on 3.4 11n_disable is broken, that will be fixed soon.
Comment 7 Johannes Berg 2012-06-20 06:53:56 UTC 
Sorry, no, my mistake; 11n_disable=1 is broken on 3.5, not 3.4.
Comment 8 João Gomes 2012-06-20 10:17:59 UTC 
I think the problem is not visible in kernel 3.5. Or at least, is much better.

I tried kernels 3.2, 3.3, 3.4, and 3.5 in Fedora and ubuntu (mint), and kernels 3.3 and 3.4 in arch linux.

In all cases, there were many problems with wifi connection when using kernels 3.3 and 3.4 (including 3.4.3).

With kernel 3.2 there were no problems. I'm still experimenting kernel 3.5 in both fedora and ubuntu but it seems to be much better. I can now use the wifi conenction with no major problems.
However, kernel 3.5 is still a little unstable.


wifi controler:
01:00.0 Network controller: Intel Corporation Centrino Advanced-N 6230 (rev 34)
Comment 9 João Gomes 2012-06-21 00:05:44 UTC 
After testing more deeply the wifi connection with kernel 3.5, I noticed that the problem remains.

Actually, the connection is now much more stable. I can now work without continuouly losing connectivity.

However, the connection seemed to be much slower.
So, I compared it with Windows and linux with kernel 3.2.
I download an ISO file from the same url and using the same machine.
When using Windows or linux with kernel 3.2, the connection speed is very similar.
With kernel 3.5, the connection is much slower, less than half the speed.
And this happens even if I configure the wireless router to use only 802.11 G.
Apparently, it isn't an exclusive problem of 802.11 N.
Comment 10 Joshua Wulf 2012-06-22 01:09:32 UTC 
I have this problem with kernel 3.4.3-1 on a Lenovo T510

Kernel:
Linux dhcp-1-77.bne.redhat.com 3.4.3-1.fc17.x86_64 #1 SMP Mon Jun 18 19:53:17 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

wifi:
03:00.0 Network controller: Intel Corporation Centrino Ultimate-N 6300 (rev 35)

Frequent occurrences of this:

Jun 22 10:55:37 dhcp-1-77 kernel: [14904.742979] iwlwifi 0000:03:00.0: Queue 11 stuck for 2000 ms.
Jun 22 10:55:37 dhcp-1-77 kernel: [14904.742985] iwlwifi 0000:03:00.0: Current SW read_ptr 169 write_ptr 183
Jun 22 10:55:37 dhcp-1-77 kernel: [14904.743037] iwlwifi 0000:03:00.0: Current HW read_ptr 169 write_ptr 183
Jun 22 10:55:37 dhcp-1-77 kernel: [14904.743040] iwlwifi 0000:03:00.0: On demand firmware reload
Jun 22 10:55:37 dhcp-1-77 kernel: [14904.743490] ieee80211 phy0: Hardware restart was requested
Jun 22 10:55:37 dhcp-1-77 kernel: [14904.743563] iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S
Jun 22 10:55:37 dhcp-1-77 kernel: [14904.743754] iwlwifi 0000:03:00.0: Radio type=0x0-0x3-0x1
Jun 22 11:01:22 dhcp-1-77 kernel: [15248.737344] cfg80211: Calling CRDA to update world regulatory domain
Jun 22 11:01:22 dhcp-1-77 NetworkManager[781]: <info> (wlan0): supplicant interface state: completed -> disconnected
Comment 11 Joshua Wulf 2012-06-22 02:26:35 UTC 
Getting the same thing with 3.3.4-3 in F16, slightly different wifi card:

Linux nitai 3.3.4-3.fc16.x86_64 #1 SMP Thu May 3 14:46:44 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

03:00.0 Network controller: Intel Corporation Centrino Ultimate-N 6300 (rev 3e)

Jun 22 12:21:23 nitai kernel: [41126.742767] iwlwifi 0000:03:00.0: Queue 11 stuck for 2000 ms.
Jun 22 12:21:23 nitai kernel: [41126.742771] iwlwifi 0000:03:00.0: Current SW read_ptr 235 write_ptr 59
Jun 22 12:21:23 nitai kernel: [41126.742822] iwlwifi 0000:03:00.0: Current HW read_ptr 235 write_ptr 59
Jun 22 12:21:23 nitai kernel: [41126.742825] iwlwifi 0000:03:00.0: On demand firmware reload
Jun 22 12:21:23 nitai kernel: [41126.743226] ieee80211 phy0: Hardware restart was requested
Jun 22 12:21:23 nitai kernel: [41126.743313] iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S
Jun 22 12:21:23 nitai kernel: [41126.743488] iwlwifi 0000:03:00.0: Radio type=0x0-0x3-0x1
Comment 12 Joshua Wulf 2012-06-22 07:41:18 UTC 
I get this behaviour when connecting to an Airport Express at home.

However, when connecting to the wireless AP at the office I have a rock solid connection; so it seems to be a combination of:
 
[kernel code]: 3.3.4-3.fc16 & 3.4.3-1.fc17
[wireless chipset]: Centrino Ultimate-N 6300
[AP  or environmental factors]: Apple Airport Express


I'll check the channel settings on the AP at home and compare them with the AP settings in the office, and see if I can narrow it down further.
Comment 13 Toby Haynes 2012-06-23 01:47:30 UTC 
This is another data point from a Lenovo W510.

03:00.0 Network controller: Intel Corporation Centrino Ultimate-N 6300 (rev 35)
	Subsystem: Intel Corporation Centrino Ultimate-N 6300 3x3 AGN
	Flags: bus master, fast devsel, latency 0, IRQ 55
	Memory at f2000000 (64-bit, non-prefetchable) [size=8K]
	Capabilities: [c8] Power Management version 3
	Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
	Capabilities: [e0] Express Endpoint, MSI 00
	Capabilities: [100] Advanced Error Reporting
	Capabilities: [140] Device Serial Number 00-24-d7-ff-ff-70-cc-28
	Kernel driver in use: iwlwifi

Works fine at authenticating with LEAP to the company network. At home using WPA2 against a , it works fine if I sit within 3 metres of the access point but if I move a little further away, it eventually drops out (within a few minutes). If I use VPNC to work, it drops out a whole lot faster.
Comment 14 Toby Haynes 2012-06-23 01:51:22 UTC 
I should add

Linux nexus6.torolab.ibm.com 3.4.3-1.fc17.x86_64 #1 SMP Mon Jun 18 19:53:17 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Comment 15 Tom O. 2012-06-24 22:05:59 UTC 
Have the same problems with Fedora 16 on my Thinkpad T510. 

When connected to a wireless access point with WPA2 (FRITZ!Box), the connection sometimes stops, however the (k)networkmanager still shows an active and alive connection. 

If I disable wireless and networking in knetworkmanager, and then re-enable it, wifi works again until the next stop sometime later.

Kernel: 3.4.2-1.fc16.x86_64
03:00.0 Network controller: Intel Corporation Centrino Ultimate-N 6300 (rev 35)
Comment 16 Tom O. 2012-06-24 22:30:35 UTC 
Also, whenever the connection to the internet is not working, dmesg gives me:

 1195.465827] wlan0: authenticate with bc:05:43:49:12:c9
[ 1195.470281] wlan0: send auth to bc:05:43:49:12:c9 (try 1/3)
[ 1195.479621] wlan0: authenticated
[ 1195.480603] wlan0: associate with bc:05:43:49:12:c9 (try 1/3)
[ 1195.485430] wlan0: RX AssocResp from bc:05:43:49:12:c9 (capab=0x431 status=0 aid=1)
[ 1195.485436] wlan0: associated
[ 1738.945625] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
[ 1855.835088] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
[ 1909.752134] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
[ 1911.755617] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
[ 2038.592005] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
[ 2047.635404] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
[ 2055.405972] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
Comment 17 Matt Kinni 2012-06-25 16:54:39 UTC 
just posting a "me too" message with kernel 3.4.3-1.fc17.x86_64

[ 5939.491305] iwlwifi 0000:25:00.0: Queue 2 stuck for 2000 ms.
[ 5939.491315] iwlwifi 0000:25:00.0: Current SW read_ptr 110 write_ptr 113
[ 5939.491354] iwlwifi 0000:25:00.0: Current HW read_ptr 110 write_ptr 113
[ 5939.491360] iwlwifi 0000:25:00.0: On demand firmware reload
[ 5939.491776] ieee80211 phy0: Hardware restart was requested
[ 5939.491840] iwlwifi 0000:25:00.0: L1 Disabled; Enabling L0S
[ 5939.491983] iwlwifi 0000:25:00.0: Radio type=0x0-0x3-0x1
[ 5956.055551] wlan0: deauthenticating from 00:dd:9d:86:f1:6b by local choice (reason=3)
[ 5956.094408] cfg80211: Calling CRDA to update world regulatory domain
[ 5956.115033] bridge-wlan0: disabling the bridge on dev down
[ 5956.115073] bridge-wlan0: down
[ 5956.127881] bridge-wlan0: detached
[ 5956.128042] cfg80211: World regulatory domain updated:
[ 5956.128052] cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[ 5956.128063] cfg80211:   (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 5956.128072] cfg80211:   (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[ 5956.128081] cfg80211:   (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[ 5956.128089] cfg80211:   (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 5956.128098] cfg80211:   (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 5956.128554] cfg80211: Calling CRDA for country: SE
[ 5956.134044] cfg80211: Regulatory domain changed to country: SE
[ 5956.134051] cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[ 5956.134058] cfg80211:   (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
[ 5956.134064] cfg80211:   (5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm)
[ 5956.134069] cfg80211:   (5250000 KHz - 5330000 KHz @ 40000 KHz), (N/A, 2000 mBm)
[ 5956.134074] cfg80211:   (5490000 KHz - 5710000 KHz @ 40000 KHz), (N/A, 2700 mBm)
[ 5956.248893] cfg80211: Calling CRDA to update world regulatory domain
[ 5956.252853] cfg80211: World regulatory domain updated:
[ 5956.252860] cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[ 5956.252867] cfg80211:   (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 5956.252873] cfg80211:   (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[ 5956.252879] cfg80211:   (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[ 5956.252884] cfg80211:   (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 5956.252889] cfg80211:   (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 5956.259032] Intel(R) Wireless WiFi Link AGN driver for Linux, in-tree:d
[ 5956.259034] Copyright(c) 2003-2012 Intel Corporation
[ 5956.259129] iwlwifi 0000:25:00.0: pci_resource_len = 0x00002000
[ 5956.259131] iwlwifi 0000:25:00.0: pci_resource_base = ffffc900117ec000
[ 5956.259132] iwlwifi 0000:25:00.0: HW Revision ID = 0x35
[ 5956.259226] iwlwifi 0000:25:00.0: irq 58 for MSI/MSI-X
[ 5956.263597] iwlwifi 0000:25:00.0: loaded firmware version 9.221.4.1 build 25532
[ 5956.263828] iwlwifi 0000:25:00.0: CONFIG_IWLWIFI_DEBUG enabled
[ 5956.263830] iwlwifi 0000:25:00.0: CONFIG_IWLWIFI_DEBUGFS enabled
[ 5956.263831] iwlwifi 0000:25:00.0: CONFIG_IWLWIFI_DEVICE_TRACING disabled
[ 5956.263832] iwlwifi 0000:25:00.0: CONFIG_IWLWIFI_DEVICE_TESTMODE disabled
[ 5956.263833] iwlwifi 0000:25:00.0: CONFIG_IWLWIFI_P2P disabled
[ 5956.263835] iwlwifi 0000:25:00.0: Detected Intel(R) Centrino(R) Ultimate-N 6300 AGN, REV=0x74


Sometimes it fixes itself, and sometimes I have to reload the module with modprobe or cycle the hardware switch manually
Comment 18 tom.jenkinson 2012-06-25 21:25:21 UTC 
"Me too":

FC17 with latest updates:

[tom@tomsfc17 ~]$ uname -r
3.4.3-1.fc17.x86_64

[  898.444187] usb 1-1.1: USB disconnect, device number 8
[ 2104.110358] iwlwifi 0000:03:00.0: Queue 2 stuck for 2000 ms.
[ 2104.110364] iwlwifi 0000:03:00.0: Current SW read_ptr 177 write_ptr 183
[ 2104.110416] iwlwifi 0000:03:00.0: Current HW read_ptr 177 write_ptr 183
[ 2104.110419] iwlwifi 0000:03:00.0: On demand firmware reload
[ 2104.110823] ieee80211 phy0: Hardware restart was requested
[ 2104.110895] iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S
[ 2104.111083] iwlwifi 0000:03:00.0: Radio type=0x0-0x3-0x1

[tom@tomsfc17 ~]$ lspci | grep "Network controller"
03:00.0 Network controller: Intel Corporation Centrino Ultimate-N 6300 (rev 35)

Lenovo Thinkpad T510
Comment 19 Nick Cross 2012-06-27 05:41:29 UTC 
Me too:

FC16 with latest updates:

Jun 27 06:33:48 localhost kernel: [78505.341557] iwlwifi 0000:03:00.0: Queue 12 stuck for 2000 ms.
Jun 27 06:33:48 localhost kernel: [78505.341570] iwlwifi 0000:03:00.0: Current SW read_ptr 194 write_ptr 32
Jun 27 06:33:48 localhost kernel: [78505.341649] iwlwifi 0000:03:00.0: Current HW read_ptr 194 write_ptr 32
Jun 27 06:33:48 localhost kernel: [78505.341657] iwlwifi 0000:03:00.0: On demand firmware reload
Jun 27 06:33:48 localhost kernel: [78505.342480] ieee80211 phy0: Hardware restart was requested
Jun 27 06:33:48 localhost kernel: [78505.342638] iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S
Jun 27 06:33:48 localhost kernel: [78505.342889] iwlwifi 0000:03:00.0: Radio type=0x0-0x3-0x1

lspci | grep "Network controller"
03:00.0 Network controller: Intel Corporation Centrino Ultimate-N 6300 (rev 35)

uname -r
3.4.2-1.fc16.x86_64
Comment 20 tom.jenkinson 2012-06-29 12:26:42 UTC 
Got it again on FC16 though:

[21528.114050] iwlwifi 0000:03:00.0: Queue 2 stuck for 2000 ms.
[21528.114056] iwlwifi 0000:03:00.0: Current SW read_ptr 126 write_ptr 133
[21528.114109] iwlwifi 0000:03:00.0: Current HW read_ptr 126 write_ptr 133
[21528.114112] iwlwifi 0000:03:00.0: On demand firmware reload
[21528.114586] ieee80211 phy0: Hardware restart was requested
[21528.114659] iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S
[21528.114850] iwlwifi 0000:03:00.0: Radio type=0x0-0x3-0x1
Comment 21 Nick Cross 2012-07-02 11:21:49 UTC 
And twice more this morning with F16 (same config as above) :-(

[  160.600837] iwlwifi 0000:03:00.0: Queue 2 stuck for 2000 ms.
[  160.600852] iwlwifi 0000:03:00.0: Current SW read_ptr 182 write_ptr 188
[  160.600982] iwlwifi 0000:03:00.0: Current HW read_ptr 182 write_ptr 188
[  160.600984] iwlwifi 0000:03:00.0: On demand firmware reload
[  160.601623] ieee80211 phy0: Hardware restart was requested
[  160.601774] iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S
[  160.602028] iwlwifi 0000:03:00.0: Radio type=0x0-0x3-0x1
[  445.386086] TCP: lp registered
Comment 22 Paul Wouters 2012-07-03 19:54:36 UTC 
Still happening with 3.4.4-3.fc17.x86_64
Comment 23 Paul Wouters 2012-07-03 20:51:38 UTC 
It seems for me power_save=0 is the module parameter that helps me best
Comment 24 tom.jenkinson 2012-07-04 08:50:52 UTC 
Hi Paul,

Please can you elaborate? Is power_save=0 an option that we need to add into linux parameters for: /boot/grub2/grub.cfg

Also, when you say "helps me best", does that mean that you have never had the issue when you have that set?

Tom
Comment 25 Paul Wouters 2012-07-04 16:47:34 UTC 
It's a module parameter, so I put it in /etc/modprobe.d/iwlwifi.conf

options iwlwifi power_save=0


I still have some issues, and when it gets busy in our hackerspace I still see a lot more issues then other people remaining connected. But with this setting, at home where I use a TPlink http://www.tp-link.com/ca/products/details/?categoryid=241&model=TL-WR702N which causes my wifi card to lock up in seconds and reboot itself, so I can't actually use it at all, even if I'm a meter away from it. One every 10 pings will take 3000ms. With this option set, I can stay online at home.
Comment 26 tom.jenkinson 2012-07-04 16:52:53 UTC 
Thanks for the clarification, much appreciated
Comment 27 Joshua Wulf 2012-07-04 22:49:21 UTC 
This one is giving me the love. Thanks!

(In reply to comment #25)
> It's a module parameter, so I put it in /etc/modprobe.d/iwlwifi.conf
> 
> options iwlwifi power_save=0
> 
> 
> I still have some issues, and when it gets busy in our hackerspace I still
> see a lot more issues then other people remaining connected. But with this
> setting, at home where I use a TPlink
> http://www.tp-link.com/ca/products/details/?categoryid=241&model=TL-WR702N
> which causes my wifi card to lock up in seconds and reboot itself, so I
> can't actually use it at all, even if I'm a meter away from it. One every 10
> pings will take 3000ms. With this option set, I can stay online at home.
Comment 28 Wade Mealing 2012-07-04 23:54:56 UTC 
I've also been running with wd_disable=1 for about a week with no issues.
Comment 29 John Anderson 2012-07-05 06:10:10 UTC 
Created attachment 596332 [details]
errors I'm getting

Linux ovo 3.4.4-3.fc17.i686 #1 SMP Tue Jun 26 21:32:03 UTC 2012 i686 i686 i386 GNU/Linux
Comment 30 Tom O. 2012-07-15 02:07:36 UTC 
At least for me the recent kernel update towards 3.4.4-4.fc16.x86_64 fixed the problem. My PC configuration is detailed in Comment 15.
Comment 31 Joel Uckelman 2012-07-15 10:50:23 UTC 
(In reply to comment #30)
> At least for me the recent kernel update towards 3.4.4-4.fc16.x86_64 fixed
> the problem. My PC configuration is detailed in Comment 15.

I have a similar configuration---ThinkPad W520, and a Fritz!Box access point using WPA2---and I still get the same stuck queue problem with 3.4.4-5 in F17.
Comment 32 Paul Wouters 2012-07-15 22:52:50 UTC 
Same here, still issues with 3.4.4-5 in F17 on Thinkpad X201
Comment 33 irosenhagen 2012-07-22 10:55:19 UTC 
Problem still there on Thinkpad x201 with 3.4.6:


ingmar@th1nkpad ~ % uname -a
Linux th1nkpad 3.4.6-2.fc17.x86_64 #1 SMP Thu Jul 19 22:54:16 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

02:00.0 Network controller: Intel Corporation Centrino Ultimate-N 6300 (rev 35)

[  754.136836] iwlwifi 0000:02:00.0: Queue 2 stuck for 2000 ms.
[  754.136843] iwlwifi 0000:02:00.0: Current SW read_ptr 15 write_ptr 55
[  754.136898] iwlwifi 0000:02:00.0: Current HW read_ptr 15 write_ptr 55
[  754.136902] iwlwifi 0000:02:00.0: On demand firmware reload
[  754.141446] iwlwifi 0000:02:00.0: Failing on timeout while stopping DMA channel 1 [0x07fd0001]
[  754.141995] ieee80211 phy0: Hardware restart was requested
Comment 34 Paul Wouters 2012-07-31 20:39:42 UTC 
As a further note, I did not experience any issues at a super busy IETF network, so i think this really relates to some (cheao?) AP implementation interaction with my intel card.
Comment 35 Stanislaw Gruszka 2012-11-16 11:01:43 UTC 
Does the problem still happen on 3.6.5 or later ?
Comment 36 Otto Meijer 2012-11-16 12:42:01 UTC 
Kernel 3.6 and later fixes the bug for me.

Network controller: Intel Corporation Centrino Advanced-N 6230 (rev 34)

Best regards,

Otto
Comment 37 Tom O. 2012-11-16 12:44:33 UTC 
The problem did not appear anymore on my Thinkpad T510 with Fedora 16 for quite a while. The last 3.4.x kernels as well as the 3.6.x kernel do not have the flaky wifi behaviour anymore.

3.6.6-1.fc16.x86_64
iwlwifi 0000:03:00.0: Detected Intel(R) Centrino(R) Ultimate-N 6300 AGN, REV=0x74
Comment 38 Stanislaw Gruszka 2012-11-16 15:02:43 UTC 
Closing per above comments ...