Bug 204731 - iwlwifi: AX200: Could not start any interface with iwlwifi-cc-a0-48.ucode firmware
Summary: iwlwifi: AX200: Could not start any interface with iwlwifi-cc-a0-48.ucode fir...
Status: NEEDINFO
Alias: None
Product: Drivers
Classification: Unclassified
Component: network-wireless-intel (show other bugs)
Hardware: All Linux
: P1 high
Assignee: DO NOT USE - assign "network-wireless-intel" component instead
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-08-29 12:31 UTC by Kirill_Lukonin
Modified: 2022-07-30 19:04 UTC (History)
11 users (show)

See Also:
Kernel Version: Backports v5.3-rc4-1
Subsystem:
Regression: No
Bisected commit-id:


Attachments
dmesg log of firmware crash (5.91 KB, text/plain)
2019-08-29 12:31 UTC, Kirill_Lukonin
Details
additional dmesg output (38.21 KB, text/plain)
2019-08-31 23:40 UTC, Stephen
Details
trace dat from openwrt (2.31 KB, text/plain)
2019-10-29 13:31 UTC, Kirill_Lukonin
Details
Full trace.dat (348.76 KB, text/plain)
2019-10-30 17:21 UTC, Kirill_Lukonin
Details
trace.dat from the OpenWrt (1.25 MB, application/octet-stream)
2019-12-22 18:32 UTC, Kirill_Lukonin
Details
Little pach to change rx queue_num value (798 bytes, application/mbox)
2019-12-30 09:23 UTC, Kirill_Lukonin
Details
I've just made some attempts to strace the issue (98.34 KB, text/plain)
2020-01-01 19:48 UTC, Kirill_Lukonin
Details
Trace of the patched version (1.25 MB, application/octet-stream)
2020-01-03 19:27 UTC, Kirill_Lukonin
Details

Description Kirill_Lukonin 2019-08-29 12:31:58 UTC
Created attachment 284695 [details]
dmesg log of firmware crash

Any vif fails after system or daemon tries to bring it up.


Steps to represent:

1) Create any interface (AP/management)
2) Configure wpa_supplicant/hostapd
3) Start daemon or bring interface up with ip link command.


This issue is representable in the latest OpenWrt.

Bachports v5.2.8-1 is also affected.
iwlwifi-cc-a0-48.ucode is also affected.

So this looks like a driver problem.
Comment 1 Kirill_Lukonin 2019-08-29 12:50:30 UTC
Sorry, I mean both iwlwifi-cc-a0-48.ucode and iwlwifi-cc-a0-46.ucode are affected...
Comment 2 Stephen 2019-08-31 23:40:44 UTC
Created attachment 284741 [details]
additional dmesg output

I believe I'm seeing a similar crash. Attached is my dmesg output.
Comment 3 chrisaw 2019-09-02 14:55:20 UTC
I'm seeing the same here on QubesOS 4.0.2 which makes use of vifs to share Internet traffic between VMs.

It would be awesome to get a resolution or workaround for this since without it - no Internet connectivity for me. :(
Comment 4 chrisaw 2019-09-02 14:58:33 UTC
(In reply to chrisaw from comment #3)
> I'm seeing the same here on QubesOS 4.0.2 which makes use of vifs to share
> Internet traffic between VMs.
> 
> It would be awesome to get a resolution or workaround for this since without
> it - no Internet connectivity for me. :(

Just to add to this - in my case I'm on amd64 (Razer Blade Pro 17" 2019) so this isn't limited to Mips32 arch.
Comment 5 Oleksandr Natalenko 2019-09-04 07:22:12 UTC
Could you please provide `iw list` output for AX200 card?
Comment 6 chrisaw 2019-09-06 13:52:16 UTC
(In reply to Oleksandr Natalenko from comment #5)
> Could you please provide `iw list` output for AX200 card?

The following is actually from a "Killer AX1650" which is essentially an AX200 with inbuilt QoS goodies. Anyway - as far of the chip though it should be identical to a "genuine" AX200.

If the following isn't sufficient I can swap in the genuine Intel AX200 I have but I'd rather not take the laptop apart to do that if I can avoid it.

$ iw list

Wiphy phy84
	max # scan SSIDs: 20
	max scan IEs length: 365 bytes
	max # sched scan SSIDs: 20
	max # match sets: 11
	max # scan plans: 2
	max scan plan interval: 65535
	max scan plan iterations: 254
	Retry short limit: 7
	Retry long limit: 4
	Coverage class: 0 (up to 0m)
	Device supports RSN-IBSS.
	Device supports AP-side u-APSD.
	Device supports T-DLS.
	Supported Ciphers:
		* WEP40 (00-0f-ac:1)
		* WEP104 (00-0f-ac:5)
		* TKIP (00-0f-ac:2)
		* CCMP-128 (00-0f-ac:4)
		* GCMP-128 (00-0f-ac:8)
		* GCMP-256 (00-0f-ac:9)
		* CMAC (00-0f-ac:6)
		* GMAC-128 (00-0f-ac:11)
		* GMAC-256 (00-0f-ac:12)
	Available Antennas: TX 0 RX 0
	Supported interface modes:
		 * IBSS
		 * managed
		 * AP
		 * AP/VLAN
		 * monitor
		 * P2P-client
		 * P2P-GO
		 * P2P-device
	Band 1:
		Capabilities: 0x19ef
			RX LDPC
			HT20/HT40
			SM Power Save disabled
			RX HT20 SGI
			RX HT40 SGI
			TX STBC
			RX STBC 1-stream
			Max AMSDU length: 7935 bytes
			DSSS/CCK HT40
		Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
		Minimum RX AMPDU time spacing: 4 usec (0x05)
		HT Max RX data rate: 300 Mbps
		HT TX/RX MCS rate indexes supported: 0-15
		Bitrates (non-HT):
			* 1.0 Mbps
			* 2.0 Mbps (short preamble supported)
			* 5.5 Mbps (short preamble supported)
			* 11.0 Mbps (short preamble supported)
			* 6.0 Mbps
			* 9.0 Mbps
			* 12.0 Mbps
			* 18.0 Mbps
			* 24.0 Mbps
			* 36.0 Mbps
			* 48.0 Mbps
			* 54.0 Mbps
		Frequencies:
			* 2412 MHz [1] (22.0 dBm)
			* 2417 MHz [2] (22.0 dBm)
			* 2422 MHz [3] (22.0 dBm)
			* 2427 MHz [4] (22.0 dBm)
			* 2432 MHz [5] (22.0 dBm)
			* 2437 MHz [6] (22.0 dBm)
			* 2442 MHz [7] (22.0 dBm)
			* 2447 MHz [8] (22.0 dBm)
			* 2452 MHz [9] (22.0 dBm)
			* 2457 MHz [10] (22.0 dBm)
			* 2462 MHz [11] (22.0 dBm)
			* 2467 MHz [12] (22.0 dBm)
			* 2472 MHz [13] (22.0 dBm)
			* 2484 MHz [14] (22.0 dBm)
	Band 2:
		Capabilities: 0x19ef
			RX LDPC
			HT20/HT40
			SM Power Save disabled
			RX HT20 SGI
			RX HT40 SGI
			TX STBC
			RX STBC 1-stream
			Max AMSDU length: 7935 bytes
			DSSS/CCK HT40
		Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
		Minimum RX AMPDU time spacing: 4 usec (0x05)
		HT Max RX data rate: 300 Mbps
		HT TX/RX MCS rate indexes supported: 0-15
		VHT Capabilities (0x039071f6):
			Max MPDU length: 11454
			Supported Channel Width: 160 MHz
			RX LDPC
			short GI (80 MHz)
			short GI (160/80+80 MHz)
			TX STBC
			SU Beamformee
			MU Beamformee
		VHT RX MCS set:
			1 streams: MCS 0-9
			2 streams: MCS 0-9
			3 streams: not supported
			4 streams: not supported
			5 streams: not supported
			6 streams: not supported
			7 streams: not supported
			8 streams: not supported
		VHT RX highest supported: 0 Mbps
		VHT TX MCS set:
			1 streams: MCS 0-9
			2 streams: MCS 0-9
			3 streams: not supported
			4 streams: not supported
			5 streams: not supported
			6 streams: not supported
			7 streams: not supported
			8 streams: not supported
		VHT TX highest supported: 0 Mbps
		Bitrates (non-HT):
			* 6.0 Mbps
			* 9.0 Mbps
			* 12.0 Mbps
			* 18.0 Mbps
			* 24.0 Mbps
			* 36.0 Mbps
			* 48.0 Mbps
			* 54.0 Mbps
		Frequencies:
			* 5180 MHz [36] (22.0 dBm)
			* 5200 MHz [40] (22.0 dBm)
			* 5220 MHz [44] (22.0 dBm)
			* 5240 MHz [48] (22.0 dBm)
			* 5260 MHz [52] (22.0 dBm)
			* 5280 MHz [56] (22.0 dBm)
			* 5300 MHz [60] (22.0 dBm)
			* 5320 MHz [64] (22.0 dBm)
			* 5340 MHz [68] (22.0 dBm)
			* 5360 MHz [72] (22.0 dBm)
			* 5380 MHz [76] (22.0 dBm)
			* 5400 MHz [80] (22.0 dBm)
			* 5420 MHz [84] (22.0 dBm)
			* 5440 MHz [88] (22.0 dBm)
			* 5460 MHz [92] (22.0 dBm)
			* 5480 MHz [96] (22.0 dBm)
			* 5500 MHz [100] (22.0 dBm)
			* 5520 MHz [104] (22.0 dBm)
			* 5540 MHz [108] (22.0 dBm)
			* 5560 MHz [112] (22.0 dBm)
			* 5580 MHz [116] (22.0 dBm)
			* 5600 MHz [120] (22.0 dBm)
			* 5620 MHz [124] (22.0 dBm)
			* 5640 MHz [128] (22.0 dBm)
			* 5660 MHz [132] (22.0 dBm)
			* 5680 MHz [136] (22.0 dBm)
			* 5700 MHz [140] (22.0 dBm)
			* 5720 MHz [144] (22.0 dBm)
			* 5745 MHz [149] (22.0 dBm)
			* 5765 MHz [153] (22.0 dBm)
			* 5785 MHz [157] (22.0 dBm)
			* 5805 MHz [161] (22.0 dBm)
			* 5825 MHz [165] (22.0 dBm)
			* 5845 MHz [169] (22.0 dBm)
			* 5865 MHz [173] (22.0 dBm)
			* 5885 MHz [177] (22.0 dBm)
			* 5905 MHz [181] (22.0 dBm)
	Supported commands:
		 * new_interface
		 * set_interface
		 * new_key
		 * start_ap
		 * new_station
		 * new_mpath
		 * set_mesh_config
		 * set_bss
		 * authenticate
		 * associate
		 * deauthenticate
		 * disassociate
		 * join_ibss
		 * join_mesh
		 * remain_on_channel
		 * set_tx_bitrate_mask
		 * frame
		 * frame_wait_cancel
		 * set_wiphy_netns
		 * set_channel
		 * set_wds_peer
		 * tdls_mgmt
		 * tdls_oper
		 * start_sched_scan
		 * probe_client
		 * set_noack_map
		 * register_beacons
		 * start_p2p_device
		 * set_mcast_rate
		 * connect
		 * disconnect
		 * channel_switch
		 * set_qos_map
		 * add_tx_ts
		 * set_multicast_to_unicast
	Supported TX frame types:
		 * IBSS: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
		 * managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
		 * AP: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
		 * AP/VLAN: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
		 * mesh point: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
		 * P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
		 * P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
		 * P2P-device: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
	Supported RX frame types:
		 * IBSS: 0x40 0xb0 0xc0 0xd0
		 * managed: 0x40 0xd0
		 * AP: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
		 * AP/VLAN: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
		 * mesh point: 0xb0 0xc0 0xd0
		 * P2P-client: 0x40 0xd0
		 * P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
		 * P2P-device: 0x40 0xd0
	software interface modes (can always be added):
		 * AP/VLAN
		 * monitor
	valid interface combinations:
		 * #{ managed } <= 1, #{ AP, P2P-client, P2P-GO } <= 1, #{ P2P-device } <= 1,
		   total <= 3, #channels <= 2
	HT Capability overrides:
		 * MCS: ff ff ff ff ff ff ff ff ff ff
		 * maximum A-MSDU length
		 * supported channel width
		 * short GI for 40 MHz
		 * max A-MPDU length exponent
		 * min MPDU start spacing
	Device supports TX status socket option.
	Device supports HT-IBSS.
	Device supports SAE with AUTHENTICATE command
	Device supports low priority scan.
	Device supports scan flush.
	Device supports per-vif TX power setting
	P2P GO supports CT window setting
	P2P GO supports opportunistic powersave setting
	Driver supports full state transitions for AP/GO clients
	Driver supports a userspace MPM
	Driver/device bandwidth changes during BSS lifetime (AP/GO mode)
	Device adds DS IE to probe requests
	Device can update TPC Report IE
	Device supports static SMPS
	Device supports dynamic SMPS
	Device supports WMM-AC admission (TSPECs)
	Device supports configuring vdev MAC-addr on create.
	Device supports randomizing MAC-addr in scans.
	Device supports randomizing MAC-addr in sched scans.
	Device supports randomizing MAC-addr in net-detect scans.
	Supported extended features:
		* [ VHT_IBSS ]: VHT-IBSS
		* [ RRM ]: RRM
		* [ MU_MIMO_AIR_SNIFFER ]: MU-MIMO sniffer
		* [ SCAN_START_TIME ]: scan start timestamp
		* [ BSS_PARENT_TSF ]: BSS last beacon/probe TSF
		* [ SET_SCAN_DWELL ]: scan dwell setting
		* [ FILS_STA ]: STA FILS (Fast Initial Link Setup)
		* [ CONTROL_PORT_OVER_NL80211 ]: control port over nl80211
		* [ TXQS ]: FQ-CoDel-enabled intermediate TXQs
Comment 7 chrisaw 2019-09-09 11:25:03 UTC
I've contacted Intel directly about this issue.

@Kirill_Lukonin:

It would be good if you could reclassify this bug as affecting all archs - not just Mips32.
Comment 8 Kirill_Lukonin 2019-09-09 11:33:37 UTC
(In reply to chrisaw from comment #7)
> I've contacted Intel directly about this issue.
> 
> @Kirill_Lukonin:
> 
> It would be good if you could reclassify this bug as affecting all archs -
> not just Mips32.

NP.
Comment 9 chrisaw 2019-09-20 17:25:12 UTC
Very poor show from Intel on this one - haven't heard a peep from them! :|
Comment 10 Luca Coelho 2019-09-23 06:57:35 UTC
Sorry for the delay.  The two different dmesg logs seem to be different bugs.

The relevant part in this case is this:

In the first dmesg:

[  692.953899] iwlwifi 0000:01:00.0: 0x20000034 | NMI_INTERRUPT_WDG


In the second one:

[    4.374651] iwlwifi 0000:52:00.0: 0x200021A2 | ADVANCED_SYSASSERT


The latter seems to be a problem in our debugging code, and since it seems to be a more common problem, we'll take a look into it first.
Comment 11 Luca Coelho 2019-09-23 09:45:58 UTC
I tried to reproduce the 21A2 sysassert problem, but I couldn't.  I tried v5.3.1 (the version reported in the main bug) with both FWs.  The FW in the second dmesg is old (48.954cff6d.0), but I couldn't reproduce the bug with either.

I'll try once more with v5.2.11, which is the version I see in the second dmesg.
Comment 12 Kirill_Lukonin 2019-09-23 10:03:51 UTC
(In reply to Luca Coelho from comment #11)
> I tried to reproduce the 21A2 sysassert problem, but I couldn't.  I tried
> v5.3.1 (the version reported in the main bug) with both FWs.  The FW in the
> second dmesg is old (48.954cff6d.0), but I couldn't reproduce the bug with
> either.
> 
> I'll try once more with v5.2.11, which is the version I see in the second
> dmesg.

Please note that it is not 5.3.1 version in my dmesg. It's a 5.3 backports package.
Comment 13 Luca Coelho 2019-09-23 10:52:24 UTC
I couldn't reproduce it with v5.2.11 and either the old firmware (48.954cff6d.0) or the new one (48.4fa0041f.0).

Christopher and Stephen, can you try to reproduce the bug on your machine again and post the full dmesg? Then you could try to make sure you have both the newest kernel (v5.3.1) and the newest FW[1] and see if it works.  If it does, we have to find the right patch to send to 5.2 stable.

And please open a new bug, because we're high-jacking the bug Kirill reported with a different thing.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/plain/iwlwifi-cc-a0-48.ucode
Comment 14 Luca Coelho 2019-09-23 10:53:43 UTC
(In reply to Kirill_Lukonin from comment #12)
> (In reply to Luca Coelho from comment #11)
> > I tried to reproduce the 21A2 sysassert problem, but I couldn't.  I tried
> > v5.3.1 (the version reported in the main bug) with both FWs.  The FW in the
> > second dmesg is old (48.954cff6d.0), but I couldn't reproduce the bug with
> > either.
> > 
> > I'll try once more with v5.2.11, which is the version I see in the second
> > dmesg.
> 
> Please note that it is not 5.3.1 version in my dmesg. It's a 5.3 backports
> package.

Yes, as I said in the previous comment, your bug seems to be different and Stephen, Christopher and I have high-jacked it.  We'll continue the discussion about the other bug in a new report.

I'll take a look at the problem you're having now.
Comment 15 Luca Coelho 2019-09-23 11:18:58 UTC
Kirill, is it possible for you to take trace-cmd logs as described in our wiki[1]?

Also, do you have the same problem if you try to use a normal STA instead of AP mode?

The problem seems to be that we are calculating the number of queues incorrectly, somehow, when we try to send the RFH_QUEUE_CONFIG_CMD, causing a mismatch between the num_queues and the actual data we are passing.

It can also be some sort of alignment issue, because we have 64-bit values in that command and you are using a 32-bit platform.

[1] https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi/debugging#tracing
Comment 16 Kirill_Lukonin 2019-09-23 13:00:17 UTC
Yes, sure. I will try to run STA and try to use trace-cmd.
Comment 17 Luca Coelho 2019-10-12 09:43:12 UTC
Ping?
Comment 18 Kirill_Lukonin 2019-10-12 09:49:48 UTC
WIP
Comment 19 Kirill_Lukonin 2019-10-29 13:31:42 UTC
Created attachment 285707 [details]
trace dat from openwrt
Comment 20 Kirill_Lukonin 2019-10-29 17:08:45 UTC
It was a little bit tricky.

I also tried 5.4 backports, but result is the same.
Comment 21 Kirill_Lukonin 2019-10-30 17:21:09 UTC
Created attachment 285719 [details]
Full trace.dat

That's now looks like the right trace file.
Comment 22 Kirill_Lukonin 2019-11-05 18:11:51 UTC
Was it helpful?
Comment 23 Kirill_Lukonin 2019-11-17 13:00:50 UTC
Ping?
Comment 24 Luca Coelho 2019-11-25 07:56:45 UTC
Hi Kirill,

Unfortunately I could not open either of these two files.  Trace-cmd reports "error reading header for trace.dat".  Any idea why they seem to be corrupted? How did you get these traces?
Comment 25 Kirill_Lukonin 2019-11-30 18:28:53 UTC
Hello 

I just redirected the output to the file. And copied it with scp from the router.

Do you have some instructions how to fetch this file right?
Comment 26 Luca Coelho 2019-12-20 12:57:51 UTC
Sorry I just came back to this now.

Ah, can you send us the binary form of trace.dat? We have some extra scripts that parse directly from the binary, so we can get more information.
Comment 27 Kirill_Lukonin 2019-12-22 18:32:41 UTC
Created attachment 286405 [details]
trace.dat from the OpenWrt

Looks like this is the file you asked about.
Comment 28 Kirill_Lukonin 2019-12-30 09:22:33 UTC
Hello.

Just sharing my little investigation result.
I noticed that rx queue counter in error message is negative and it's value is -5.

So I decided to hardcode a positive value and check the driver behavior.
Can't figure out is it a good or bad, but with this little patch driver doesn't show previous error message.
Comment 29 Kirill_Lukonin 2019-12-30 09:23:23 UTC
Created attachment 286517 [details]
Little pach to change rx queue_num value
Comment 30 Kirill_Lukonin 2020-01-01 19:48:50 UTC
Created attachment 286561 [details]
I've just made some attempts to strace the issue

It's a file with two tests for IBSS and STA interfaces.

Patch was applied.
Comment 31 Kirill_Lukonin 2020-01-03 19:27:39 UTC
Created attachment 286605 [details]
Trace of the patched version

Looks like we have more than one problem in the current issue.
Comment 32 Kirill_Lukonin 2020-01-03 20:29:38 UTC
Is it normal that we have 517 buffers?

Looks like the problem is in iwl_pcie_rxmq_restock
Comment 33 Kirill_Lukonin 2020-01-19 15:53:15 UTC
PING?
Comment 34 Jeff Schuler 2020-03-26 17:40:39 UTC
I can confirm this issue, or a variant of it, on kernel v5.4.13 LTS, and both v5.4.0 & v5.4.3, ARCH=arm. Firmware 46.177b3e46.0, 48.4fa0041f.0, and also Intel's experimental 50.3e391d3e.0 as well, all three, on all three kernel versions.

When booted with -50.ucode, kernel 5.4.13, following shows TLV_FW_FSEQ_VERSION:

[    7.016181] Intel(R) Wireless WiFi driver for Linux
[    7.016188] Copyright(c) 2003- 2015 Intel Corporation
[    7.016453] iwlwifi 0000:01:00.0: enabling device (0140 -> 0142)
[    7.020680] iwlwifi 0001:01:00.0: enabling device (0140 -> 0142)
[    7.430795] iwlwifi 0000:01:00.0: TLV_FW_FSEQ_VERSION: FSEQ Version: 58.3.35.22
[    7.430818] iwlwifi 0000:01:00.0: Found debug destination: EXTERNAL_DRAM
[    7.430824] iwlwifi 0000:01:00.0: Found debug configuration: 0
[    7.433696] iwlwifi 0000:01:00.0: loaded firmware version 50.3e391d3e.0 op_mode iwlmvm
[    7.433941] iwlwifi 0001:01:00.0: TLV_FW_FSEQ_VERSION: FSEQ Version: 58.3.35.22
[    7.433960] iwlwifi 0001:01:00.0: Found debug destination: EXTERNAL_DRAM
[    7.433966] iwlwifi 0001:01:00.0: Found debug configuration: 0
[    7.437431] iwlwifi 0001:01:00.0: loaded firmware version 50.3e391d3e.0 op_mode iwlmvm

The device is there:

$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 2c:27:9e:31:00:0c brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ieee802.11/radiotap 60:f2:62:17:8e:d7 brd ff:ff:ff:ff:ff:ff
4: wlan1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 60:f2:62:16:a5:fd brd ff:ff:ff:ff:ff:ff


And this works... $ sudo iw dev wlan0 set type monitor

$ iw dev
phy#1
        Interface wlan1
                ifindex 4
                wdev 0x100000001
                addr 60:f2:62:16:a5:fd
                type managed
                txpower 0.00 dBm
phy#0
        Interface wlan0
                ifindex 3
                wdev 0x1
                addr 60:f2:62:17:8e:d7
                type monitor
                txpower 0.00 dBm


(Able to change interface to monitor mode ^)

But then actually bringing up the interface fails:

$ sudo ip link set wlan0 up
RTNETLINK answers: No such file or directory

:(

The kernel log shows nothing awry at all...
Comment 35 ag 2020-11-11 21:38:16 UTC
hi all
i found a bunch of firmware at https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/
there are apparently no other documents about them
-rw-r--r-- 	iwlwifi-cc-a0-46.ucode 	1044452 	logstatsplain
-rw-r--r-- 	iwlwifi-cc-a0-48.ucode 	1096704 	logstatsplain
-rw-r--r-- 	iwlwifi-cc-a0-50.ucode 	1101228 	logstatsplain
-rw-r--r-- 	iwlwifi-cc-a0-53.ucode 	1205332 	logstatsplain
-rw-r--r-- 	iwlwifi-cc-a0-55.ucode 	1219356 	logstatsplain
-rw-r--r-- 	iwlwifi-cc-a0-59.ucode 	1261280 	logstatsplain

has anyone tried them out do they work with AP on AX200?
Comment 36 ag 2020-11-18 16:32:33 UTC
i recently installed ubuntu 20.10 (kernel 5.8.0-28) with a card based on ax200 chipset that apparently ships with a rather recent firmware iwlwifi-cc-a0-55.ucode, i've been able to get it to work in station (managed) mode and ap mode (but only on 2.4ghz)
it seemed to be missing the 2nd phy and bluetooth didn't work (yet)
Comment 37 Gustavo A. Díaz 2021-08-18 18:30:33 UTC
I have an AX200 card as well and there is no way to change the Regdomain since seems because Intel's DRS/LAR, which with their firmware there is no way to bypass it. So, no AP with 5Ghz... a shame...

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