Bug 95901
| Summary: | iwlwifi: 7265: wireless performance unstable on Linux >= 3.19 | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Ryan Finnie (ryan) |
| Component: | network-wireless | Assignee: | drivers_network-wireless (drivers_network-wireless) |
| Status: | CLOSED INVALID | ||
| Severity: | normal | CC: | degts, enrico.tagliavini, greg.b.kernel, ilw, luca, ryan, seth, stefan.hoelldampf |
| Priority: | P1 | ||
| Hardware: | Intel | ||
| OS: | Linux | ||
| See Also: | https://bugzilla.kernel.org/show_bug.cgi?id=97291 | ||
| Kernel Version: | 4.0rc6 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: |
syslog output, including dmesg
syslog with wpa_supplicant -dd trace.dat on 4.0 |
||
|
Description
Ryan Finnie
2015-03-31 20:23:59 UTC
I can confirm I am occasionally experiencing this as well on a ThinkPad T450 running kernel 3.19. from lspci -nn: 03:00.0 Network controller [0280]: Intel Corporation Wireless 7265 [8086:095b] (rev 59) When I've encountered this problem, it appeared to be a transmitter lockup. If I was receiving a stream of data (in my case, an audio call over UDP), the RX stream would continue while TX was locked up. A running ping would eventually start reporting ENOBUFS. Sometimes the transmitter would recover after several seconds, but many times it would require forcing Linux to reassociate with the AP. The problem also appeared to be worsened by a noisy RF environment (e.g., other nearby very active access points), with TX lockups occurring as frequently as every few seconds. @Greg - this is most likely a different issue. Can you please attach your dmesg output to confirm? @Emmanuel - there was no dmesg output at all during the lockup. The first log message generated in /var/log/messages came from me manually disassocating the wifi, and the following messages after that came from me manually requesting wifi re-associate with the AP. I can send those messages if desired. I also commented on this issue downstream: https://bugzilla.redhat.com/show_bug.cgi?id=1202930 (see tail end of report for my comments). On the downstream report, I also included some information about a wifi problem I had twice on 3.18 which included a kernel WARNING and backtrace which could only be resolved by a reboot. I haven't had that happen again. I expect that's a different issue, but don't know. No dmesg output? No reassociation? No Tx queue stuck? I think that the WARNING you talked about has been fixed since then. Please make sure you work with the latest firmware (25.16.12.0). Nothing at all remarkable in dmesg; the only messages are due to disconnection/reassociation after I manually intervened. Here's the re-association *after* I manually disconnected and manually reassociated. The connection had been locked up for about three minutes before I disconnected and reassociated, and a running ping was returning ENOBUFS for most of that time. The driver and wifi subsystem apparently never realized there was a problem. Sometimes this will happen several times a minute, for several minutes on end, and other times it will go minutes or hours before it happens again. Kernel: Linux version 3.19.3-200.fc21.x86_64 (mockbuild@bkernel02.phx2.fedoraproject.org) (gcc version 4.9.2 20150212 (Red Hat 4.9.2-6) (GCC) ) #1 SMP Thu Mar 26 21:39:42 UTC 2015 Ping -n -D output: (ENETUNREACH messages below were due to me manually disconnecting/reassociating the wifi) [1428211160.121871] 64 bytes from x.x.x.x: icmp_seq=1188 ttl=64 time=4.77 ms [1428211161.121624] 64 bytes from x.x.x.x: icmp_seq=1189 ttl=64 time=2.52 ms [1428211162.122984] 64 bytes from x.x.x.x: icmp_seq=1190 ttl=64 time=2.12 ms ping: sendmsg: No buffer space available (ENOBUFS message repeated many times) ping: sendmsg: No buffer space available ping: sendmsg: No buffer space available ping: sendmsg: Network is unreachable ping: sendmsg: Network is unreachable ping: sendmsg: Network is unreachable [1428211382.910083] 64 bytes from x.x.x.x: icmp_seq=1391 ttl=64 time=765 ms [1428211383.983037] 64 bytes from x.x.x.x: icmp_seq=1392 ttl=64 time=837 ms [1428211385.163210] 64 bytes from x.x.x.x: icmp_seq=1393 ttl=64 time=1016 ms [1428211385.171305] 64 bytes from x.x.x.x: icmp_seq=1394 ttl=64 time=25.4 ms [1428211386.152963] 64 bytes from x.x.x.x: icmp_seq=1395 ttl=64 time=5.63 ms [1428211387.151779] 64 bytes from x.x.x.x: icmp_seq=1396 ttl=64 time=2.56 ms Dmesg snippet: [54388.592157] wlp3s0: deauthenticating from xx:xx:xx:xx:xx:xx by local choice (Reason: 3=DEAUTH_LEAVING) [54388.602390] cfg80211: Calling CRDA to update world regulatory domain [54388.616714] cfg80211: World regulatory domain updated: [54388.616718] cfg80211: DFS Master region: unset [54388.616719] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time) [54388.616722] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A) [54388.616724] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A) [54388.616726] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (N/A, 2000 mBm), (N/A) [54388.616728] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (N/A) [54388.616730] cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (0 s) [54388.616732] cfg80211: (5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A, 2000 mBm), (0 s) [54388.616734] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 2000 mBm), (N/A) [54388.616736] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0 mBm), (N/A) [54388.617377] cfg80211: Calling CRDA for country: US [54388.622191] cfg80211: Regulatory domain changed to country: US [54388.622194] cfg80211: DFS Master region: FCC [54388.622195] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time) [54388.622197] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 3000 mBm), (N/A) [54388.622198] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 1700 mBm), (N/A) [54388.622200] cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2300 mBm), (0 s) [54388.622201] cfg80211: (5490000 KHz - 5600000 KHz @ 80000 KHz), (N/A, 2300 mBm), (0 s) [54388.622202] cfg80211: (5650000 KHz - 5710000 KHz @ 40000 KHz), (N/A, 2300 mBm), (0 s) [54388.622203] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 3000 mBm), (N/A) [54388.622204] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 4000 mBm), (N/A) [54391.812924] wlp3s0: authenticate with xx:xx:xx:xx:xx:xx [54391.818065] wlp3s0: send auth to xx:xx:xx:xx:xx:xx (try 1/3) [54391.821645] wlp3s0: authenticated [54391.822681] wlp3s0: associate with xx:xx:xx:xx:xx:xx (try 1/3) [54391.826146] wlp3s0: RX AssocResp from xx:xx:xx:xx:xx:xx (capab=0x411 status=0 aid=5) [54391.827683] wlp3s0: associated good - please open a new bug. This is not related to this bug. @Ryan Finnie -- getting back to the original bug It's pretty strange that the deauth is happening exactly one minute after the connection completes. And this can only be coming from the userspace, since the kernel "deauthenticating by local choice" message can only be printed if the userspace requested it or if the system is suspending (the latter is not the case here). In order to try to get some more clues could you please do the following? 1. make sure there is only one wpa_supplicant instance running 2. run wpa_supplicant with debugging -- just add -dd to the command line options 3. collect ftrace logs (trace-cmd record -e iwlwifi -e iwlwifi_msg -e cfg80211 -e mac80211) 4. try to run 3.18 with iwlwifi-7265D-10.ucode renamed as iwlwifi-7265-10.ucode 5. if 4. works and the problem is not reproduced, you could bisect Sorry that we can't figure out anything more without extra information... Created attachment 173811 [details]
syslog with wpa_supplicant -dd
Created attachment 173821 [details]
trace.dat on 4.0
(In reply to Luca Coelho from comment #7) > It's pretty strange that the deauth is happening exactly one minute after > the connection completes. And this can only be coming from the userspace, > since the kernel "deauthenticating by local choice" message can only be > printed if the userspace requested it or if the system is suspending (the > latter is not the case here). And yet oddly userspace doesn't seem to know about the deauth until after the kernel event. I've uploaded a new full syslog with wpa_supplicant -dd, but here are the a lines when the 60 second interval happens: Apr 12 21:08:04 linda wpa_supplicant[2606]: EAPOL authentication completed - result=SUCCESS Apr 12 21:08:04 linda wpa_supplicant[2606]: RTM_NEWLINK: ifi_index=3 ifname=wlan0 operstate=6 linkmode=1 ifi_flags=0x11043 ([UP][RUNNING][LOWER_UP]) Apr 12 21:08:04 linda kernel: [ 1257.591077] wlan0: Limiting TX power to 30 (30 - 0) dBm as advertised by 38:2c:4a:5c:7f:e4 Apr 12 21:08:05 linda wpa_supplicant[2606]: EAPOL: startWhen --> 0 Apr 12 21:08:05 linda wpa_supplicant[2606]: EAPOL: disable timer tick Apr 12 21:09:04 linda kernel: [ 1317.514138] wlan0: deauthenticating from 38:2c:4a:5c:7f:e4 by local choice (Reason: 3=DEAUTH_LEAVING) Apr 12 21:09:04 linda wpa_supplicant[2606]: nl80211: Event message available Apr 12 21:09:04 linda wpa_supplicant[2606]: nl80211: Drv Event 20 (NL80211_CMD_DEL_STATION) received for wlan0 > In order to try to get some more clues could you please do the following? > > 1. make sure there is only one wpa_supplicant instance running Confirmed. Previously wpa_supplicant was managed by Ubuntu vivid via systemd/dbus/stuff (sorry, I'm not proficient with how the modern desktop works these days w/r/t networking). But I now have it set to not manage wlan0 and have configured wpa_supplicant manually to rule out the desktop environment (no change in behavior). > 2. run wpa_supplicant with debugging -- just add -dd to the command line > options Done, please see attached. > 3. collect ftrace logs (trace-cmd record -e iwlwifi -e iwlwifi_msg -e > cfg80211 -e mac80211) Done, please see attached. > 4. try to run 3.18 with iwlwifi-7265D-10.ucode renamed as > iwlwifi-7265-10.ucode iwlwifi on 3.18 doesn't seem to like that: [ 7.810688] Intel(R) Wireless WiFi driver for Linux, in-tree: [ 7.810691] Copyright(c) 2003- 2014 Intel Corporation [ 7.811625] iwlwifi 0000:03:00.0: irq 50 for MSI/MSI-X [ 7.823048] iwlwifi 0000:03:00.0: loaded firmware version 23.15.10.0 op_mode iwlmvm [ 7.860776] iwlwifi 0000:03:00.0: Detected Intel(R) Dual Band Wireless AC 7265, REV=0x210 [ 7.861123] iwlwifi 0000:03:00.0: L1 Enabled - LTR Enabled [ 7.861572] iwlwifi 0000:03:00.0: L1 Enabled - LTR Enabled [ 7.916535] cfg80211: World regulatory domain updated: [ 7.916539] cfg80211: DFS Master region: unset [ 7.916540] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time) [ 7.916543] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm), (N/A) [ 7.916545] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (300 mBi, 2000 mBm), (N/A) [ 7.916547] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm), (N/A) [ 7.916549] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm), (N/A) [ 7.916551] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm), (N/A) [ 8.866062] iwlwifi 0000:03:00.0: Failed to start INIT ucode: -110 [ 8.866455] iwlwifi 0000:03:00.0: Failed to run INIT ucode: -110 > 5. if 4. works and the problem is not reproduced, you could bisect > > > Sorry that we can't figure out anything more without extra information... No problem, thank you for your help. Please let me know if there's anything else I can do. (In reply to Ryan Finnie from comment #10) > (In reply to Luca Coelho from comment #7) > > It's pretty strange that the deauth is happening exactly one minute after > > the connection completes. And this can only be coming from the userspace, > > since the kernel "deauthenticating by local choice" message can only be > > printed if the userspace requested it or if the system is suspending (the > > latter is not the case here). > > And yet oddly userspace doesn't seem to know about the deauth until after > the kernel event. I've uploaded a new full syslog with wpa_supplicant -dd, > but here are the a lines when the 60 second interval happens: > > Apr 12 21:08:04 linda wpa_supplicant[2606]: EAPOL authentication completed - > result=SUCCESS > Apr 12 21:08:04 linda wpa_supplicant[2606]: RTM_NEWLINK: ifi_index=3 > ifname=wlan0 operstate=6 linkmode=1 ifi_flags=0x11043 > ([UP][RUNNING][LOWER_UP]) > Apr 12 21:08:04 linda kernel: [ 1257.591077] wlan0: Limiting TX power to 30 > (30 - 0) dBm as advertised by 38:2c:4a:5c:7f:e4 > Apr 12 21:08:05 linda wpa_supplicant[2606]: EAPOL: startWhen --> 0 > Apr 12 21:08:05 linda wpa_supplicant[2606]: EAPOL: disable timer tick > Apr 12 21:09:04 linda kernel: [ 1317.514138] wlan0: deauthenticating from > 38:2c:4a:5c:7f:e4 by local choice (Reason: 3=DEAUTH_LEAVING) > Apr 12 21:09:04 linda wpa_supplicant[2606]: nl80211: Event message available > Apr 12 21:09:04 linda wpa_supplicant[2606]: nl80211: Drv Event 20 > (NL80211_CMD_DEL_STATION) received for wlan0 Okay, sorry, this can also happen because of regulatory. I missed that. > > In order to try to get some more clues could you please do the following? > > > > 1. make sure there is only one wpa_supplicant instance running > > Confirmed. Previously wpa_supplicant was managed by Ubuntu vivid via > systemd/dbus/stuff (sorry, I'm not proficient with how the modern desktop > works these days w/r/t networking). But I now have it set to not manage > wlan0 and have configured wpa_supplicant manually to rule out the desktop > environment (no change in behavior). Good, this is necessary to rule out strange behavior caused by two instances competing for control. > > 2. run wpa_supplicant with debugging -- just add -dd to the command line > > options > > Done, please see attached. Can't see anything in wpa_supplicant triggering the deauth, so it is indeed kernel initiated. > > 3. collect ftrace logs (trace-cmd record -e iwlwifi -e iwlwifi_msg -e > > cfg80211 -e mac80211) > > Done, please see attached. Thanks, this was very useful! > > 4. try to run 3.18 with iwlwifi-7265D-10.ucode renamed as > > iwlwifi-7265-10.ucode > > iwlwifi on 3.18 doesn't seem to like that: > > [ 7.810688] Intel(R) Wireless WiFi driver for Linux, in-tree: > [ 7.810691] Copyright(c) 2003- 2014 Intel Corporation > [ 7.811625] iwlwifi 0000:03:00.0: irq 50 for MSI/MSI-X > [ 7.823048] iwlwifi 0000:03:00.0: loaded firmware version 23.15.10.0 > op_mode iwlmvm > [ 7.860776] iwlwifi 0000:03:00.0: Detected Intel(R) Dual Band Wireless AC > 7265, REV=0x210 > [ 7.861123] iwlwifi 0000:03:00.0: L1 Enabled - LTR Enabled > [ 7.861572] iwlwifi 0000:03:00.0: L1 Enabled - LTR Enabled > [ 7.916535] cfg80211: World regulatory domain updated: > [ 7.916539] cfg80211: DFS Master region: unset > [ 7.916540] cfg80211: (start_freq - end_freq @ bandwidth), > (max_antenna_gain, max_eirp), (dfs_cac_time) > [ 7.916543] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 > mBi, 2000 mBm), (N/A) > [ 7.916545] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (300 > mBi, 2000 mBm), (N/A) > [ 7.916547] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 > mBi, 2000 mBm), (N/A) > [ 7.916549] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 > mBi, 2000 mBm), (N/A) > [ 7.916551] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 > mBi, 2000 mBm), (N/A) > [ 8.866062] iwlwifi 0000:03:00.0: Failed to start INIT ucode: -110 > [ 8.866455] iwlwifi 0000:03:00.0: Failed to run INIT ucode: -110 Bummer, I thought that would have worked. :( > > 5. if 4. works and the problem is not reproduced, you could bisect > > > > > > Sorry that we can't figure out anything more without extra information... > > No problem, thank you for your help. Please let me know if there's anything > else I can do. So this really seems like a regulatory issue now. Channel 153 (5765) is not available everywhere so it could be that your NIC was purchased in a region where it is not supported (Europe, for instance)? I'll ask my colleague who knows a lot more about regulatory to see if he has any clues and what sort of data we may need. (In reply to Luca Coelho from comment #11) > So this really seems like a regulatory issue now. Channel 153 (5765) is not > available everywhere so it could be that your NIC was purchased in a region > where it is not supported (Europe, for instance)? > > I'll ask my colleague who knows a lot more about regulatory to see if he has > any clues and what sort of data we may need. Thanks. FWIW, this Thinkpad X250 was bought directly from Lenovo through their US store, for use in the US. The part number is 20CMCTO1WW and I assume the "WW" means worldwide, but I would assume (hope?) they would configure it with a wireless card sourced for use in the US. (In reply to Ryan Finnie from comment #12) > (In reply to Luca Coelho from comment #11) > > So this really seems like a regulatory issue now. Channel 153 (5765) is > not > > available everywhere so it could be that your NIC was purchased in a region > > where it is not supported (Europe, for instance)? > > > > I'll ask my colleague who knows a lot more about regulatory to see if he > has > > any clues and what sort of data we may need. > > Thanks. FWIW, this Thinkpad X250 was bought directly from Lenovo through > their US store, for use in the US. The part number is 20CMCTO1WW and I > assume the "WW" means worldwide, but I would assume (hope?) they would > configure it with a wireless card sourced for use in the US. Yeah, definitely looks to be regulatory. "iw reg set US" stops the deauths. I believe there's still an outstanding bug considering the range for channel 153 (5735000 KHz - 5835000 KHz @ 40000 KHz) is listed both for the default unset and for FCC: [ 12.500598] cfg80211: World regulatory domain updated: [ 12.500602] cfg80211: DFS Master region: unset [ 12.500603] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time) [ 12.500607] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm), (N/A) [ 12.500618] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (300 mBi, 2000 mBm), (N/A) [ 12.500620] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm), (N/A) [ 12.500622] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm), (N/A) [ 12.500624] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm), (N/A) [ 13.217842] cfg80211: Calling CRDA for country: US [ 13.220191] iwlwifi 0000:03:00.0: L1 Enabled - LTR Enabled [ 13.220647] iwlwifi 0000:03:00.0: L1 Enabled - LTR Enabled [ 13.241168] cfg80211: Regulatory domain changed to country: US [ 13.241173] cfg80211: DFS Master region: FCC [ 13.241174] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time) [ 13.241176] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm), (N/A) [ 13.241178] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm), (N/A) [ 13.241179] cfg80211: (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm), (0 s) [ 13.241181] cfg80211: (5490000 KHz - 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm), (0 s) [ 13.241182] cfg80211: (5650000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm), (0 s) [ 13.241183] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm), (N/A) [ 13.241185] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 4000 mBm), (N/A) [ 15.916175] wlan0: authenticate with 38:2c:4a:5c:7f:e4 [ 15.916183] wlan0: capabilities/regulatory prevented using AP HT/VHT configuration, downgraded [ 15.925062] wlan0: send auth to 38:2c:4a:5c:7f:e4 (try 1/3) [ 15.925796] wlan0: authenticated [ 15.928273] wlan0: associate with 38:2c:4a:5c:7f:e4 (try 1/3) [ 15.936807] wlan0: RX AssocResp from 38:2c:4a:5c:7f:e4 (capab=0x511 status=0 aid=54) [ 15.938792] wlan0: associated [ 15.938854] cfg80211: Calling CRDA for country: US [ 15.954889] wlan0: Limiting TX power to 30 (30 - 0) dBm as advertised by 38:2c:4a:5c:7f:e4 [ 15.972480] cfg80211: Regulatory domain changed to country: US [ 15.972483] cfg80211: DFS Master region: FCC [ 15.972485] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time) [ 15.972487] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm), (N/A) [ 15.972490] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm), (N/A) [ 15.972492] cfg80211: (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm), (0 s) [ 15.972493] cfg80211: (5490000 KHz - 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm), (0 s) [ 15.972495] cfg80211: (5650000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm), (0 s) [ 15.972497] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm), (N/A) [ 15.972499] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 4000 mBm), (N/A) [ 2238.567087] wlan0: Limiting TX power to 30 (30 - 0) dBm as advertised by 38:2c:4a:5c:7f:e4 Oh, good news if setting the reg to US manually works. :) We looked into this a bit further. There's a new patch in 3.19 that adds a check for regulatory validity after the connection has been established. This seems to be the code that is causing the deauth here. Another observation is that cfg80211 (as you posted above) is reporting (5735000 KHz - 5835000 KHz @ 40000 KHz), meaning 40MHz max should be used. But the association happens at 80MHz. This could be why it's disconnecting, but I'm not sure yet. Additionally, the upstream regdb says that 80MHz can be used in the US, so maybe you have an older version? In any case, there are a few more things you could try to log for us: 1) Can you take trace-cmd logs (same events as before) containing the time when you *load* the iwlwifi+iwlmvm modules? 2) Get the information that "iw list" returns, before and after the connection. 3) Can you enable the CONFIG_CFG80211_REG_DEBUG Kconfig option in your kernel? With this we can check what is changed from before and after the connection is established, as well as the information that is enforced in the firmware. (In reply to Luca Coelho from comment #14) > Oh, good news if setting the reg to US manually works. :) > > We looked into this a bit further. There's a new patch in 3.19 that adds a > check for regulatory validity after the connection has been established. > This seems to be the code that is causing the deauth here. > > Another observation is that cfg80211 (as you posted above) is reporting > (5735000 KHz - 5835000 KHz @ 40000 KHz), meaning 40MHz max should be used. > But the association happens at 80MHz. This could be why it's disconnecting, > but I'm not sure yet. Additionally, the upstream regdb says that 80MHz can > be used in the US, so maybe you have an older version? Yeah, that appears to be it. Ubuntu vivid currently has wireless-regdb 2013.02.13, which is ancient and predates 80MHz VHT updates. I'm currently working with the Ubuntu distro people[0] to try to get Debian sid's 2014.11.18 package (which is still a few releases behind vanilla, but much more modern) included with vivid before final freeze. With 2014.11.18 installed, it works as expected on 4.0 (and 3.19 which vivid is to be released with) without having to force "iw reg set US", and looks like it stops the world/US/world/US flip-flopping I saw before. [0] Full disclosure: I am a Canonical employee, but not a Ubuntu developer, so I don't have the authority to simply push an update. Looks like downstream maintenance of wireless-regdb got lost in the shuffle; see https://bugs.launchpad.net/ubuntu/+source/wireless-regdb/+bug/1284093 . > In any case, there are a few more things you could try to log for us: > > 1) Can you take trace-cmd logs (same events as before) containing the time > when you *load* the iwlwifi+iwlmvm modules? > > 2) Get the information that "iw list" returns, before and after the > connection. > > 3) Can you enable the CONFIG_CFG80211_REG_DEBUG Kconfig option in your > kernel? > > With this we can check what is changed from before and after the connection > is established, as well as the information that is enforced in the firmware. I will try to get this done tonight. Do you want me to try this with the old or the newer regdb? Cool. The regdb maintainer happens to be the wireless maintainer for Ubuntu and is CCed to this bug:-) Closing as the bug is not in the WiFi driver. |