Created attachment 192961 [details] dmesg 802.11n connection becomes extremely unreliable with iwlwifi driver on Intel Wireless 7260 when not in direct line of sight of the router. Disabling 802.11n by adding 11n_disable=1 module parameter and running 802.11g instead makes the connection perfectly stable. I tried various permutations of 11n_disable=N, swcrypto=1, and different 802.11n settings on the router, and did not observe any noticeable difference. Neither did any firmware from iwlwifi-7260-14 to 17 make any difference. The last more or less usable configuration for me is kernel 4.2 with iwlwifi-7260-12 firmware. It was not stable either, but less so. Please say if you need more information.
Created attachment 192971 [details] lspci
Created attachment 192981 [details] ethtool
Created attachment 192991 [details] Core14 FW with uSniffer Please reproduce with the firmware attached. Please run with fw_restart=0 This means that we won't recover after the first failure. This will allow me to correlate between the different logs. 1) Tracing 2) The dump file that will be created when the FW crashes Information on how to collect this is available here: https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi/debugging please read the note about privacy. Can you please try to disable bluetooth and say if it helps? Thank you.
Created attachment 193021 [details] trace
Created attachment 193031 [details] coredump
I attached the trace and the dump. Turning Bluetooth off in the GNOME settings makes no difference. Unless you mean something more specific I should do here?
Created attachment 193041 [details] dmesg-iwlwifi-17
Can you please try to disable power save and report back? sudo iw wlan0 set power_save off If that works, I'd like to collect fw dump with a different firmware to get more logs. Let me know. thanks.
I think it is off by default, so no difference. See dmesg. I don't know if this is in any way relevant, but it seems I can trigger the crash quite reliably by placing the laptop in a certain point in the room, and holding it sideways. I am pretty sure I am not imagining this. It also seems that the closer I get to the router the more stable the connection is. If I am in the same room as the router, I usually do not even notice that something is wrong, but dmesg reveals that is does crash like once an hour anyway. No such bizarre behavior when running 11g.
Created attachment 195081 [details] dmesg-powersave-off
Created attachment 195181 [details] Core14 FW with uSniffer with TX_MNG probes Hi, can you please recreate a dump with the firmware attached? It would be nice to have a dump with 11n_disable=1 and another one without so that we can compare the 2. In order to create a dump when the firmware does not crash, you can do: echo 1 > /sys/kernel/debug/iwlwifi/0000\:0X\:00.0/iwlmvm/fw_restart Make sure to run with fw_restart=0 to avoid confusion. Thanks!
can you try to set cfg80211_disable_40mhz_24ghz to true? This is module parameter to the cfg80211 module. Thanks.
Created attachment 195831 [details] dmesg1
Created attachment 195841 [details] modprobe1
Created attachment 195851 [details] dump1
Created attachment 195861 [details] trace1
Created attachment 195871 [details] dmesg2
Created attachment 195881 [details] modprobe2
Created attachment 195891 [details] dump2
Created attachment 195901 [details] trace2
Created attachment 195911 [details] dmesg3
Created attachment 195921 [details] modprobe3
thanks. This is the same as the original bug though. I'll forward the information to the firmware team. Thank you.
Created attachment 195931 [details] trace3
Unfortunately there is no dump for the third one which does not crash. I do not have /sys/kernel/debug/iwlwifi directory, and cannot find any kernel option that would enable it: CONFIG_IWLWIFI=m CONFIG_IWLWIFI_LEDS=y CONFIG_IWLWIFI_OPMODE_MODULAR=y # CONFIG_IWLWIFI_BCAST_FILTERING is not set # CONFIG_IWLWIFI_UAPSD is not set CONFIG_IWLWIFI_DEBUG=y CONFIG_IWLWIFI_DEBUG_EXPERIMENTAL_UCODE=y CONFIG_IWLWIFI_DEVICE_TRACING=y Am I missing something?
The third one didn't crash and hence you didn't get any dump. This is fine. I am a bit concerned by the fact that you have 2 different issues: hang queues and ASSERT 100C. We'll see what the firmware team says about 100C, they may need other logs for this type of failures. I'll let you know. Thank you for the info provided so far.
I talked to the firmware team. They are already handling this issue. I'll provided soon a firmware on an earlier code base that don't seem to have this issue. Thank!
Created attachment 195941 [details] Core13 FW with uSniffer with TX_MNG probes Please try with this firmware. Note that you'll need to delete -17.ucode to work this firmware since it is an older code base. Thanks!
Oh my, this is much worse. The 16.ucode crashes as soon as I turn the wifi on, both with 11n and 11g. Dump coming up.
Created attachment 195951 [details] dmesg4
Created attachment 195961 [details] modprobe4
Created attachment 195971 [details] trace4
Created attachment 195981 [details] dump4
Ah - That's because of the debug probes. I'll get back to you tomorrow. Sorry for the noise.
We already have a few reports in the same area. Closing as duplicate. *** This bug has been marked as a duplicate of bug 107471 ***