Bug 785239 - Wifi connection by iwlwifi module
Wifi connection by iwlwifi module
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
16
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: John W. Linville
Fedora Extras Quality Assurance
:
: 749988 785516 785822 785848 786374 786605 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-01-27 13:22 EST by Antonio Trande
Modified: 2012-07-17 17:29 EDT (History)
31 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-02-06 10:16:52 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
dmesg (85.30 KB, application/octet-stream)
2012-01-27 13:22 EST, Antonio Trande
no flags Details
messages (173.65 KB, text/plain)
2012-01-27 13:23 EST, Antonio Trande
no flags Details
tid check (1.95 KB, patch)
2012-01-30 10:53 EST, wey-yi.w.guy
no flags Details | Diff
dmesg with the patched kernel-3.2.2-1 64bit (80.56 KB, application/octet-stream)
2012-01-30 15:29 EST, Antonio Trande
no flags Details
dmesg using the kernel-3.2.3-2 (76.17 KB, text/plain)
2012-02-06 09:58 EST, Antonio Trande
no flags Details
dmesg after kernel 3.2.3-2 (23.55 KB, text/plain)
2012-02-06 13:07 EST, Gendre Sébastien
no flags Details
dmesg just after wireless died, kernel 3.2.7-1 (93.38 KB, text/plain)
2012-02-24 16:34 EST, Joel Uckelman
no flags Details

  None (edit)
Description Antonio Trande 2012-01-27 13:22:30 EST
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]
Comment 1 Antonio Trande 2012-01-27 13:23:56 EST
Created attachment 557924 [details]
messages
Comment 2 Josh Boyer 2012-01-27 14:49:47 EST
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.
Comment 3 Antonio Trande 2012-01-28 06:02:39 EST
(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.
Comment 4 Michael 2012-01-30 08:30:54 EST
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.
Comment 5 John W. Linville 2012-01-30 10:07:11 EST
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?
Comment 6 wey-yi.w.guy 2012-01-30 10:53:03 EST
Created attachment 558382 [details]
tid check

is this patch from Emmanule help?

Thanks
Wey
Comment 7 Michael 2012-01-30 11:15:33 EST
(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.
Comment 8 Antonio Trande 2012-01-30 11:28:39 EST
(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.
Comment 9 wey-yi.w.guy 2012-01-30 11:34:27 EST
any chance to try the patch in "Comment 6"?

Thanks
Wey
Comment 10 John W. Linville 2012-01-30 13:17:17 EST
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!
Comment 11 Antonio Trande 2012-01-30 15:27:47 EST
(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.
Comment 12 Antonio Trande 2012-01-30 15:29:21 EST
Created attachment 558445 [details]
dmesg with the patched kernel-3.2.2-1 64bit
Comment 13 John W. Linville 2012-01-31 11:17:44 EST
*** Bug 785822 has been marked as a duplicate of this bug. ***
Comment 14 John W. Linville 2012-01-31 13:47:45 EST
*** Bug 785848 has been marked as a duplicate of this bug. ***
Comment 15 Sergio Monteiro Basto 2012-01-31 22:15:17 EST
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.
Comment 16 John Watzke 2012-02-01 01:19:34 EST
This patched kernel seems to be doing the trick.  Wifi has been stable for several hours now.
Comment 17 John W. Linville 2012-02-01 10:24:52 EST
*** Bug 785516 has been marked as a duplicate of this bug. ***
Comment 18 Sergio Monteiro Basto 2012-02-01 10:38:30 EST
(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.
Comment 19 Jonathan Underwood 2012-02-01 12:22:30 EST
*** Bug 786374 has been marked as a duplicate of this bug. ***
Comment 20 hannes 2012-02-01 15:16:00 EST
*** Bug 749988 has been marked as a duplicate of this bug. ***
Comment 21 hannes 2012-02-01 15:16:56 EST
I can confirm that the patched kernel solves the issue for me so far.
Comment 22 Julian Sikorski 2012-02-01 16:49:36 EST
Seems to be working so far (I am typing this comment running this kernel and I did not had to restart the connection yet).
Comment 23 Thorsten Leemhuis 2012-02-02 13:49:39 EST
kernel 3.2.2-1.bz785561.1.fc16.x86_64 seems to fix the problem for me, too
Comment 24 John W. Linville 2012-02-02 14:02:50 EST
*** Bug 786605 has been marked as a duplicate of this bug. ***
Comment 25 Gary Case 2012-02-02 14:38:44 EST
My laptop has been running for five hours on the new kernel and wireless has not disconnected. I'd call that a fix!
Comment 26 Joel Uckelman 2012-02-04 11:14:24 EST
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?
Comment 27 Antonio Trande 2012-02-06 09:57:22 EST
The connection is more stable using the kernel-3.2.3-2 without iwlwifi fix of the Comment 5.

Thx.
Comment 28 Antonio Trande 2012-02-06 09:58:49 EST
Created attachment 559654 [details]
dmesg using the kernel-3.2.3-2
Comment 29 Sergio Monteiro Basto 2012-02-06 10:31:25 EST
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.
Comment 30 Gendre Sébastien 2012-02-06 13:05:21 EST
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)
Comment 31 Gendre Sébastien 2012-02-06 13:07:21 EST
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).
Comment 32 John Watzke 2012-02-06 14:15:16 EST
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.
Comment 33 Scott Banwart 2012-02-19 15:23:51 EST
As of 3.2.6-3 this is still broken with a Centrino 6300.

Network controller: Intel Corporation Centrino Ultimate-N 6300 (rev 35)
Comment 34 Joel Uckelman 2012-02-20 12:13:41 EST
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?
Comment 35 Dmitry Avershin 2012-02-21 01:38:36 EST
3.2.6-3.fc16.x86_64 the same problem
Network controller: Intel Corporation Centrino Wireless-N 130 (rev 34)
Comment 36 Dmitry Avershin 2012-02-21 01:40:52 EST
3.2.6-3.fc16.x86_64 the same problem
Network controller: Intel Corporation Centrino Wireless-N 130 (rev 34)
Comment 37 Joel Uckelman 2012-02-24 15:54:51 EST
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).
Comment 38 wey-yi.w.guy 2012-02-24 16:05:33 EST
Joel, anything stand out in the dmesg log? such as firmware reload or probe timeout?

Thanks
Wey
Comment 39 Joel Uckelman 2012-02-24 16:31:22 EST
(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.
Comment 40 Joel Uckelman 2012-02-24 16:34:46 EST
Created attachment 565677 [details]
dmesg just after wireless died, kernel 3.2.7-1
Comment 41 Joel Uckelman 2012-03-15 16:57:07 EDT
This problem still occurs with kernel-3.2.9-2.fc16.x86_64. What do we need to do to get this resolved?
Comment 42 Kyle Tirak 2012-03-16 17:56:03 EDT
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.
Comment 43 Joel Uckelman 2012-03-20 14:50:42 EDT
This problem still occurs with kernel-3.2.10-3.fc16.x86_64.
Comment 44 Joel Uckelman 2012-03-20 14:59:19 EDT
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.
Comment 45 Thorsten Leemhuis 2012-03-20 15:06:20 EDT
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.
Comment 46 Joel Uckelman 2012-03-20 15:49:14 EDT
(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.
Comment 47 hannes 2012-03-20 16:16:05 EDT
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.
Comment 48 Sergio Monteiro Basto 2012-03-24 06:48:27 EDT
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 .
Comment 49 nikodll 2012-06-08 15:39:04 EDT
Still reproducible on FC 17. Kernels 3.3 ... 3.4.0-1.fc17.x86_64

Centrino Ultimate-N 6300
Comment 50 Thorsten Leemhuis 2012-06-09 16:57:15 EDT
(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
Comment 51 nikodll 2012-06-09 17:10:15 EDT
(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

Note You need to log in before you can comment on or make changes to this bug.