Bug 193641 - iwlwifi: 8265: ASSERT 14FD on setup as monitor on A band - WIFILNX-608
Summary: iwlwifi: 8265: ASSERT 14FD on setup as monitor on A band - WIFILNX-608
Status: CLOSED INVALID
Alias: None
Product: Drivers
Classification: Unclassified
Component: network-wireless (show other bugs)
Hardware: x86-64 Linux
: P1 normal
Assignee: DO NOT USE - assign "network-wireless-intel" component instead
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-01-30 11:36 UTC by Jan Fuchs
Modified: 2017-08-26 14:52 UTC (History)
6 users (show)

See Also:
Kernel Version: 4.9.0-15
Tree: Mainline
Regression: No


Attachments
dmesg-output with one Intel 8265 crash (88.57 KB, text/plain)
2017-01-30 11:36 UTC, Jan Fuchs
Details
dmesg-output with three Intel 8265 (crash) (135.53 KB, application/octet-stream)
2017-01-30 11:36 UTC, Jan Fuchs
Details
Bash script (178 bytes, application/octet-stream)
2017-01-30 11:37 UTC, Jan Fuchs
Details
core24-build (25.48 KB, text/plain)
2017-01-31 10:06 UTC, Jan Fuchs
Details
iwlwifi-8625-27-dmesg.log (112.95 KB, text/x-log)
2017-01-31 14:50 UTC, Jan Fuchs
Details
iw list output (158.94 KB, text/plain)
2017-01-31 16:37 UTC, Jan Fuchs
Details

Description Jan Fuchs 2017-01-30 11:36:02 UTC
Created attachment 253541 [details]
dmesg-output with one Intel 8265 crash

When setting up a Intel 8265 to monitor mode via a simple bash script it crashes reproducible. Though, executing the commands individually it won't.

I've got a trace-cmd report (with -e iwlwifi -e mac80211 -e cfg80211 -e iwlwifi_msgwhile), which I'd like to send compressed via a privately to a developer.

ac-sniffer@acsniffer-ThinkCentre-M900:~$ ethtool -i wls3 | grep firmware
firmware-version: 22.361476.0
Comment 1 Jan Fuchs 2017-01-30 11:36:39 UTC
Created attachment 253551 [details]
dmesg-output with three Intel 8265 (crash)
Comment 2 Jan Fuchs 2017-01-30 11:37:04 UTC
Created attachment 253561 [details]
Bash script
Comment 3 Emmanuel Grumbach 2017-01-30 11:44:18 UTC
Does it work on channel 1 (freq = 2412)?
Comment 4 Jan Fuchs 2017-01-30 11:57:53 UTC
(In reply to Emmanuel Grumbach from comment #3)
> Does it work on channel 1 (freq = 2412)?

Yes, it does on freq 2412 with HT40+: no crash.
Comment 5 Emmanuel Grumbach 2017-01-30 17:46:03 UTC
Please try with core24 from https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi/core_release

You need to take the firmware and the driver.

Thanks.
Comment 6 Jan Fuchs 2017-01-31 10:05:59 UTC
Thank you.
Downloaded the firmware and moved it to /lib/firmware.
Though compiling the Core24 driver aborts with errors on my PC.
See the attached core24-build.txt
Comment 7 Jan Fuchs 2017-01-31 10:06:20 UTC
Created attachment 253651 [details]
core24-build
Comment 8 Emmanuel Grumbach 2017-01-31 10:17:55 UTC
Hm... Core24 won't work on such a recent kernel :(

Do you have an older kernel installed on this system?
Comment 9 Jan Fuchs 2017-01-31 13:52:06 UTC
I've compiled kernel 4.8.6 from the sources, installed and rebooted, selected the 4.8.6 kernel on startup. Core24 won't compile though.
You should have told me, which kernel I need ... ?
Comment 10 Luca Coelho 2017-01-31 14:26:20 UTC
I just pushed the latest version of our Core24 release[1] and it compiles fine with v4.8 on my machine.  Do you want to give it a try?

In any case, I think we should probably add the min/max kernel version supported by each Core on our wiki...


[1] http://git.kernel.org/cgit/linux/kernel/git/iwlwifi/backport-iwlwifi.git/log/?h=release/LinuxCore24
Comment 11 Jan Fuchs 2017-01-31 14:49:38 UTC
(In reply to Luca Coelho from comment #10)
> I just pushed the latest version of our Core24 release[1] and it compiles
> fine with v4.8 on my machine.  Do you want to give it a try?

Thank you. You are right - it compiled now without any errors.
But the Intel 8265 still crashes. See the attached iwlwifi-8625-27-dmesg.log

> In any case, I think we should probably add the min/max kernel version
> supported by each Core on our wiki...

Yes, good idea :)
Comment 12 Jan Fuchs 2017-01-31 14:50:00 UTC
Created attachment 253661 [details]
iwlwifi-8625-27-dmesg.log
Comment 13 Jan Fuchs 2017-01-31 15:01:10 UTC
Addition: tried it again with channel 36 (freq 5180) - no problems, no crash?!
Comment 14 Emmanuel Grumbach 2017-01-31 16:23:24 UTC
Can you try to check iw list?
Comment 15 Jan Fuchs 2017-01-31 16:37:52 UTC
Created attachment 253711 [details]
iw list output

As you can see in the iw list output, U-NII-2C channels are available (not marked as disabled). Tried it with Channel 104 again, see the dmesg output appended to the iw list output. Maybe it affects only U-NII-2C radio frequencies?
Comment 16 Emmanuel Grumbach 2017-02-05 07:16:02 UTC
Can you please send the firmware dump that is generated by the firmware crash?

Please see in [1] how to do that. In your case, no need for a special firmware.
Please take the time to read the privacy notice here [2].
Thank you.

[1] https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi/debugging#firmware_debugging
[2] https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi/debugging#privacy_aspects
Comment 17 Emmanuel Grumbach 2017-02-06 22:02:19 UTC
I got the data. Thanks.
Comment 18 Jan Fuchs 2017-03-14 09:12:03 UTC
Haven't heard any news from you guys for a while. Did you come up with a thought how to  solve this? I'm still getting bothered by this issue :/
Comment 19 Emmanuel Grumbach 2017-03-14 09:14:56 UTC
Unfortunately, this bug is not my hands, but in the firmware team's hand.
There isn't much I can from this point but being the bridge.

I am still waiting for them.
Comment 20 Emmanuel Grumbach 2017-03-21 12:24:02 UTC
The firmware team is telling me that the problem comes from the bandwidth.

Can you please get the latest iw from git:
https://git.kernel.org/pub/scm/linux/kernel/git/jberg/iw.git/

and do
iw phy0 channels

?

This will give us the allowed bandwidth.

thanks.
Comment 21 Emmanuel Grumbach 2017-03-21 16:37:56 UTC
Not need. Channel 104 can't be a control channel if the bandwidth is set to 80MHz but only the firmware enforces that. I'll share more details later.
Comment 22 Jan Fuchs 2017-03-30 10:10:28 UTC
Do I still need to provide the info, or will you share the details with us? :)
Comment 23 Emmanuel Grumbach 2017-03-30 13:24:44 UTC
Sorry, I haven't found the time to dive into the channel table.
If you have access to the 802.11 specification, you can look at Annex E to find the control channels that can take part in a 40MHz or 80MHz bonding.

I'll try to find some time for this next week.
Comment 24 Emmanuel Grumbach 2017-04-05 12:59:03 UTC
So I spent quite some time on this and:
104 can't be a central channel for a 80MHz channel width
the spec defines that channel 106 can be a central channel, meaning:

channel 106 maps to (5000 + 106 * 5) MHz = 5530MHz

From what I see in the spec, channels 42 58 106 122 138 and 155 can be central channels for 80MHz bandwidth.

On my device (which may have different tables than yours), I could open a sniffer using:
set freq 5500 80 5530
set freq 5520 80 5530
set freq 5540 80 5530
set freq 5560 80 5530

When I try
set freq 5520 80 5550 I get the same ASSERT as you.

But 5520 80 5550 means:
* central freq = 5550, which maps to channel 110
* control freq = 5520, which maps to channel 104

as written above this configuration is not allowed by the spec.
Comment 25 Emmanuel Grumbach 2017-04-05 13:00:11 UTC
I am now closing this bug, I will continue to get mails notification on each one of your comments. You can re-open if you still think something needs to be changed in our behavior.
Comment 26 Jan Fuchs 2017-04-24 13:41:28 UTC
Thanks for you remarks on the channel selection for a 80 MHz 802.11ac radio channel!
I will not re-open this case, but personally, I think the driver should intercept those non valid frequency configuriation, without an assertion.
I'll try to find a workaround in my simple shell script, though.
Comment 27 Emmanuel Grumbach 2017-07-08 21:01:31 UTC
You may want to take a look at bug 195299. We made the kernel more resilient.
Look at the last patches I added there.

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