Created attachment 557923 [details] dmesg Description of problem: (iwlwifi module) The wifi connection by Intel WiFi 5100 Network Controller becomes very poor after few minutes; then absent. This problem is attend only with lastest kernel-3.2* including kernel-3.2.2-1 used to resolv the Bug784345. This issue do not exist with others wifi devices. Version-Release number of selected component (if applicable): kernel-3.2.2-1.fc16.x86_64 iwl5000-firmware-8.83.5.1_1-1.fc16.noarch How reproducible: After few minutes of wifi connection. Additional info: 07:00.0 Network controller [0280]: Intel Corporation WiFi Link 5100 [8086:4232]
Created attachment 557924 [details] messages
John, Davej has been fighting iwlwifi in 3.3 git for a while now. Since we're now using 3.3-rc1, this might be the same issue. I think Intel has a test patch they've sent out.
(In reply to comment #2) > John, Davej has been fighting iwlwifi in 3.3 git for a while now. Since we're > now using 3.3-rc1, this might be the same issue. I think Intel has a test > patch they've sent out. So is there not fix (or patch) for this problem now ? Thanks.
The same behavior here: Intel Corporation Ultimate N WiFi Link 5300 3.2.2-1.fc16.x86_64 The only message related to wifi in logs: [23362.581447] iwlwifi 0000:05:00.0: Tx aggregation enabled on ra = c0:c1:c0:32:25:98 tid = 0 that seems to appear just before the interface dies. The timings are more or less random and rf-killing seems to work as recovery mechanism.
Please create a file called /etc/modprobe.d/iwlwifi.conf with a single line like this: options iwlwifi 11n_disable=1 Then reboot (or "modprobe -r iwlwifi ; modprobe iwlwifi" as root). Does that at least keep the interface alive and working?
Created attachment 558382 [details] tid check is this patch from Emmanule help? Thanks Wey
(In reply to comment #5) > Please create a file called /etc/modprobe.d/iwlwifi.conf with a single line > like this: > > options iwlwifi 11n_disable=1 > > Then reboot (or "modprobe -r iwlwifi ; modprobe iwlwifi" as root). Does that > at least keep the interface alive and working? yes, the connection is stable 54Mbps with 11n disabled.
(In reply to comment #5) > Please create a file called /etc/modprobe.d/iwlwifi.conf with a single line > like this: > > options iwlwifi 11n_disable=1 > > Then reboot (or "modprobe -r iwlwifi ; modprobe iwlwifi" as root). Does that > at least keep the interface alive and working? It seems to be more stable for me, too.
any chance to try the patch in "Comment 6"? Thanks Wey
Test kernel w/ above patch building here: http://koji.fedoraproject.org/koji/taskinfo?taskID=3746937 Please give them a test and report the results here -- thanks!
(In reply to comment #10) > Test kernel w/ above patch building here: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=3746937 > > Please give them a test and report the results here -- thanks! kernel-3.2.2-1.bz785561.1.fc16.x86_64.rpm installed. options iwlwifi 11n_disable changed to 0. Connection stable for more of ten minutes. In dmesg (in attachment) is still present the lines : "Tx aggregation enabled on ra = a0:21:b7:65:69:62 tid = 0 " They increase with passage of time.
Created attachment 558445 [details] dmesg with the patched kernel-3.2.2-1 64bit
*** Bug 785822 has been marked as a duplicate of this bug. ***
*** Bug 785848 has been marked as a duplicate of this bug. ***
Hi, thanks for the kernel-3.2.2-1.bz785561.1.fc16.x86_64, because it fix my wifi at home with VPN. Since update to kernel-3.2, wifi hangs specially when I connect to a VPN pptp. So the patch fix wifi here. Thanks, Note : I (still) see on dmesg iwlwifi 0000:02:00.0: Tx aggregation enabled on ra = 00:26:44:e2:96:be tid = 0 iwlwifi 0000:02:00.0: Tx aggregation enabled on ra = 00:26:44:e2:96:be tid = 6 but seems harmless.
This patched kernel seems to be doing the trick. Wifi has been stable for several hours now.
*** Bug 785516 has been marked as a duplicate of this bug. ***
(In reply to comment #15) > Hi, thanks for the kernel-3.2.2-1.bz785561.1.fc16.x86_64, because it fix my > wifi at home with VPN. > Since update to kernel-3.2, wifi hangs specially when I connect to a VPN pptp. > So the patch fix wifi here. > > Thanks, > > Note : > I (still) see on dmesg > iwlwifi 0000:02:00.0: Tx aggregation enabled on ra = 00:26:44:e2:96:be tid = 0 > iwlwifi 0000:02:00.0: Tx aggregation enabled on ra = 00:26:44:e2:96:be tid = 6 > but seems harmless. After a few hour and change wifi , from home to office , after a few suspend and resume , the problem back again. sorry for the bad new, but anyway with patch it works better.
*** Bug 786374 has been marked as a duplicate of this bug. ***
*** Bug 749988 has been marked as a duplicate of this bug. ***
I can confirm that the patched kernel solves the issue for me so far.
Seems to be working so far (I am typing this comment running this kernel and I did not had to restart the connection yet).
kernel 3.2.2-1.bz785561.1.fc16.x86_64 seems to fix the problem for me, too
*** Bug 786605 has been marked as a duplicate of this bug. ***
My laptop has been running for five hours on the new kernel and wireless has not disconnected. I'd call that a fix!
The test kernel (3.2.2-1.bz785561.1.fc16.x86_64) was working find on my ThinkPad W520 until this morning---but now I've had the same problem, where I have to toggle the kill switch for the wireless card, twice in the last 10 minutes. I'm not convinced that this has fixed the problem. What additional diagnostic information can I provide?
The connection is more stable using the kernel-3.2.3-2 without iwlwifi fix of the Comment 5. Thx.
Created attachment 559654 [details] dmesg using the kernel-3.2.3-2
Hi, I found messages on dmesg like: imuxsock begins to drop messages from pid 24280 due to rate-limiting the pid in question is from NetworkManager. Though if it isn't also related with NetworkManager.
The new kernel, 3.2.3-2, break intel wifi in 802.11n in my laptop. I can connect, but don't upload/download data. It work only in 802.11g. My wifi chipset: Intel Corporation Centrino Advanced-N 6200 (rev 35)
Created attachment 559709 [details] dmesg after kernel 3.2.3-2 I add the log of dmesg about the 802.11n broken (my previous comment).
Just adding my bit here. I have an Intel Corporation Ultimate N WiFi Link 5300 and the new kernel 3.2.3-2 works fine and has been stable unlike the prior version. It may be something specific to the 6000 series that is causing it to break.
As of 3.2.6-3 this is still broken with a Centrino 6300. Network controller: Intel Corporation Centrino Ultimate-N 6300 (rev 35)
With kernel 3.2.6-3.fc16.x86_64, I'm finding that heavy network usage can trigger the problem. I was downloading something at > 500KB/s for the past 15 minutes or so, and had to toggle the wireless kill switch three times over that period. What further information is needed so this can be fixed?
3.2.6-3.fc16.x86_64 the same problem Network controller: Intel Corporation Centrino Wireless-N 130 (rev 34)
The problem is a bit different with kernel 3.2.7-1.fc16.x86_64. It seems that instead of the wireless cutting out entirely, what I'm getting now is some intermittently terrible (>3000ms) ping times, interspersed with normal ones (< 3ms).
Joel, anything stand out in the dmesg log? such as firmware reload or probe timeout? Thanks Wey
(In reply to comment #38) > Joel, anything stand out in the dmesg log? such as firmware reload or probe > timeout? > > Thanks > Wey Yes, there's a firmware reload right before the last time the wireless died on me. I'm attaching the output of dmesg now.
Created attachment 565677 [details] dmesg just after wireless died, kernel 3.2.7-1
This problem still occurs with kernel-3.2.9-2.fc16.x86_64. What do we need to do to get this resolved?
I've come across this issue in a few different distributions (currently running Arch) and only found this bug today. The 11n disabling seems to have cured me for now. I do have some additional information that might be of use. It seemed like the speed dropoff would only occur when I was using NetworkManager. If I stopped NetworkManager and initiated the wireless connection with just iwconfig and dhcpcd (network uses a WEP key) then everything seemed to work fine without ever disabling 11n in iwlwifi. Also, my home wireless network did not seem to be affected by this at all (NetworkManager worked fine without disabling 11n) -- only my work network had the issue.
This problem still occurs with kernel-3.2.10-3.fc16.x86_64.
This looks relevant to the "queue stuck" messages: https://lkml.org/lkml/2012/3/4/139 I haven't tried the suggestion to give wd_disable=1 as a kernel parameter yet, but will when I reboot next.
I'm not what Fedora calls a "proventester", so consider this a note from some random person: There clearly was a bug (I was affected) that was fixed by the patches that lead to closing the issue (fine for me, as they fixed it for me, as the problem did not come back). Obviously there are others bugs that lead to similar problems; adding notes about those here just leads to a long, confusing/hard to follow bug report where nobody knows which comment is relevant to the issues that remain unfixed. So I'd suggest those that are still affected open one single new bug report (mention it here once!), gather there and share all the relevant informations, maybe then a clear pattern shows up that can help to track down the root of the issue.
(In reply to comment #45) > I'm not what Fedora calls a "proventester", so consider this a note from some > random person: There clearly was a bug (I was affected) that was fixed by the > patches that lead to closing the issue (fine for me, as they fixed it for me, > as the problem did not come back). > > Obviously there are others bugs that lead to similar problems; adding notes > about those here just leads to a long, confusing/hard to follow bug report > where nobody knows which comment is relevant to the issues that remain unfixed. > So I'd suggest those that are still affected open one single new bug report > (mention it here once!), gather there and share all the relevant informations, > maybe then a clear pattern shows up that can help to track down the root of the > issue. I've filed Bug 805285 for this purpose.
I think one big problem with this is that it also depends on the router hardware you are using. So it may be fixed in some of the setups but not all of them. So I don't know how to deal with that issue.
I got the problem with kernel-3.2.2, after that the problem as fixed and I never got problem again , so I am off this bug .
Still reproducible on FC 17. Kernels 3.3 ... 3.4.0-1.fc17.x86_64 Centrino Ultimate-N 6300
(In reply to comment #49) > Still reproducible on FC 17. It's way more likely you see the problem that is discussed in Bug 825491
(In reply to comment #50) Looks like it is. For now I put my AP to G-only mode, which helps. I will recheck again when patches they mentioned in that bug will hit the FC mainstream kernel. Thank you for pointing me to that bug! > It's way more likely you see the problem that is discussed in Bug 825491