@Yuri_Konotopov Neat!! That’s a good one to tell the folks over at bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=213829
Has anyone had issues with the AX210 resetting due to a microcode timeout that results in decreased performance (around ~500Kb/s) till the interface is stopped and started again? I am running Fedora 34 and I saw issues similar to this with a Dell XPS 13 and the Intel AX201 card but I can’t seem to find a resolution for it. When the error shows up I see the following in the logs but I am not sure how else to troubleshoot this problem.
kernel: iwlwifi 0000:aa:00.0: regular scan timed out
kernel: iwlwifi 0000:aa:00.0: Microcode SW error detected. Restarting 0x0.
kernel: iwlwifi 0000:aa:00.0: Start IWL Error Log Dump:
kernel: iwlwifi 0000:aa:00.0: Transport status: 0x0000004A, valid: 6
kernel: iwlwifi 0000:aa:00.0: Loaded firmware version: 63.c04f3485.0 ty-a0-gf-a0-63.ucode
kernel: iwlwifi 0000:aa:00.0: 0x00000084 | NMI_INTERRUPT_UNKNOWN
kernel: iwlwifi 0000:aa:00.0: 0x00A082F0 | trm_hw_status0
kernel: iwlwifi 0000:aa:00.0: 0x00000000 | trm_hw_status1
kernel: iwlwifi 0000:aa:00.0: 0x004DA004 | branchlink2
kernel: iwlwifi 0000:aa:00.0: 0x004D07EA | interruptlink1
kernel: iwlwifi 0000:aa:00.0: 0x004D07EA | interruptlink2
kernel: iwlwifi 0000:aa:00.0: 0x000163E4 | data1
kernel: iwlwifi 0000:aa:00.0: 0x01000000 | data2
kernel: iwlwifi 0000:aa:00.0: 0x00000000 | data3
kernel: iwlwifi 0000:aa:00.0: 0x6600057E | beacon time
kernel: iwlwifi 0000:aa:00.0: 0xF1E8DA65 | tsf low
kernel: iwlwifi 0000:aa:00.0: 0x0000003F | tsf hi
kernel: iwlwifi 0000:aa:00.0: 0x00000000 | time gp1
kernel: iwlwifi 0000:aa:00.0: 0x15F3CEAD | time gp2
kernel: iwlwifi 0000:aa:00.0: 0x00000001 | uCode revision type
kernel: iwlwifi 0000:aa:00.0: 0x0000003F | uCode version major
kernel: iwlwifi 0000:aa:00.0: 0xC04F3485 | uCode version minor
kernel: iwlwifi 0000:aa:00.0: 0x00000420 | hw version
kernel: iwlwifi 0000:aa:00.0: 0x00C89002 | board version
kernel: iwlwifi 0000:aa:00.0: 0x05AB001C | hcmd
kernel: iwlwifi 0000:aa:00.0: 0x20028000 | isr0
kernel: iwlwifi 0000:aa:00.0: 0x00400000 | isr1
kernel: iwlwifi 0000:aa:00.0: 0x48F00002 | isr2
kernel: iwlwifi 0000:aa:00.0: 0x40C37FCC | isr3
kernel: iwlwifi 0000:aa:00.0: 0x00200000 | isr4
kernel: iwlwifi 0000:aa:00.0: 0x05AB001C | last cmd Id
kernel: iwlwifi 0000:aa:00.0: 0x000163E4 | wait_event
kernel: iwlwifi 0000:aa:00.0: 0x00000054 | l2p_control
kernel: iwlwifi 0000:aa:00.0: 0x00000020 | l2p_duration
kernel: iwlwifi 0000:aa:00.0: 0x0000000F | l2p_mhvalid
kernel: iwlwifi 0000:aa:00.0: 0x00C700D8 | l2p_addr_match
kernel: iwlwifi 0000:aa:00.0: 0x00000009 | lmpm_pmg_sel
kernel: iwlwifi 0000:aa:00.0: 0x00000000 | timestamp
kernel: iwlwifi 0000:aa:00.0: 0x00006834 | flow_handler
kernel: iwlwifi 0000:aa:00.0: Start IWL Error Log Dump:
kernel: iwlwifi 0000:aa:00.0: Transport status: 0x0000004A, valid: 7
kernel: iwlwifi 0000:aa:00.0: 0x20000066 | NMI_INTERRUPT_HOST
kernel: iwlwifi 0000:aa:00.0: 0x00000000 | umac branchlink1
kernel: iwlwifi 0000:aa:00.0: 0x8045CF40 | umac branchlink2
kernel: iwlwifi 0000:aa:00.0: 0x8047E3DE | umac interruptlink1
kernel: iwlwifi 0000:aa:00.0: 0x8047E3DE | umac interruptlink2
kernel: iwlwifi 0000:aa:00.0: 0x01000000 | umac data1
kernel: iwlwifi 0000:aa:00.0: 0x8047E3DE | umac data2
kernel: iwlwifi 0000:aa:00.0: 0x00000000 | umac data3
kernel: iwlwifi 0000:aa:00.0: 0x0000003F | umac major
kernel: iwlwifi 0000:aa:00.0: 0xC04F3485 | umac minor
kernel: iwlwifi 0000:aa:00.0: 0x15F3D3DE | frame pointer
kernel: iwlwifi 0000:aa:00.0: 0xC0886264 | stack pointer
kernel: iwlwifi 0000:aa:00.0: 0x00BD010D | last host cmd
kernel: iwlwifi 0000:aa:00.0: 0x00010408 | isr status reg
kernel: iwlwifi 0000:aa:00.0: IML/ROM dump:
kernel: iwlwifi 0000:aa:00.0: 0x00000B03 | IML/ROM error/state
kernel: iwlwifi 0000:aa:00.0: 0x000077A7 | IML/ROM data1
kernel: iwlwifi 0000:aa:00.0: 0x00000080 | IML/ROM WFPM_AUTH_KEY_0
kernel: iwlwifi 0000:aa:00.0: Fseq Registers:
kernel: iwlwifi 0000:aa:00.0: 0x60000100 | FSEQ_ERROR_CODE
kernel: iwlwifi 0000:aa:00.0: 0x00440003 | FSEQ_TOP_INIT_VERSION
kernel: iwlwifi 0000:aa:00.0: 0x00080009 | FSEQ_CNVIO_INIT_VERSION
kernel: iwlwifi 0000:aa:00.0: 0x0000A652 | FSEQ_OTP_VERSION
kernel: iwlwifi 0000:aa:00.0: 0x00000002 | FSEQ_TOP_CONTENT_VERSION
kernel: iwlwifi 0000:aa:00.0: 0x4552414E | FSEQ_ALIVE_TOKEN
kernel: iwlwifi 0000:aa:00.0: 0x00400410 | FSEQ_CNVI_ID
kernel: iwlwifi 0000:aa:00.0: 0x00400410 | FSEQ_CNVR_ID
kernel: iwlwifi 0000:aa:00.0: 0x00400410 | CNVI_AUX_MISC_CHIP
kernel: iwlwifi 0000:aa:00.0: 0x00400410 | CNVR_AUX_MISC_CHIP
kernel: iwlwifi 0000:aa:00.0: 0x00009061 | CNVR_SCU_SD_REGS_SD_REG_DIG_DCDC_VTRIM
kernel: iwlwifi 0000:aa:00.0: 0x00000061 | CNVR_SCU_SD_REGS_SD_REG_ACTIVE_VDIG_MIRROR
kernel: iwlwifi 0000:aa:00.0: WRT: Collecting data: ini trigger 4 fired (delay=0ms).
kernel: iwlwifi 0000:aa:00.0: Got NSS = 4 - trimming to 2
kernel: iwlwifi 0000:aa:00.0: Got NSS = 4 - trimming to 2
@Kevin_Anderson Have you checked this thread? Check your kernel version by uname -r and you might need to upgrade the kernel by dnf upgrade.
@junaruga I believe the issues in that thread are unrelated to the issue that I am experiencing. I am currently running 5.14.12-200.fc34.x86_64 but I have seen the problem on multiple kernel versions. I’m not sure how to format the information below as a table but it is the kernel version, the firmware version, and the number of firmware crashes/resets I had.
Linux 5.13.4-200.fc34.x86_64 : 63.c04f3485.0 ty-a0-gf-a0-63.ucode : 10 crashes
Linux 5.13.6-200.fc34.x86_64 : 63.c04f3485.0 ty-a0-gf-a0-63.ucode : 4 crashes
Linux 5.13.7-200.fc34.x86_64 : 63.c04f3485.0 ty-a0-gf-a0-63.ucode : 32 crashes
Linux 5.13.10-200.fc34.x86_64 : 63.c04f3485.0 ty-a0-gf-a0-63.ucode : 2 crashes
Linux 5.13.12-200.fc34.x86_64 : 63.c04f3485.0 ty-a0-gf-a0-63.ucode : 2 crashes
Linux 5.13.13-200.fc34.x86_64 : 63.c04f3485.0 ty-a0-gf-a0-63.ucode : 9 crashes
Linux 5.13.14-200.fc34.x86_64 : 63.c04f3485.0 ty-a0-gf-a0-63.ucode : 7 crashes
Linux 5.13.16-200.fc34.x86_64 : 63.c04f3485.0 ty-a0-gf-a0-63.ucode : 6 crashes
Linux 5.13.19-200.fc34.x86_64 : 63.c04f3485.0 ty-a0-gf-a0-63.ucode : 13 crashes
Linux 5.14.9-200.fc34.x86_64 : 63.c04f3485.0 ty-a0-gf-a0-63.ucode : 2 crashes
Linux 5.14.10-200.fc34.x86_64 : 63.c04f3485.0 ty-a0-gf-a0-63.ucode : 3 crashes
Linux 5.14.11-200.fc34.x86_64 : 63.c04f3485.0 ty-a0-gf-a0-63.ucode : 5 crashes
@Kevin_Anderson OK, the kernel version 5.14.12-200.fc34.x86_64 is the latest one on the current Fedora 34.
Do you mind opening the issue ticket on the Fedora bugzilla with the component: kernel? Then they would help you. The document is here if you need.
@junaruga I opened BZ#1991752 back in August but it hasn’t seen any movement yet. That’s why I figured I would post here to see if anyone else has had similar issues or not. 
I using gcc-11.2.0 compiled kernels 5 days now - warm boot problem goes away.
OK. I emailed the Bugzilla ticket URL and this thread’s URL to a person I know who tested Framework Laptop on Fedora in the past. It might also be a good idea to ping on the Bugzilla ticket. Because I see there are many “NEW” state tickets for the kernel RPM. The maintainers might miss it. It might also be a good idea to email on the Fedora kernel group’s mailing list if you like.
@Kevin_Anderson Yes and it’s easily and reliably reproducible with iperf and a rescan. I opened a bug report for iwlwifi. Hoping that maybe once Kernel 5.15 is out and the new firmware is usable that it will be resolved, but not holding my breath.
1 Like
@tribixbite You didn’t do any configuration? I am currently running into a max of 60mps on popos 5.13.0
Nope nothing special
Hopefully I didn’t damage the connectors when installing them. The antenna wires were a bit long on my DIY and took many attempts to get them tucked.
Bluetooth is now working for me on Arch Linux with kernel 5.14.14.
Interesting… reboots were still resulting in no bluetooth controllers found for me on Arch/5.14.14 yesterday. Updated to 5.14.15 today (via pacman), still no dice. Cold boots are still working fine.
I’ve got a pretty basic setup, KDE with:
bluez 5.62-1
bluez-libs 5.62-1
bluez-qt 5.87.0-1
bluez-utils 5.62-1
Are you compiling the kernel yourself or running anything out of the ordinary?
After updating to the latest 5.14.16 kernel on Arch, bluetooth stopped working after both cold and warm boots. Rolling back to 5.14.15 at least got me functioning bluetooth again after a cold boot.
It didn’t even occur to me to run a speed test, because it was working fine, but when I saw the posts here, so I got to wondering.
This is out of the box running Pop OS Non-LTS, but I did actually upgrade to the beta version released a few days ago to see if it would fix the fingerprint reader (it did).
I can consistently get about 450Mbps up and down for speed test services hosted in Japan. My Macbook Pro seems to get slower (like 230) on average, but occasionally over 500.
Certainly more than 15 anyway.
(My connection is supposedly 2Gbps, but no WiFi can handle that…)
Oh, bluetooth is working in the sense that devices show up in a bluetooth scan, but I haven’t had the desire to actually pair anything yet.
shiruba@framework:~$ uname -a
Linux framework 5.13.0-7620-generic #20~1634827117~21.10~874b071 SMP Thu Oct 21 16:32:36 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
shiruba@framework:~$ cat /etc/os-release
NAME="Pop!_OS"
VERSION="21.10"
BTW My Router is a Synology R2600
1 Like
Good news – according to this comment on the bug, the patch fixing the bluetooth bug has landed and will be included in an upcoming 5.15 release. 
1 Like
I’m on 5.15.2 and the bluetooth warm boot issue is still here. The newer comments in that thread seem to suggest the same.
The last post seem to indicate there’s a patch that works. It would be nice if it made it in 5.15 at some point, but my money’s on it being released with 5.16.
I rebuilt a custom Arch 5.15.2 kernel with this patch and I can confirm bluetooth is now working properly for me, I was never able to get bluetoothctl to find a controller at all until this patch, warm boot, cold boot, didn’t matter. I’m using the vPro version of the AX210 as well.
2 Likes
Unfortunately I do not yet have a Framework (perhaps once it will be available in my country, and with a larger screen and more I/O), however as I generally upgrade my WiFi with modules I order from Fenvi’s AliExpress store (they also sell on Amazon and Newegg, to my country it just makes more sense to order these from AliExpress), I am currently rocking an AX210 on my Lenovo IdeaPad 300-15ISK, an AX200 with Fenvi’s FV-102 M.2 to standard PCIe adapter on my desktop (Asus Z97 Pro-Gamer at the moment), and the rest of the family are using 9260 modules on their laptops and desktops (the latter with FV-102 adapters).
I use Solus, and I can confirm from my testing that when the regressions occurred, it affected everything from the 9260 to the AX210 (there were both WiFi and Bluetooth issues, not necessarily at the same time, and not necessarily the same exact issues between the different models), at least on Solus, and currently on 5.14.16 on Solus, there are no issues currently with any of them.