Description of problem: After some time (usually around 30 seconds to a minute) Version-Release number of selected component (if applicable): kernel-3.19.1-200.fc21.x86_64 (works fine on kernel-3.18.9-200.fc21.x86_64) How reproducible: Each of three times I rebooted into 3.19.1, pings to my gateway stopped responding until I reconnected to the wireless network (nmcli con up id SSID). Steps to Reproduce: 1. Connect to network 2. Run ping $GATEWAY 3. Cause other network traffic Actual results: ping responses stop and no network traffic gets through Expected results: the network operates normally Additional info: This is a ThinkPad X250. $ lspci | grep Wireless 03:00.0 Network controller: Intel Corporation Wireless 7265 (rev 59) I'm currently at my parents' where this is happening on an 802.11g WPA network (no 5 GHz radio). On Thursday I can test this on other networks.
Is there anything in dmesg related to this?
I can confirm this with a new Thinkpad X1 on 3.19.1.201.fc21.x86_64, and like Ian I don't have problems on 3.18.9-200.fc21.x86_64. $ lspci | grep Wireless 04:00.0 Network controller: Intel Corporation Wireless 7265 (rev 59) After an OK wireless connection, within a minute I lose connectivity and it takes a couple of minutes to reconnect. dmesg reports the following: [ 4592.790135] cfg80211: Calling CRDA to update world regulatory domain [ 4592.794179] cfg80211: World regulatory domain updated: [ 4592.794182] cfg80211: DFS Master region: unset [ 4592.794183] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time) [ 4592.794185] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A) [ 4592.794187] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A) [ 4592.794188] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (N/A, 2000 mBm), (N/A) [ 4592.794189] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (N/A) [ 4592.794191] cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (0 s) [ 4592.794192] cfg80211: (5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A, 2000 mBm), (0 s) [ 4592.794193] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 2000 mBm), (N/A) [ 4592.794194] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0 mBm), (N/A) [ 4592.794206] cfg80211: Calling CRDA for country: US [ 4592.796311] cfg80211: Regulatory domain changed to country: US [ 4592.796313] cfg80211: DFS Master region: FCC [ 4592.796314] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time) [ 4592.796315] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 3000 mBm), (N/A) [ 4592.796317] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 1700 mBm), (N/A) [ 4592.796318] cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2300 mBm), (0 s) [ 4592.796319] cfg80211: (5490000 KHz - 5600000 KHz @ 80000 KHz), (N/A, 2300 mBm), (0 s) [ 4592.796320] cfg80211: (5650000 KHz - 5710000 KHz @ 40000 KHz), (N/A, 2300 mBm), (0 s) [ 4592.796321] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 3000 mBm), (N/A) [ 4592.796322] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 4000 mBm), (N/A) [ 4595.499407] wlp4s0: authenticate with **:**:**:**:**:** [ 4595.505953] wlp4s0: send auth to **:**:**:**:**:** (try 1/3) [ 4595.507857] wlp4s0: authenticated [ 4595.508509] wlp4s0: associate with **:**:**:**:**:** (try 1/3) [ 4595.511944] wlp4s0: RX AssocResp from **:**:**:**:**:** (capab=0x431 status=0 aid=3) [ 4595.515316] wlp4s0: associated [ 4595.515389] cfg80211: Calling CRDA for country: US [ 4595.518323] cfg80211: Regulatory domain changed to country: US [ 4595.518326] cfg80211: DFS Master region: FCC [ 4595.518327] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time) [ 4595.518329] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 3000 mBm), (N/A) [ 4595.518331] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 1700 mBm), (N/A) [ 4595.518332] cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2300 mBm), (0 s) [ 4595.518334] cfg80211: (5490000 KHz - 5600000 KHz @ 80000 KHz), (N/A, 2300 mBm), (0 s) [ 4595.518335] cfg80211: (5650000 KHz - 5710000 KHz @ 40000 KHz), (N/A, 2300 mBm), (0 s) [ 4595.518336] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 3000 mBm), (N/A) [ 4595.518337] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 4000 mBm), (N/A) [ 4821.630840] cfg80211: Calling CRDA to update world regulatory domain [ 4821.633362] cfg80211: World regulatory domain updated: [ 4821.633364] cfg80211: DFS Master region: unset [ 4821.633365] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time) [ 4821.633367] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A) [ 4821.633368] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A) [ 4821.633369] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (N/A, 2000 mBm), (N/A) [ 4821.633371] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (N/A) [ 4821.633372] cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (0 s) [ 4821.633373] cfg80211: (5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A, 2000 mBm), (0 s) [ 4821.633374] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 2000 mBm), (N/A) [ 4821.633375] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0 mBm), (N/A) [ 4821.633389] cfg80211: Calling CRDA for country: US [ 4821.635608] cfg80211: Regulatory domain changed to country: US [ 4821.635612] cfg80211: DFS Master region: FCC [ 4821.635613] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time) [ 4821.635615] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 3000 mBm), (N/A) [ 4821.635616] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 1700 mBm), (N/A) [ 4821.635618] cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2300 mBm), (0 s) [ 4821.635619] cfg80211: (5490000 KHz - 5600000 KHz @ 80000 KHz), (N/A, 2300 mBm), (0 s) [ 4821.635620] cfg80211: (5650000 KHz - 5710000 KHz @ 40000 KHz), (N/A, 2300 mBm), (0 s) [ 4821.635621] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 3000 mBm), (N/A) [ 4821.635622] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 4000 mBm), (N/A) [ 4824.348395] wlp4s0: authenticate with **:**:**:**:**:** [ 4824.354507] wlp4s0: send auth to **:**:**:**:**:** (try 1/3) [ 4824.356411] wlp4s0: authenticated [ 4824.357203] wlp4s0: associate with **:**:**:**:**:** (try 1/3) [ 4824.363494] wlp4s0: RX AssocResp from **:**:**:**:**:** (capab=0x431 status=0 aid=3) [ 4824.365322] wlp4s0: associated [ 4824.365395] cfg80211: Calling CRDA for country: US [ 4824.367282] cfg80211: Regulatory domain changed to country: US [ 4824.367285] cfg80211: DFS Master region: FCC [ 4824.367286] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time) [ 4824.367288] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 3000 mBm), (N/A) [ 4824.367289] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 1700 mBm), (N/A) [ 4824.367291] cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2300 mBm), (0 s) [ 4824.367292] cfg80211: (5490000 KHz - 5600000 KHz @ 80000 KHz), (N/A, 2300 mBm), (0 s) [ 4824.367293] cfg80211: (5650000 KHz - 5710000 KHz @ 40000 KHz), (N/A, 2300 mBm), (0 s) [ 4824.367294] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 3000 mBm), (N/A) [ 4824.367295] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 4000 mBm), (N/A)
Actually, I lied about 3.19.1.201.fc21.x86_64 being fine. I also get intermittent failures: [Mon Mar 23 23:47:55 2015] iwlwifi 0000:04:00.0: fail to flush all tx fifo queues Q 0 [Mon Mar 23 23:47:55 2015] iwlwifi 0000:04:00.0: Current SW read_ptr 179 write_ptr 184 [Mon Mar 23 23:47:55 2015] iwl data: 00000000: 00 00 00 00 00 00 00 00 00 00 f8 00 00 00 00 00 ................ [Mon Mar 23 23:47:55 2015] iwlwifi 0000:04:00.0: FH TRBs(0) = 0x80003080 [Mon Mar 23 23:47:55 2015] iwlwifi 0000:04:00.0: FH TRBs(1) = 0xc01100dc [Mon Mar 23 23:47:55 2015] iwlwifi 0000:04:00.0: FH TRBs(2) = 0x00000000 [Mon Mar 23 23:47:55 2015] iwlwifi 0000:04:00.0: FH TRBs(3) = 0x803000b7 [Mon Mar 23 23:47:55 2015] iwlwifi 0000:04:00.0: FH TRBs(4) = 0x00000000 [Mon Mar 23 23:47:55 2015] iwlwifi 0000:04:00.0: FH TRBs(5) = 0x00000000 [Mon Mar 23 23:47:55 2015] iwlwifi 0000:04:00.0: FH TRBs(6) = 0x00000000 [Mon Mar 23 23:47:55 2015] iwlwifi 0000:04:00.0: FH TRBs(7) = 0x007090b6 [Mon Mar 23 23:47:55 2015] iwlwifi 0000:04:00.0: Q 0 is active and mapped to fifo 3 ra_tid 0x0000 [179,184] [Mon Mar 23 23:47:55 2015] iwlwifi 0000:04:00.0: Q 1 is active and mapped to fifo 2 ra_tid 0x0000 [0,0] [Mon Mar 23 23:47:55 2015] iwlwifi 0000:04:00.0: Q 2 is active and mapped to fifo 1 ra_tid 0x0000 [163,163] [Mon Mar 23 23:47:55 2015] iwlwifi 0000:04:00.0: Q 3 is active and mapped to fifo 0 ra_tid 0x0000 [129,129] [Mon Mar 23 23:47:55 2015] iwlwifi 0000:04:00.0: Q 4 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0] [Mon Mar 23 23:47:55 2015] iwlwifi 0000:04:00.0: Q 5 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0] [Mon Mar 23 23:47:55 2015] iwlwifi 0000:04:00.0: Q 6 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0] [Mon Mar 23 23:47:55 2015] iwlwifi 0000:04:00.0: Q 7 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0] [Mon Mar 23 23:47:55 2015] iwlwifi 0000:04:00.0: Q 8 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0] [Mon Mar 23 23:47:55 2015] iwlwifi 0000:04:00.0: Q 9 is active and mapped to fifo 7 ra_tid 0x0000 [183,183] [Mon Mar 23 23:47:55 2015] iwlwifi 0000:04:00.0: Q 10 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0] [Mon Mar 23 23:47:55 2015] iwlwifi 0000:04:00.0: Q 11 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0] [Mon Mar 23 23:47:55 2015] iwlwifi 0000:04:00.0: Q 12 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0] [Mon Mar 23 23:47:55 2015] iwlwifi 0000:04:00.0: Q 13 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0] [Mon Mar 23 23:47:55 2015] iwlwifi 0000:04:00.0: Q 14 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0] [Mon Mar 23 23:47:55 2015] iwlwifi 0000:04:00.0: Q 15 is active and mapped to fifo 5 ra_tid 0x0000 [0,0] [Mon Mar 23 23:47:55 2015] iwlwifi 0000:04:00.0: Q 16 is active and mapped to fifo 1 ra_tid 0x0000 [205,173] [Mon Mar 23 23:47:55 2015] iwlwifi 0000:04:00.0: Q 17 is inactive and mapped to fifo 3 ra_tid 0x0006 [12,12] [Mon Mar 23 23:47:55 2015] iwlwifi 0000:04:00.0: Q 18 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0] [Mon Mar 23 23:47:55 2015] iwlwifi 0000:04:00.0: Q 19 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0] [Mon Mar 23 23:47:55 2015] cfg80211: Calling CRDA to update world regulatory domain [Mon Mar 23 23:47:55 2015] cfg80211: World regulatory domain updated: [Mon Mar 23 23:47:55 2015] cfg80211: DFS Master region: unset [Mon Mar 23 23:47:55 2015] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time) [Mon Mar 23 23:47:55 2015] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A) [Mon Mar 23 23:47:55 2015] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A) [Mon Mar 23 23:47:55 2015] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (N/A, 2000 mBm), (N/A) [Mon Mar 23 23:47:55 2015] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (N/A) [Mon Mar 23 23:47:55 2015] cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (0 s) [Mon Mar 23 23:47:55 2015] cfg80211: (5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A, 2000 mBm), (0 s) [Mon Mar 23 23:47:55 2015] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 2000 mBm), (N/A) [Mon Mar 23 23:47:55 2015] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0 mBm), (N/A) [Mon Mar 23 23:47:55 2015] cfg80211: Calling CRDA for country: US [Mon Mar 23 23:47:55 2015] cfg80211: Regulatory domain changed to country: US [Mon Mar 23 23:47:55 2015] cfg80211: DFS Master region: FCC [Mon Mar 23 23:47:55 2015] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time) [Mon Mar 23 23:47:55 2015] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 3000 mBm), (N/A) [Mon Mar 23 23:47:55 2015] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 1700 mBm), (N/A) [Mon Mar 23 23:47:55 2015] cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2300 mBm), (0 s) [Mon Mar 23 23:47:55 2015] cfg80211: (5490000 KHz - 5600000 KHz @ 80000 KHz), (N/A, 2300 mBm), (0 s) [Mon Mar 23 23:47:55 2015] cfg80211: (5650000 KHz - 5710000 KHz @ 40000 KHz), (N/A, 2300 mBm), (0 s) [Mon Mar 23 23:47:55 2015] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 3000 mBm), (N/A) [Mon Mar 23 23:47:55 2015] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 4000 mBm), (N/A) [Mon Mar 23 23:47:58 2015] wlp4s0: authenticate with **:**:**:**:**:** [Mon Mar 23 23:47:58 2015] wlp4s0: send auth to **:**:**:**:**:** (try 1/3) [Mon Mar 23 23:47:58 2015] wlp4s0: authenticated [Mon Mar 23 23:47:58 2015] wlp4s0: associate with **:**:**:**:**:** (try 1/3) [Mon Mar 23 23:47:58 2015] wlp4s0: RX AssocResp from **:**:**:**:**:** (capab=0x431 status=0 aid=3) [Mon Mar 23 23:47:58 2015] wlp4s0: associated [Mon Mar 23 23:47:58 2015] cfg80211: Calling CRDA for country: US [Mon Mar 23 23:47:58 2015] cfg80211: Regulatory domain changed to country: US [Mon Mar 23 23:47:58 2015] cfg80211: DFS Master region: FCC [Mon Mar 23 23:47:58 2015] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time) [Mon Mar 23 23:47:58 2015] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 3000 mBm), (N/A) [Mon Mar 23 23:47:58 2015] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 1700 mBm), (N/A) [Mon Mar 23 23:47:58 2015] cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2300 mBm), (0 s) [Mon Mar 23 23:47:58 2015] cfg80211: (5490000 KHz - 5600000 KHz @ 80000 KHz), (N/A, 2300 mBm), (0 s) [Mon Mar 23 23:47:58 2015] cfg80211: (5650000 KHz - 5710000 KHz @ 40000 KHz), (N/A, 2300 mBm), (0 s) [Mon Mar 23 23:47:58 2015] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 3000 mBm), (N/A) [Mon Mar 23 23:47:58 2015] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 4000 mBm), (N/A)
I have a similar problem on my Thinkpad T450 with this same card: 03:00.0 Network controller [0280]: Intel Corporation Wireless 7265 [8086:095b] (rev 59) WiFi will work for a "while" (minutes to hours), and then suddenly stop. Disconnecting from and reconnecting to the AP usually works, but no always. Versions: [ 17.474392] iwlwifi 0000:03:00.0: loaded firmware version 25.15.12.0 op_mode iwlmvm [ 17.597663] iwlwifi 0000:03:00.0: Detected Intel(R) Dual Band Wireless AC 7265, REV=0x210 Linux version 3.19.1-201.fc21.x86_64 (mockbuild.fedoraproject.org) (gcc version 4.9.2 20150212 (Red Hat 4.9.2-6) (GCC) ) #1 SMP Wed Mar 18 04:29:24 UTC 2015 Earlier today, before I updated to 3.19-1, I also had a kernel stack trace related to a WiFi lockup. This happened when I rebooted the AP I was connected to (wifi was working at the time); the AP came back online fine, but the wifi on my laptop crashed in the process: Mar 23 18:14:22 hostname kernel: [153401.840606] WARNING: CPU: 2 PID: 1135 at net/wireless/core.c:934 cfg80211_netdev_notifier_call+0x5c9/0x610 [cfg80211]() (I can attach the entire trace if desired). After that happened, I had to reboot the laptop; rmmodding/modprobing the iwl modules allowed AP scans to resume but reconnecting to an AP would not work.
Additional info: the wifi lockup appears to be a transmit condition, not a receive condition. Data continues to be received during the lockup, but not transmitted, and an ongoing ping will eventually report ENOBUFS during the lockup.
FYI I made a couple of comments regarding this issue upstream at: https://bugzilla.kernel.org/show_bug.cgi?id=95901 (seems similar to this issue.)
Can someone please remove my MAC address from my post please. I'm an idiot not clearing that out and can't find any edit.
Or if you can't edit just delete my comment completely please.
I have the same issue with 3.19.3-200
Same Problem here. WiFi stops working without apparent reason. No error messages whatsoever in any logs. Kernel 3.19.4-200.fc21.x86_64 Hardware: ThinkPad T450s with Intel Corporation Wireless 7265 (rev 59) Pinging an external IP while the wireless adapter is stuck results in: ping: sendmsg: No buffer space available My current workaround (not a very good one, but at least it allows me to get some data sent): while true; do iw dev wlp3s0 disconnect; sleep 30; done After disconnecting NetworkManager will automatically reconnect and the connection will work for a while. With some luck this does not even terminate existing IP connections, just causes bad lags on a regular basis... I'd gladly provide more details if you tell me which magic debug flags to set and where to look. Some connection details: # iw dev wlp3s0 link freq: 2462 signal: -45 dBm tx bitrate: 121.5 MBit/s MCS 6 40MHz bss flags: short-slot-time # iw dev wlp3s0 info type managed channel 11 (2462 MHz), width: 40 MHz, center1: 2452 MHz # iw reg get country DE: DFS-ETSI (2400 - 2483 @ 40), (N/A, 20) (5150 - 5250 @ 80), (N/A, 20), NO-OUTDOOR (5250 - 5350 @ 80), (N/A, 20), NO-OUTDOOR, DFS (5470 - 5725 @ 160), (N/A, 26), DFS (57000 - 66000 @ 2160), (N/A, 40) At home, where I have access to the router settings the problem seems to vanish (or at least to happen less frequently) when I change the router from 802.11b/g/n to 802.11b/g, i.e. by avoiding high throughput mode # iw dev wlp3s0 link freq: 2462 signal: -48 dBm tx bitrate: 54.0 MBit/s bss flags: short-slot-time # iw dev wlp3s0 info type managed channel 11 (2462 MHz), width: 20 MHz (no HT), center1: 2462 MHz Unfortunately I can not change the router settings at work and I did not find a way to deactivate HT on the client while in managed mode. E.g. the following approach to avoid using 2 channels / 40 MHz width failed: # iw dev wlp3s0 set channel 11 HT20 command failed: Device or resource busy (-16) If there are any suggestions on how to restrict the wireless adapter to 20 MHz width I can retest at home in 802.11b/g/n mode and check if it really reduces the problems.
You could be on to something. I changed my AP to be 20Mhz width and have not had a lockup/dropout once.
cfg80211_disable_40mhz_24ghz module parameter if you are on 2.4GHz You can try a newer firmware from: https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/linux-firmware.git/
Tanks a lot! I created the file /etc/modprobe.d/iwNoHt.conf with content ===== # disable high throughput mode for buggy wireless adapter options cfg80211 cfg80211_disable_40mhz_24ghz ===== and haven't had another lockup since, even though my AP is back in 802.11b/g/n mode and the wireless adapter obviously uses the n mode, as it is connected with 72 Mbit/s instead of the 54 Mbits/s available in g. A much better workaround than regular reconnects ;-) Tonight I'll give the new firmware a try and will report back as soon as I finished testing. If the new firmware also happens to lock up, are there any debug flags or magic keys to get some thread-dump-like output so I might get a clue where the adapter gets stuck?
Ok I am not surprised. Let me know what happens with the new firmware, although I am pretty sure it'll be the same. What I will need then is to collect firmware logs to open an internal bug the firmware team despite the fact that are overwhelmed lately...
to RH folks: please ensure that this bug stays on the same subject: disconnections on 40Mhz whereas it works on 20Mhz. The device here doesn't really matter as long as it is iwlmvm based. This kind of bugs tend to get an aggregation of a whole bunch of different issues that make it harder to track. Daniel, I'd appreciate if you could open a bug in bugzilla.kernel.org. It'll make it easier for me to track. After all, this bug is an Intel WiFi firmware bug and is not related to RH.
I forgot to say: whoever opens a bug on bugzilla.kernel.org should CC ilw.com to the bug.
If this is firmware bug, why things work on 3.18 kernel (according to comment 0), driver load older firmware version on that kernel ?
(In reply to Stanislaw Gruszka from comment #18) > If this is firmware bug, why things work on 3.18 kernel (according to > comment 0), driver load older firmware version on that kernel ? I am not sure that what Daniel said (works on 20Mhz) is true for the original submitter. But what Daniel said is the most precise data I have to can give a lead and this is why I am focusing on that. As you know, there are many different reasons that could lead to issues in wireless... In any case, I opened a bug on the firmware team (internal ticket MWG100234515) on that very specific scenario: doesn't work on 40Mhz, but works on 20Mhz.
As one of the prior commenters on this, I can confirm that in my case the problem occurs in HT20 also (at least, I know the AP's were on HT20 only; I did not force the iwl driver itself to HT20). Other than that, I have the same symptoms (random TX lockup without log messages, ENOBUFS messages from ping, etc.) I'll submit the possibility here that this bug is worsened by, but not caused by, HT40 due only to the increased interference; in my case it appeared that interference increased the frequency of TX lockups, sometimes significantly so. I'll continue to lurk on this bug report, realizing that it might no longer represent the bug I am experiencing.
I was wrong the 20Mhz wide change did not resolve the issue. I did get another drop but it happened much less frequently. So in frustration I upgraded to Fedora 22 (Kernel 4.0.0-1) and the issue is still there. [root@t450s ~]# uname -a Linux t450s 4.0.0-1.fc22.x86_64 #1 SMP Mon Apr 13 10:03:33 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux This is the results of the AP that works flawlessly for days [root@t450s ~]# iw dev wlp3s0 link Connected to **:**:**:**:**:** (on wlp3s0) SSID: ************ freq: 2442 RX: 19862616 bytes (92831 packets) TX: 9670526 bytes (64133 packets) signal: -61 dBm tx bitrate: 39.0 MBit/s MCS 4 bss flags: short-preamble short-slot-time dtim period: 1 beacon int: 100 [root@t450s ~]# iw dev wlp3s0 info Interface wlp3s0 ifindex 3 wdev 0x1 addr **:**:**:**:**:** type managed wiphy 0 channel 7 (2442 MHz), width: 20 MHz, center1: 2442 MHz [root@t450s ~]# iw reg get country AU: DFS-UNSET (2402 - 2482 @ 40), (N/A, 20), (N/A) (5170 - 5250 @ 80), (N/A, 17), (N/A) (5250 - 5330 @ 80), (N/A, 24), (0 ms), DFS (5490 - 5710 @ 160), (N/A, 24), (0 ms), DFS (5735 - 5835 @ 80), (N/A, 30), (N/A) This is the results of the AP that drops connections intermittently. [root@t450s ~]# iw dev wlp3s0 link Connected to **:**:**:**:**:** (on wlp3s0) SSID: *********** freq: 2462 RX: 50247 bytes (194 packets) TX: 23185 bytes (160 packets) signal: -52 dBm tx bitrate: 144.4 MBit/s MCS 15 short GI bss flags: short-preamble short-slot-time dtim period: 1 beacon int: 100 [root@t450s ~]# iw dev wlp3s0 info Interface wlp3s0 ifindex 3 wdev 0x1 addr **:**:**:**:**:** type managed wiphy 0 channel 11 (2462 MHz), width: 20 MHz, center1: 2462 MHz [root@t450s ~]# iw reg get country AU: DFS-UNSET (2402 - 2482 @ 40), (N/A, 20), (N/A) (5170 - 5250 @ 80), (N/A, 17), (N/A) (5250 - 5330 @ 80), (N/A, 24), (0 ms), DFS (5490 - 5710 @ 160), (N/A, 24), (0 ms), DFS (5735 - 5835 @ 80), (N/A, 30), (N/A) Happy to run any other tests if someone wants?
please use the firmware I pointed to above and attach your dmesg output.
Once I'll have the dmesg output, I'll know if I need to collect firmware logs from you. I'll need to send you a special firmware for that.
Apologies but I don't know how to change the firmware.
nothing to need to apology for :) Just copy iwlwifi-726X-12.ucode to /lib/firmware. X can be 0 or 5 depending on the device you have. Then you need to reload the driver. The easiest is just to reboot.
Based on these filesizes it looks like I have the same set of firmwares [root@t450s linux-firmware]# ls -al /root/installers/linux-firmware/iwlwifi-726* -rw-r--r-- 1 root root 672352 Apr 28 19:30 /root/installers/linux-firmware/iwlwifi-7260-10.ucode -rw-r--r-- 1 root root 782300 Apr 28 19:30 /root/installers/linux-firmware/iwlwifi-7260-12.ucode -rw-r--r-- 1 root root 683236 Apr 28 19:30 /root/installers/linux-firmware/iwlwifi-7260-7.ucode -rw-r--r-- 1 root root 679780 Apr 28 19:30 /root/installers/linux-firmware/iwlwifi-7260-8.ucode -rw-r--r-- 1 root root 680508 Apr 28 19:30 /root/installers/linux-firmware/iwlwifi-7260-9.ucode -rw-r--r-- 1 root root 736844 Apr 28 19:30 /root/installers/linux-firmware/iwlwifi-7265-10.ucode -rw-r--r-- 1 root root 880604 Apr 28 19:30 /root/installers/linux-firmware/iwlwifi-7265-12.ucode -rw-r--r-- 1 root root 690452 Apr 28 19:30 /root/installers/linux-firmware/iwlwifi-7265-8.ucode -rw-r--r-- 1 root root 697828 Apr 28 19:30 /root/installers/linux-firmware/iwlwifi-7265-9.ucode -rw-r--r-- 1 root root 740436 Apr 28 19:30 /root/installers/linux-firmware/iwlwifi-7265D-10.ucode -rw-r--r-- 1 root root 1002800 Apr 28 19:30 /root/installers/linux-firmware/iwlwifi-7265D-12.ucode [root@t450s linux-firmware]# ls -al /lib/firmware/iwlwifi-726* -rw-r--r--. 1 root root 672352 Apr 15 00:59 /lib/firmware/iwlwifi-7260-10.ucode -rw-r--r--. 1 root root 782300 Apr 15 00:59 /lib/firmware/iwlwifi-7260-12.ucode -rw-r--r--. 1 root root 683236 Apr 15 00:59 /lib/firmware/iwlwifi-7260-7.ucode -rw-r--r--. 1 root root 679780 Apr 15 00:59 /lib/firmware/iwlwifi-7260-8.ucode -rw-r--r--. 1 root root 680508 Apr 15 00:59 /lib/firmware/iwlwifi-7260-9.ucode -rw-r--r--. 1 root root 736844 Apr 15 00:59 /lib/firmware/iwlwifi-7265-10.ucode -rw-r--r--. 1 root root 880604 Apr 15 00:59 /lib/firmware/iwlwifi-7265-12.ucode -rw-r--r--. 1 root root 690452 Apr 15 00:59 /lib/firmware/iwlwifi-7265-8.ucode -rw-r--r--. 1 root root 697828 Apr 15 00:59 /lib/firmware/iwlwifi-7265-9.ucode -rw-r--r--. 1 root root 740436 Apr 15 00:59 /lib/firmware/iwlwifi-7265D-10.ucode -rw-r--r--. 1 root root 1002800 Apr 15 00:59 /lib/firmware/iwlwifi-7265D-12.ucode
I doubt it. 25.17.12.0 is not in upstream's linux-firwamre.git yet.
You were correct :) Before update [root@t450s linux-firmware]# /sbin/ethtool -i wlp3s0 driver: iwlwifi version: 4.0.0-1.fc22.x86_64 firmware-version: 25.15.12.0 bus-info: 0000:03:00.0 supports-statistics: yes supports-test: no supports-eeprom-access: no supports-register-dump: no supports-priv-flags: no Backed them up first [root@t450s linux-firmware]# cp /lib/firmware/iwlwifi-726* /root/installers/old-firmwares Copied them across then rebooted [root@t450s linux-firmware]# cp /root/installers/linux-firmware/iwlwifi-726* /lib/firmware/ cp: overwrite ‘/lib/firmware/iwlwifi-7260-10.ucode’? y cp: overwrite ‘/lib/firmware/iwlwifi-7260-12.ucode’? y cp: overwrite ‘/lib/firmware/iwlwifi-7260-7.ucode’? y cp: overwrite ‘/lib/firmware/iwlwifi-7260-8.ucode’? y cp: overwrite ‘/lib/firmware/iwlwifi-7260-9.ucode’? y cp: overwrite ‘/lib/firmware/iwlwifi-7265-10.ucode’? y cp: overwrite ‘/lib/firmware/iwlwifi-7265-12.ucode’? y cp: overwrite ‘/lib/firmware/iwlwifi-7265-8.ucode’? y cp: overwrite ‘/lib/firmware/iwlwifi-7265-9.ucode’? y cp: overwrite ‘/lib/firmware/iwlwifi-7265D-10.ucode’? y cp: overwrite ‘/lib/firmware/iwlwifi-7265D-12.ucode’? y After reboot [root@t450s ~]# /sbin/ethtool -i wlp3s0 driver: iwlwifi version: 4.0.0-1.fc22.x86_64 firmware-version: 25.17.12.0 bus-info: 0000:03:00.0 supports-statistics: yes supports-test: no supports-eeprom-access: no supports-register-dump: no supports-priv-flags: no Will post a dmesg if it drops again
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 21 kernel bugs. Fedora 21 has now been rebased to 3.19.5-200.fc21. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 22, and are still experiencing this issue, please change the version to Fedora 22. If you experience different issues, please open a new bug report for those.
the bug still exists in 3.19.5-200.fc21.x86_64 I didn't manage to try the new firmware yet, but I did some more testing. Unfortunately I can confirm that the problem also happens on 20 MHz bandwidth. Either it was a coincidence that it worked better on 20 MHz before or may be slowing down the adapter reduced the chance of the adapter getting stuck. Anyhow, today I observed the bug while on 802.11n with 20 MHz width and also on 802.11g. After some more testing it seems that the problem triggers more often when there is a lot of wireless traffic in the same network. I.e. when I stream a movie on another device the connection on the ThinkPad brakes down more often. Btw, I didn't want to hijack this bug report and in fact I still think that the problem I see is the same problem as described initially.
ok thanks. I'd need to have firmware logs then. For that, I need to get back to you with a custom firmware.
BTW - Daniel, can you please attach the dmesg output of when the problem occurs? thanks.
In order to confirm the initial bug report I just did a series of tests with the 3.17.4-301.fc21.x86_64 kernel from the initial Fedora 21 repo and the current 3.19.5-200.fc21.x86_64 kernel from the update repo. While I could reproduce the problem very reliably with the recent kernel I did not see any lock ups on the 3.17 one. I did not change the firmware in /lib/firmware/iwlwifi-7265*, just booted another kernel. Therefore, I think it's not a firmware bug after all but a kernel/module problem. I'll reboot into the 3.19 kernel now to collect some dmesg for you now, but you should not expect too much; there is nothing in there...
this is the output just before the wireless adapter gets stuck ============================================================== [ 33.360921] wlp3s0: authenticate with **:**:**:**:**:** [ 33.370131] wlp3s0: send auth to **:**:**:**:**:** (try 1/3) [ 33.373107] wlp3s0: authenticated [ 33.373801] wlp3s0: associate with **:**:**:**:**:** (try 1/3) [ 33.378697] wlp3s0: RX AssocResp from **:**:**:**:**:** (capab=0x411 status=0 aid=1) [ 33.392355] wlp3s0: associated [ 33.392406] cfg80211: Calling CRDA for country: DE [ 33.397599] cfg80211: Regulatory domain changed to country: DE [ 33.397604] cfg80211: DFS Master region: ETSI [ 33.397605] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time) [ 33.397607] cfg80211: (2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A) [ 33.397609] cfg80211: (5150000 KHz - 5250000 KHz @ 80000 KHz, 200000 KHz AUTO), (N/A, 2000 mBm), (N/A) [ 33.397610] cfg80211: (5250000 KHz - 5350000 KHz @ 80000 KHz, 200000 KHz AUTO), (N/A, 2000 mBm), (0 s) [ 33.397611] cfg80211: (5470000 KHz - 5725000 KHz @ 160000 KHz), (N/A, 2698 mBm), (0 s) [ 33.397612] cfg80211: (57000000 KHz - 66000000 KHz @ 2160000 KHz), (N/A, 4000 mBm), (N/A) [ 43.688142] Adjusting tsc more than 11% (5419111 vs 7179164) ============================================================== Now I create some traffic on the adapter and some more traffic on the network using other devices. After the ping to my local router changes from ============================================================== 64 bytes from 192.168.64.1: icmp_seq=60 ttl=64 time=1.21 ms ============================================================== to ============================================================== ping: sendmsg: No buffer space available ============================================================== I wait some time to make sure all relevant messages get a chance to appear in dmesg. After some time I run ============================================================== iw dev wlp3s0 disconnect ============================================================== to force a reconnect. This is all the dmesg output up to the reconnect: ============================================================== [ 33.360921] wlp3s0: authenticate with **:**:**:**:**:** [ 33.370131] wlp3s0: send auth to **:**:**:**:**:** (try 1/3) [ 33.373107] wlp3s0: authenticated [ 33.373801] wlp3s0: associate with **:**:**:**:**:** (try 1/3) [ 33.378697] wlp3s0: RX AssocResp from **:**:**:**:**:** (capab=0x411 status=0 aid=1) [ 33.392355] wlp3s0: associated [ 33.392406] cfg80211: Calling CRDA for country: DE [ 33.397599] cfg80211: Regulatory domain changed to country: DE [ 33.397604] cfg80211: DFS Master region: ETSI [ 33.397605] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time) [ 33.397607] cfg80211: (2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A) [ 33.397609] cfg80211: (5150000 KHz - 5250000 KHz @ 80000 KHz, 200000 KHz AUTO), (N/A, 2000 mBm), (N/A) [ 33.397610] cfg80211: (5250000 KHz - 5350000 KHz @ 80000 KHz, 200000 KHz AUTO), (N/A, 2000 mBm), (0 s) [ 33.397611] cfg80211: (5470000 KHz - 5725000 KHz @ 160000 KHz), (N/A, 2698 mBm), (0 s) [ 33.397612] cfg80211: (57000000 KHz - 66000000 KHz @ 2160000 KHz), (N/A, 4000 mBm), (N/A) [ 43.688142] Adjusting tsc more than 11% (5419111 vs 7179164) [ 195.265490] usb 1-6: reset full-speed USB device number 3 using xhci_hcd [ 195.430335] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep **************** [ 195.430339] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep **************** [ 195.430341] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep **************** [ 195.430342] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep **************** [ 206.932144] wlp3s0: deauthenticating from **:**:**:**:**:** by local choice (Reason: 3=DEAUTH_LEAVING) [ 206.951663] cfg80211: Calling CRDA to update world regulatory domain [ 206.958845] cfg80211: World regulatory domain updated: [ 206.958848] cfg80211: DFS Master region: unset [ 206.958850] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time) [ 206.958851] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A) [ 206.958852] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A) [ 206.958853] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (N/A, 2000 mBm), (N/A) [ 206.958854] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (N/A) [ 206.958856] cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (0 s) [ 206.958857] cfg80211: (5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A, 2000 mBm), (0 s) [ 206.958858] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 2000 mBm), (N/A) [ 206.958859] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0 mBm), (N/A) [ 206.958873] cfg80211: Calling CRDA for country: DE [ 206.961170] cfg80211: Regulatory domain changed to country: DE [ 206.961172] cfg80211: DFS Master region: ETSI [ 206.961174] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time) [ 206.961175] cfg80211: (2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A) [ 206.961176] cfg80211: (5150000 KHz - 5250000 KHz @ 80000 KHz, 200000 KHz AUTO), (N/A, 2000 mBm), (N/A) [ 206.961178] cfg80211: (5250000 KHz - 5350000 KHz @ 80000 KHz, 200000 KHz AUTO), (N/A, 2000 mBm), (0 s) [ 206.961179] cfg80211: (5470000 KHz - 5725000 KHz @ 160000 KHz), (N/A, 2698 mBm), (0 s) [ 206.961180] cfg80211: (57000000 KHz - 66000000 KHz @ 2160000 KHz), (N/A, 4000 mBm), (N/A) [ 209.793344] wlp3s0: authenticate with **:**:**:**:**:** [ 209.799563] wlp3s0: send auth to **:**:**:**:**:** (try 1/3) [ 209.806769] wlp3s0: authenticated [ 209.807078] wlp3s0: associate with **:**:**:**:**:** (try 1/3) [ 209.814046] wlp3s0: RX AssocResp from **:**:**:**:**:** (capab=0x411 status=0 aid=1) [ 209.817678] wlp3s0: associated [ 209.817726] cfg80211: Calling CRDA for country: DE [ 209.819457] cfg80211: Regulatory domain changed to country: DE [ 209.819459] cfg80211: DFS Master region: ETSI [ 209.819460] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time) [ 209.819462] cfg80211: (2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A) [ 209.819463] cfg80211: (5150000 KHz - 5250000 KHz @ 80000 KHz, 200000 KHz AUTO), (N/A, 2000 mBm), (N/A) [ 209.819464] cfg80211: (5250000 KHz - 5350000 KHz @ 80000 KHz, 200000 KHz AUTO), (N/A, 2000 mBm), (0 s) [ 209.819465] cfg80211: (5470000 KHz - 5725000 KHz @ 160000 KHz), (N/A, 2698 mBm), (0 s) [ 209.819466] cfg80211: (57000000 KHz - 66000000 KHz @ 2160000 KHz), (N/A, 4000 mBm), (N/A) ============================================================== so there is no wireless related output until I force the device to reconnect.
OK did not get any dropouts with new firmware with AP set to 20Mhz on Fedora 22 overnight. I have now switched AP back to 40MHz and will report back if this has any issues. May be switching back to Fedora 21 today as well because I can't get half of the apps I need due to no rpm-fusion available for Fedora 22. So will likely test Fedora 21 as well with new firmware and kernel.
@All to avoid further confusion, please note that different kernels may load different firmware versions. To check the firmware version: /sbin/ethtool -i <iface_name> | grep firmware If you see something that is not: 25.17.12.0 please don't report any issues but install the firmware from https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/linux-firmware.git/ and re-test. Many highly visible issues were fixed in 25.17.12.0. Don't rely on sizes, there's a version number for a reason. Please don't waste my time. Note that: -10.ucode's latest version is 23.15.10.0 -12.ucode's latest version is 25.17.12.0 When you reboot, check the firmware version being loaded. *ALWAYS* mention what firmware version you were using in your report whether you want to say that you don't see the bug anymore or you want to report the issue is (still) there. Another point. The driver (kernel) knows how to handle old firmwares. So that if you want to compare -10.ucode and -12.ucode without changing the driver, you can just remove (or rename) the -12.ucode and -10.ucode will be loaded. Here is the mapping between kernels and firmware versions: 3.17 will load -10.ucode (23.15.10.0). 3.18 will load -10.ucode (23.15.10.0). 3.19 will load -12.ucode (25.17.12.0) and fallback to -10.ucode All these kernels can fallback to -9.ucode. I would be very grateful if you follow these guidelines. We have 16 followers on this bug and that creates quite a bit of confusion. Thank you.
Firmware 25.17.12.0 has been stable for me today.
Wifi has been totally stable today on AP with 40Mhz, Kernel 4.0.0-1, firmware 25.17.12.0. Seems like the firmware update fixed it perfectly. Thanks Emmanuel for the suggestion and assist. [root@t450s Downloads]# uname -a Linux t450s 4.0.0-1.fc22.x86_64 #1 SMP Mon Apr 13 10:03:33 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux [root@t450s Downloads]# iw dev wlp3s0 info Interface wlp3s0 ifindex 3 wdev 0x1 addr **:**:**:**:**:** type managed wiphy 0 channel 11 (2462 MHz), width: 40 MHz, center1: 2452 MHz [root@t450s Downloads]# /sbin/ethtool -i wlp3s0 driver: iwlwifi version: 4.0.0-1.fc22.x86_64 firmware-version: 25.17.12.0 bus-info: 0000:03:00.0 supports-statistics: yes supports-test: no supports-eeprom-access: no supports-register-dump: no supports-priv-flags: no
ok - I guess that this is encouraging. I will wait a bit more for another bugfix from the firmware team. If it is not here tonight, I won't wait anymore and send a pull request to linux-firmware.git so that RH folks will be able to take the fixed firmware and release it.
I can also confirm that the problem seems to be fixed with firmware 25.17.12.0. Thanks a lot for your help! Sorry for the confusion I caused before, but it was not easy to reliably reproduce the problem. I stress tested the new firmware with lots of local traffic and lots of additional traffic from other devices on the same AP. No problems so far, while with the previous firmware the connection was blocked after a few seconds under these conditions.
*** Bug 1215848 has been marked as a duplicate of this bug. ***
Firmware 25.17.12.0 is still unstable for me with kernel 3.19.3-200.fc21.x86_64. However 25.222.9.0 which fallsback to -9.ucode is very stable. When using 25.17.12.0 I experienced a drop after 4 hours of continuous use. 25.222.9.0 was previously stable for several days after downgrading from 25.15.12.0 which was unstable. 25.15.12.0 -> unstable 25.22.9.0 -> stable 25.17.12.0 -> unstable
any dmesg output with 25.17.12.0?
bmagis please open different bug report for your issue as it seems not be related with problem originally reported hare and provide dmesg there.
I just had a wifi lockup on 25.17.12.0 this evening with the same symptoms as before (nothing in dmesg prior to manually disconnecting and reconnecting the wifi). However, I can definitely say that the new firmware has significantly improved stability. I did not verify the presence ENOBUFS symptom and the TX-lockup (RX still functions) symptom this time, so it's possible this may be a separate issue unrelated to this bug ID. I'll report back if this happens again.
A new fix has been introduced in the firmware: nks. https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/linux-firmware.git/plain/iwlwifi-7260-12.ucode I'd be grateful if you could give it a try. Thanks.
Thanks Emmanuel, I'll try that. It took a week to notice a failure, so this one probably won't be as easy to call "fixed" as the original bug here. I had a second incident of this yesterday, and was able to verify that it is a TX lockup, consistent with the far more frequent issue I was having a week ago, as I was able to tcpdump and receive packets. I did not have a running ping going at the time, so I did not see an ENOBUFS error. driver: iwlwifi version: 3.19.5-200.fc21.x86_64 firmware-version: 25.17.12.0 bus-info: 0000:03:00.0 I'll download the newer firmware and give it a try.
Emmanuel, Kernel git is showing a new commit on May 3rd for these firmware files and for WHENCE, but the 7260/7265/7265D -12 firmware files are the same 25.17.12.0 files (same size and md5) that I downloaded a week ago on April 28th (see my previous posts on this bug ID). Are there files somewhere that I'm overlooking? It looks like git merge magic (or rebasing perhaps?) is making these files appear updated on May 3rd when the update really happened well before that.
Yes. What happened is that other users quickly tested it and reported that it doens't work, so I removed it from git. No need for you to test it. Sorry.
25.17.12.0 has been merged into linux-firmware.git I'd appreciate if RH could roll it out ASAP. Thanks.
From what I am seeing, the issue is now fixed and we just need RH to roll out the fix. Removing Intel from this bug.
@Cameron, I made your comment 7 private so your MAC address is hidden.
Same issue here with X1 Carbon, Intel 7265. Dropping [1] in /lib/firmware and rebooting made the card usable. [1] https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/linux-firmware.git/plain/iwlwifi-7265-13.ucode?id=0410f246bbc7577dda2873da34cf1c2950414a3e
Clarification -- I'm still seeing drops, but the card is way more usable with iwlwifi-7265-13.ucode. Certainly still has problems, though.
I'm building updated firmware packages today. Testing the linux-firmware-20150521 update when it is filed would be a good idea.
@Josh, where can I grab the firmware package?
(In reply to Greg Sheremeta from comment #56) > @Josh, where can I grab the firmware package? http://koji.fedoraproject.org/koji/taskinfo?taskID=9817529 when it finishes building. Or you can wait for an update to be filed in bodhi.
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.