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.
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
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.
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. ;)
wd_disable=1 doesn't seem to help any.
I can confirm that i'm also having this issue and my access point in not wireless-n
> [ 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
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
(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)
03:00.0 Network controller: Intel Corporation Centrino Advanced-N 6205 (rev 34)
(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.
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
(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(¹)
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.
Are there easy commands I can run to try it out as well?
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.
(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.
Applied to rawhide and F17.
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
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.
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.
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 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
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
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
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
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).
$ 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.
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).
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.
This issue is definitely not fixed. Can this bug be re-opened and looked at again?
(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.
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.
Cloned to bug 833117
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.
Problems persist, updated my fc16 machine today and unfortunately FC 16 now also suffers from a broken iwlwifi driver :(
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
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)
> 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
(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 ...
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
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.