Bug 825491 - kernel 3.4.0 iwlwifi flaky
kernel 3.4.0 iwlwifi flaky
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: John W. Linville
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-26 16:51 EDT by Kevin Fenzi
Modified: 2014-09-29 16:46 EDT (History)
27 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 833117 (view as bug list)
Environment:
Last Closed: 2012-06-17 18:22:58 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch to add patches mentioned ion comment 7 to the F17 kernel package (5.97 KB, patch)
2012-06-10 07:32 EDT, Thorsten Leemhuis
no flags Details | Diff

  None (edit)
Description Kevin Fenzi 2012-05-26 16:51:51 EDT
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.
Comment 2 Stanislaw Gruszka 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.
Comment 3 Kevin Fenzi 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. ;)
Comment 4 Kevin Fenzi 2012-06-08 17:48:41 EDT
wd_disable=1 doesn't seem to help any.
Comment 5 John Anderson 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
Comment 6 Stanislaw Gruszka 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
Comment 8 Thorsten Leemhuis 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)
Comment 9 John Anderson 2012-06-09 17:24:00 EDT
03:00.0 Network controller: Intel Corporation Centrino Advanced-N 6205 (rev 34)
Comment 10 Thorsten Leemhuis 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.
Comment 11 Thorsten Leemhuis 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
Comment 12 Thorsten Leemhuis 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(¹)
Comment 13 Kevin Fenzi 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.
Comment 14 John Anderson 2012-06-10 21:53:21 EDT
Are there easy commands I can run to try it out as well?
Comment 15 Stanislaw Gruszka 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.
Comment 16 Josh Boyer 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.
Comment 17 Josh Boyer 2012-06-11 08:09:15 EDT
Applied to rawhide and F17.
Comment 18 Thorsten Leemhuis 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
Comment 19 Kevin Fenzi 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.
Comment 20 John Anderson 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.
Comment 21 Stanislaw Gruszka 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).
Comment 22 Otto Meijer 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
Comment 23 Fedora Update System 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
Comment 24 Fedora Update System 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
Comment 25 Otto Meijer 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
Comment 26 Fedora Update System 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).
Comment 27 Andy Wang 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 28 Roman Kennke 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).
Comment 29 Fedora Update System 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.
Comment 30 Andy Wang 2012-06-18 10:02:48 EDT
This issue is definitely not fixed.  Can this bug be re-opened and looked at again?
Comment 31 Thorsten Leemhuis 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 32 Joel Uckelman 2012-06-18 13:13:26 EDT
If another bug is opened, please indicate its number here, so those of us following this bug who still have a problem can find it.
Comment 33 Andy Wang 2012-06-18 13:16:36 EDT
Cloned to bug 833117
Comment 34 Fedora Update System 2012-06-19 20:26:44 EDT
kernel-3.4.2-1.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 35 moondrake 2012-06-23 17:40:10 EDT
Problems persist, updated my fc16 machine today and unfortunately FC 16 now also suffers from a broken iwlwifi driver :(
Comment 36 tom.jenkinson 2012-06-25 17:21:37 EDT
Problems persist, 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 37 David Bosschaert 2012-06-30 05:25:20 EDT
Yes, I'm still seeing extremely flaky wifi connections too (Dell Latitude D820)

$ uname -r
3.4.3-1.fc17.i686

0c:00.0 Network controller: Broadcom Corporation BCM4311 802.11a/b/g (rev 01)
Comment 38 Peter Robinson 2012-06-30 08:21:36 EDT
> 0c:00.0 Network controller: Broadcom Corporation BCM4311 802.11a/b/g (rev 01)

David, this is a Broadcom, the bug report is about Intel Wireless networking. Wrong bug
Comment 39 Mladen Komac 2012-09-14 13:22:18 EDT
(In reply to comment #36)
> Problems persist, 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

Hi Tom,
I can confirm that, workaround is to restart Network Manager.
I am having that on HP EliteBook 8540w:

[root@guru4hp-fedora hpadmin]# ethtool -i wlan0
driver: iwlwifi
version: 3.3.4-5.fc17.x86_64
firmware-version: 9.221.4.1 build 25532
bus-info: 0000:44:00.0
supports-statistics: no
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no

[root@guru4hp-fedora hpadmin]# lspci | grep -i network
00:19.0 Ethernet controller: Intel Corporation 82577LM Gigabit Network Connection (rev 05)
44:00.0 Network controller: Intel Corporation Centrino Ultimate-N 6300 (rev 35)

I have found in post https://bugzilla.redhat.com/show_bug.cgi?id=785239 that it can be related to N standard, and that workaround can be to disabled N standard on card:

1.create a file called /etc/modprobe.d/iwlwifi.conf with a single line like this:

options iwlwifi 11n_disable=1

2. Reboot (or "modprobe -r iwlwifi ; modprobe iwlwifi" as root).

Same problem is on all RHEL  based distros: CentOS 6.3 (6.2 after update to latest version), Scientific Linux 6.3, Oracle Linux 6.3.... same card / same notebook.

BR. Mladen ...
Comment 40 Mladen Komac 2012-09-14 14:00:46 EDT
here are logs from Fedora 17:

Sep 14 19:56:54 guru4hp-fedora kernel: [ 3822.054135] iwlwifi 0000:44:00.0: Queue 2 stuck for 2000 ms.
Sep 14 19:56:54 guru4hp-fedora kernel: [ 3822.054141] iwlwifi 0000:44:00.0: Current SW read_ptr 104 write_ptr 110
Sep 14 19:56:54 guru4hp-fedora kernel: [ 3822.054171] iwlwifi 0000:44:00.0: Current HW read_ptr 104 write_ptr 110
Sep 14 19:56:54 guru4hp-fedora kernel: [ 3822.054174] iwlwifi 0000:44:00.0: On demand firmware reload
Sep 14 19:56:54 guru4hp-fedora kernel: [ 3822.054542] ieee80211 phy0: Hardware restart was requested
Sep 14 19:56:54 guru4hp-fedora kernel: [ 3822.054604] iwlwifi 0000:44:00.0: L1 Disabled; Enabling L0S
Sep 14 19:56:54 guru4hp-fedora kernel: [ 3822.061256] iwlwifi 0000:44:00.0: Radio type=0x0-0x3-0x1
Comment 41 Alexey Brodkin 2014-09-29 12:59:44 EDT
For me WiFi connection is very unstable in Fedora 20 64bit on HP 8560w even with the most recent kernel - 3.16.2-200.fc20.x86_64.

"11n_disable=1" made connection stable.

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