Wi-Fi 6 AX200 firmware issue

Fgdou · 2024-04-08 14:39:30

I have an issue with my PCI network card on Arch Linux. The card is TP-Link Archer T4E

I can't connect to my home 5GHz wifi. It works with other wifis on 2GHz.

The connection process is starting, takes a while, and breaks. Sometimes it connects, but the `arp` table is not complete and internet access is not working.

Here are the infos of the card and my os :

uname -u

Linux fgdou-fixe 6.8.2-arch2-1 #1 SMP PREEMPT_DYNAMIC Thu, 28 Mar 2024 17:06:35 +0000 x86_64 GNU/Linux

sudo lshw -c network

  *-network DISABLED
       description: Wireless interface
       product: Wi-Fi 6 AX200
       vendor: Intel Corporation
       physical id: 0
       bus info: pci@0000:04:00.0
       logical name: wlan0
       version: 1a
       serial: 14:f6:d8:b1:a1:e3
       width: 64 bits
       clock: 33MHz
       capabilities: pm msi pciexpress msix bus_master cap_list ethernet physical wireless
       configuration: broadcast=yes driver=iwlwifi driverversion=6.8.2-arch2-1 firmware=77.ad46c98b.0 cc-a0-77.ucode latency=0 link=no multicast=yes wireless=IEEE 802.11
       resources: irq:19 memory:f7100000-f7103fff

And the error related when I try to connect

sudo dmesg

[  173.957814] wlan0: send auth to f0:a7:31:a9:66:e2 (try 1/3)
[  173.998573] wlan0: authenticated
[  174.001937] wlan0: associate with f0:a7:31:a9:66:e2 (try 1/3)
[  174.010106] wlan0: RX AssocResp from f0:a7:31:a9:66:e2 (capab=0x1511 status=0 aid=9)
[  174.026821] wlan0: associated
[  174.093597] wlan0: Limiting TX power to 20 (23 - 3) dBm as advertised by f0:a7:31:a9:66:e2
[  184.102069] iwlwifi 0000:04:00.0: Queue 3 is stuck 0 16
[  184.102178] iwlwifi 0000:04:00.0: Microcode SW error detected. Restarting 0x0.
[  184.102316] iwlwifi 0000:04:00.0: Start IWL Error Log Dump:
[  184.102317] iwlwifi 0000:04:00.0: Transport status: 0x0000004A, valid: 6
[  184.102319] iwlwifi 0000:04:00.0: Loaded firmware version: 77.ad46c98b.0 cc-a0-77.ucode
[  184.102321] iwlwifi 0000:04:00.0: 0x00000084 | NMI_INTERRUPT_UNKNOWN       
[  184.102322] iwlwifi 0000:04:00.0: 0x00002AF0 | trm_hw_status0
[  184.102323] iwlwifi 0000:04:00.0: 0x00000000 | trm_hw_status1
[  184.102324] iwlwifi 0000:04:00.0: 0x004F8B7A | branchlink2
[  184.102325] iwlwifi 0000:04:00.0: 0x000151CE | interruptlink1
[  184.102326] iwlwifi 0000:04:00.0: 0x000151CE | interruptlink2
[  184.102327] iwlwifi 0000:04:00.0: 0x0000F178 | data1
[  184.102328] iwlwifi 0000:04:00.0: 0x01000000 | data2
[  184.102329] iwlwifi 0000:04:00.0: 0x00000000 | data3
[  184.102330] iwlwifi 0000:04:00.0: 0x1880664F | beacon time
[  184.102331] iwlwifi 0000:04:00.0: 0x7BC439AF | tsf low
[  184.102332] iwlwifi 0000:04:00.0: 0x000000C4 | tsf hi
[  184.102333] iwlwifi 0000:04:00.0: 0x00000000 | time gp1
[  184.102334] iwlwifi 0000:04:00.0: 0x017E1C50 | time gp2
[  184.102335] iwlwifi 0000:04:00.0: 0x00000001 | uCode revision type
[  184.102336] iwlwifi 0000:04:00.0: 0x0000004D | uCode version major
[  184.102337] iwlwifi 0000:04:00.0: 0xAD46C98B | uCode version minor
[  184.102338] iwlwifi 0000:04:00.0: 0x00000340 | hw version
[  184.102339] iwlwifi 0000:04:00.0: 0x00C89000 | board version
[  184.102340] iwlwifi 0000:04:00.0: 0x0300001C | hcmd
[  184.102341] iwlwifi 0000:04:00.0: 0x80020000 | isr0
[  184.102342] iwlwifi 0000:04:00.0: 0x00000000 | isr1
[  184.102343] iwlwifi 0000:04:00.0: 0x08F00002 | isr2
[  184.102344] iwlwifi 0000:04:00.0: 0x04C0681C | isr3
[  184.102345] iwlwifi 0000:04:00.0: 0x00000000 | isr4
[  184.102346] iwlwifi 0000:04:00.0: 0x00A80103 | last cmd Id
[  184.102347] iwlwifi 0000:04:00.0: 0x0000F178 | wait_event
[  184.102348] iwlwifi 0000:04:00.0: 0x000000D4 | l2p_control
[  184.102349] iwlwifi 0000:04:00.0: 0x00000020 | l2p_duration
[  184.102349] iwlwifi 0000:04:00.0: 0x00000007 | l2p_mhvalid
[  184.102350] iwlwifi 0000:04:00.0: 0x00000000 | l2p_addr_match
[  184.102351] iwlwifi 0000:04:00.0: 0x00000009 | lmpm_pmg_sel
[  184.102352] iwlwifi 0000:04:00.0: 0x00000000 | timestamp
[  184.102353] iwlwifi 0000:04:00.0: 0x00002884 | flow_handler
[  184.102386] iwlwifi 0000:04:00.0: Start IWL Error Log Dump:
[  184.102387] iwlwifi 0000:04:00.0: Transport status: 0x0000004A, valid: 7
[  184.102388] iwlwifi 0000:04:00.0: 0x20000066 | NMI_INTERRUPT_HOST
[  184.102389] iwlwifi 0000:04:00.0: 0x00000000 | umac branchlink1
[  184.102390] iwlwifi 0000:04:00.0: 0x80455D2E | umac branchlink2
[  184.102391] iwlwifi 0000:04:00.0: 0x80472CBA | umac interruptlink1
[  184.102392] iwlwifi 0000:04:00.0: 0x80472CBA | umac interruptlink2
[  184.102393] iwlwifi 0000:04:00.0: 0x01000000 | umac data1
[  184.102394] iwlwifi 0000:04:00.0: 0x80472CBA | umac data2
[  184.102394] iwlwifi 0000:04:00.0: 0x00000000 | umac data3
[  184.102395] iwlwifi 0000:04:00.0: 0x0000004D | umac major
[  184.102396] iwlwifi 0000:04:00.0: 0xAD46C98B | umac minor
[  184.102397] iwlwifi 0000:04:00.0: 0x017E1C4D | frame pointer
[  184.102398] iwlwifi 0000:04:00.0: 0xC0886260 | stack pointer
[  184.102399] iwlwifi 0000:04:00.0: 0x00AD0400 | last host cmd
[  184.102400] iwlwifi 0000:04:00.0: 0x00000000 | isr status reg
[  184.102410] iwlwifi 0000:04:00.0: IML/ROM dump:
[  184.102410] iwlwifi 0000:04:00.0: 0x00000003 | IML/ROM error/state
[  184.102420] iwlwifi 0000:04:00.0: 0x000057C3 | IML/ROM data1
[  184.102430] iwlwifi 0000:04:00.0: 0x00000080 | IML/ROM WFPM_AUTH_KEY_0
[  184.102436] iwlwifi 0000:04:00.0: Fseq Registers:
[  184.102439] iwlwifi 0000:04:00.0: 0x60000000 | FSEQ_ERROR_CODE
[  184.102442] iwlwifi 0000:04:00.0: 0x80290021 | FSEQ_TOP_INIT_VERSION
[  184.102445] iwlwifi 0000:04:00.0: 0x00050008 | FSEQ_CNVIO_INIT_VERSION
[  184.102449] iwlwifi 0000:04:00.0: 0x0000A503 | FSEQ_OTP_VERSION
[  184.102452] iwlwifi 0000:04:00.0: 0x80000003 | FSEQ_TOP_CONTENT_VERSION
[  184.102455] iwlwifi 0000:04:00.0: 0x4552414E | FSEQ_ALIVE_TOKEN
[  184.102458] iwlwifi 0000:04:00.0: 0x00100530 | FSEQ_CNVI_ID
[  184.102461] iwlwifi 0000:04:00.0: 0x00000532 | FSEQ_CNVR_ID
[  184.102465] iwlwifi 0000:04:00.0: 0x00100530 | CNVI_AUX_MISC_CHIP
[  184.102470] iwlwifi 0000:04:00.0: 0x00000532 | CNVR_AUX_MISC_CHIP
[  184.102475] iwlwifi 0000:04:00.0: 0x05B0905B | CNVR_SCU_SD_REGS_SD_REG_DIG_DCDC_VTRIM
[  184.102481] iwlwifi 0000:04:00.0: 0x0000025B | CNVR_SCU_SD_REGS_SD_REG_ACTIVE_VDIG_MIRROR
[  184.102484] iwlwifi 0000:04:00.0: 0x00050008 | FSEQ_PREV_CNVIO_INIT_VERSION
[  184.102487] iwlwifi 0000:04:00.0: 0x00290021 | FSEQ_WIFI_FSEQ_VERSION
[  184.102491] iwlwifi 0000:04:00.0: 0x00290021 | FSEQ_BT_FSEQ_VERSION
[  184.102494] iwlwifi 0000:04:00.0: 0x000000E6 | FSEQ_CLASS_TP_VERSION
[  184.102504] iwlwifi 0000:04:00.0: UMAC CURRENT PC: 0x804727d0
[  184.102507] iwlwifi 0000:04:00.0: LMAC1 CURRENT PC: 0xd0
[  184.102644] iwlwifi 0000:04:00.0: WRT: Collecting data: ini trigger 4 fired (delay=0ms).
[  184.102648] ieee80211 phy0: Hardware restart was requested

Do you know any other way ?

I tried to rollback to those firmwares :

iwlwifi-cc-a0-50.ucode.zst
iwlwifi-cc-a0-59.ucode.zst
iwlwifi-cc-a0-66.ucode.zst
iwlwifi-cc-a0-72.ucode.zst
iwlwifi-cc-a0-73.ucode.zst
iwlwifi-cc-a0-74.ucode.zst
iwlwifi-cc-a0-77.ucode.zst

And I tried adding those options to `/etc/modprobe.d/iwlwifi.conf`

options iwlwifi power_save=0
options iwlwifi uapsd_disable=1
options iwlwifi d0i3_disable=1
options iwlwifi 11n_disable=8
options iwlwifi bt_coex_active=0

seth · 2024-04-11 15:53:15

You associate w/ the AP effortlessly but then, exactly 10s later, might be good to know what's going on in the userspace during that time (and in general)
Please post your complete system journal for the boot:

sudo journalctl -b | curl -F 'file=@-' 0x0.st

Outswayer · 2024-04-12 07:38:14

The intel AX200 is just not a well supported card. I have one too in the tuxedo nano i use, and with my ISP's router it works perfectly, stable with good speeds, but with the Unifi wireless acces point i have it keeps crashing and restarting on default settings.

What i did was change the settings on the Unifi AP, i think changing the channel width was what finally got it to stop crashing, but it's at around 180mb/s now, compared to the 500mb/s i can get on the ISP router.

Thing is, it's not a broken AP or anything - my phone and 2 laptops all work great on it with good speeds. there's just some oddity that crashes the AX200 when connected to that access point in my case.

Fgdou · 2024-04-12 12:46:21

Outswayer wrote:

The intel AX200 is just not a well supported card. I have one too in the tuxedo nano i use, and with my ISP's router it works perfectly, stable with good speeds, but with the Unifi wireless acces point i have it keeps crashing and restarting on default settings.
What i did was change the settings on the Unifi AP, i think changing the channel width was what finally got it to stop crashing, but it's at around 180mb/s now, compared to the 500mb/s i can get on the ISP router.
Thing is, it's not a broken AP or anything - my phone and 2 laptops all work great on it with good speeds. there's just some oddity that crashes the AX200 when connected to that access point in my case.

I think you are right, there is nothing we can do about it, I guess. That's sad. I bought a TP-Link router to finally have a good Wi-Fi, and it doesn't work with my main PC.

Fgdou · 2024-04-12 12:52:47

seth wrote:

You associate w/ the AP effortlessly but then, exactly 10s later, might be good to know what's going on in the userspace during that time (and in general)
Please post your complete system journal for the boot:
sudo journalctl -b | curl -F 'file=@-' 0x0.st

Here is the journal output : https://0x0.st/X-M1.txt
Note that I am connecting back my Ethernet to be able to post

seth · 2024-04-12 14:19:43

First of all stop dhcpcd, you're already using the NM internal dhcp client and they trip over each other, resp. both try to solicit a dhcp lease and up-until that point everything looks fine.
There's a good chance that your AP simply doesn't like the spam and ignores both because it considers this a pot. DOS attack or whatever.

If the issue remains, report back w/ a clean journal.

Fgdou · 2024-04-12 14:27:14

seth wrote:

First of all stop dhcpcd, you're already using the NM internal dhcp client and they trip over each other, resp. both try to solicit a dhcp lease and up-until that point everything looks fine.
There's a good chance that your AP simply doesn't like the spam and ignores both because it considers this a pot. DOS attack or whatever.
If the issue remains, report back w/ a clean journal.

Yes, good call, thank you. I think I did try to enable / disable it in the past. But disabling it now, it doesn't solve the issue : https://0x0.st/X-us.txt

seth · 2024-04-12 14:42:51

Ok, same situation: effortless association and then stuck in dhcp.

1. idk what how or why a "cinnamon" process would call into wext, but it's probably a good idea to try this from something that's not cinnamon (basic openbx, icewm or so will do)

Apr 12 16:22:28 fgdou-fixe kernel: warning: `cinnamon' uses wireless extensions which will stop working for Wi-Fi 7 hardware; use nl80211

2. assuming it struggles w/ the particular dhcp request and since you've installed it anyway, you could use dhcpcd as NM dhcp client, https://wiki.archlinux.org/title/Networ … HCP_client (that's ok, just not running multiple dhcp clients)

3. reboot the router to make sure it's not still sulking because of the previous collisions (ie. flush its volatile memory

Fgdou · 2024-04-12 15:10:44

seth wrote:

Ok, same situation: effortless association and then stuck in dhcp.
1. idk what how or why a "cinnamon" process would call into wext, but it's probably a good idea to try this from something that's not cinnamon (basic openbx, icewm or so will do)
Apr 12 16:22:28 fgdou-fixe kernel: warning: `cinnamon' uses wireless extensions which will stop working for Wi-Fi 7 hardware; use nl80211
2. assuming it struggles w/ the particular dhcp request and since you've installed it anyway, you could use dhcpcd as NM dhcp client, https://wiki.archlinux.org/title/Networ … HCP_client (that's ok, just not running multiple dhcp clients)
3. reboot the router to make sure it's not still sulking because of the previous collisions (ie. flush its volatile memory

Interesting, changing the dhcp on NetworkManager doesn't change anything. However, when I start my computer without cinnamon and lightdm, I am able to connect to the 5ghz wifi with nmcli. Everything works as expected.
But, as soon as I launch lightdm and cinnmon, it stops working and goes in the loop again.

seth · 2024-04-12 15:23:22

I assume lightdm also doesn't matter?
=> https://github.com/linuxmint/cinnamon/issues

This is likely some network monitor or power management stuff, but I've no idea where to look for that.
You'll have to ask upstream

Arch Linux

#1 2024-04-08 14:39:30

Wi-Fi 6 AX200 firmware issue

#2 2024-04-11 15:53:15

Re: Wi-Fi 6 AX200 firmware issue

#3 2024-04-12 07:38:14

Re: Wi-Fi 6 AX200 firmware issue

#4 2024-04-12 12:46:21

Re: Wi-Fi 6 AX200 firmware issue

#5 2024-04-12 12:52:47

Re: Wi-Fi 6 AX200 firmware issue

#6 2024-04-12 14:19:43

Re: Wi-Fi 6 AX200 firmware issue

#7 2024-04-12 14:27:14

Re: Wi-Fi 6 AX200 firmware issue

#8 2024-04-12 14:42:51

Re: Wi-Fi 6 AX200 firmware issue

#9 2024-04-12 15:10:44

Re: Wi-Fi 6 AX200 firmware issue

#10 2024-04-12 15:23:22

Re: Wi-Fi 6 AX200 firmware issue

Board footer