+++ 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.
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.
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
(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
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)
There are iwlwifi parameters that could workaround this bug wd_disable and 11n_disable.
Actually on 3.4 11n_disable is broken, that will be fixed soon.
Sorry, no, my mistake; 11n_disable=1 is broken on 3.5, not 3.4.
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)
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.
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
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
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.
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.
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
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)
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
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
"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
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
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
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
Still happening with 3.4.4-3.fc17.x86_64
It seems for me power_save=0 is the module parameter that helps me best
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
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.
Thanks for the clarification, much appreciated
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.
I've also been running with wd_disable=1 for about a week with no issues.
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
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.
(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.
Same here, still issues with 3.4.4-5 in F17 on Thinkpad X201
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
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.
Does the problem still happen on 3.6.5 or later ?
Kernel 3.6 and later fixes the bug for me. Network controller: Intel Corporation Centrino Advanced-N 6230 (rev 34) Best regards, Otto
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
Closing per above comments ...