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.
Sorry, I mean both iwlwifi-cc-a0-48.ucode and iwlwifi-cc-a0-46.ucode are affected...
Created attachment 284741 [details] additional dmesg output I believe I'm seeing a similar crash. Attached is my dmesg output.
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. :(
(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.
Could you please provide `iw list` output for AX200 card?
(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
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.
(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.
Very poor show from Intel on this one - haven't heard a peep from them! :|
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.
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.
(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.
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
(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.
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
Yes, sure. I will try to run STA and try to use trace-cmd.
Ping?
WIP
Created attachment 285707 [details] trace dat from openwrt
It was a little bit tricky. I also tried 5.4 backports, but result is the same.
Created attachment 285719 [details] Full trace.dat That's now looks like the right trace file.
Was it helpful?
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?
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?
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.
Created attachment 286405 [details] trace.dat from the OpenWrt Looks like this is the file you asked about.
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.
Created attachment 286517 [details] Little pach to change rx queue_num value
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.
Created attachment 286605 [details] Trace of the patched version Looks like we have more than one problem in the current issue.
Is it normal that we have 517 buffers? Looks like the problem is in iwl_pcie_rxmq_restock
PING?
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...
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?
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)
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...