You are not logged in.

#1 2019-07-11 06:24:50

john01dav
Member
Registered: 2018-05-08
Posts: 7

[SOLVED] Reliability Issues With Intel AX200 Wifi Adapter

Although I am asking for help with a desktop computer, I put my thread in the laptop section because Intel's Wifi adapters are almost always used in laptops, implying that those who have the most useful information about this issue are more likely to look here. I assume that this forum has the capability to move threads if this is seen as a problem.
--------------------

I recently decided to add WiFi support to my desktop computer. I strongly prefer Intel's WiFi adapters because, up until now, they have always worked flawlessly with Linux due to their in-kernel drivers. Unfortunately, they are normally laptop M.2 parts, and my motherboard's M.2 slots do not have a key that is compatible with Intel's M.2 WiFi adapters. As such, I got an M.2 <-> PCIe card (link) that is designed specifically to adapt Intel's WiFi adapters to work in a PCIe slot of a desktop. I put an Intel AX200 M.2 WiFi adapter in this card (This WiFi adapter is listed as supported by the card.) and connected the antennas. Unfortunately, it seems like the AX200 is a new enough chip that the 5.2 Linux kernel is required for it to function. As such, I had to wait for it to be published to Arch's repositories earlier today.

After downloading and installing version 5.2 of the Linux kernel, it did not immediately work. When I attempted to connect to my WiFi network via Gnome, it failed to prompt for a password and disconnected. My WiFi network is WPA2-PSK with AES. Journalctl gave me the infamous error about a WiFi connection in in infrastructure mode with no access point. Some searching on the Internet gave me a vague Idea that Gnome caused this, so I used the Network Connections system in my XFCE desktop to save the password to my WiFi network. After going back into Gnome, it connected to the WiFi network after some finagling of disconnecting, reconnecting, etc. Once I was (seemingly) connected to my WiFi network, things seemed to be working correctly. I could get the full speed (200mbps) of my Internet connection over WiFi (5GHz), and the latency to my router was only about 5ms.

Unfortunately, I quickly encountered a very problematic problem: my WiFi system would suddenly and apparently randomly stop sending and/or receiving packets for spans of time anywhere from 5 seconds to 30 seconds, with anywhere from 10 seconds to 20 minutes between time spans of non-functional WiFi. When this issue first took place, my first thought was some sort of interference. I have heard of microwaves doing the same thing for 2.4GHz WiFi. This seems unlikely to me, however, because my phone (that is on the same WiFi network) is able to ping my router without issue, even when sitting next to my computer during a time span of non-functional WiFi. Whatever this issue is, it is specific to my computer. Localized interference from my computer is not ruled out. There are no journalctl messages that correspond with these occurrences, nor anything that seems to be related to WiFi at all (or, rather, not much of anything at all once my computer is booted). During the time spans of non-functional Wifi, ping commands can't reach anything (including the router) and no other network functions work (e.g. HTTP, DNS, SSH). Right as the time spans of non-functional WiFi end, the latency to my router (and, I assume, everywhere else), as measured by the ping command, is increased to around 100ms, sometimes less, for anywhere from a fraction of a second to several seconds. If I leave a ping command running for a length of time that is significantly larger than the time spans of non-functional WiFI, and the intervals between them, then the total packet loss varies from ~5% to 12.5% on different trials. Longer trials' results hover just over 5%, so this number is most likely accurate.

What is the cause of the time spans of non-functional WiFi, and how can I fix it? DuckDuckGo has no useful information.

Last edited by john01dav (2019-07-12 11:43:23)

Offline

#2 2019-07-11 07:51:32

V1del
Forum Moderator
Registered: 2012-10-16
Posts: 21,415

Re: [SOLVED] Reliability Issues With Intel AX200 Wifi Adapter

Post some output after reproduction of an issue, a complete

sudo journalctl -b

within [ code ] tags would be useful.

Moving to Kernel and Hardware.

Online

#3 2019-07-11 08:45:31

john01dav
Member
Registered: 2018-05-08
Posts: 7

Re: [SOLVED] Reliability Issues With Intel AX200 Wifi Adapter

V1del wrote:

Post some output after reproduction of an issue, a complete

sudo journalctl -b

within [ code ] tags would be useful.

Moving to Kernel and Hardware.

Here is journalctl -b's output. I ran the command a few seconds after the conclusion of an instance of the issue. It should be noted that the issue occurs seemingly randomly, so I have no way to reliably reproduce it. I also noticed that it may be related to DNS lookups to domains that are not currently in the cache, but when I artificially re-create this scenario, the issue is not induced.

Jul 10 23:47:54 blue kernel: microcode: microcode updated early to revision 0xae, date = 2019-02-14
Jul 10 23:47:54 blue kernel: Linux version 5.2.0-arch2-1-ARCH (builduser@heftig-101614) (gcc version 9.1.0 (GCC)) #1 SMP PREEMPT Mon Jul 8 18:18:54 UTC 2019
Jul 10 23:47:54 blue kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-linux root=UUID=955153fb-08be-46f8-85aa-f86d6346372f rw quiet
Jul 10 23:47:54 blue kernel: KERNEL supported cpus:
Jul 10 23:47:54 blue kernel:   Intel GenuineIntel
Jul 10 23:47:54 blue kernel:   AMD AuthenticAMD
Jul 10 23:47:54 blue kernel:   Hygon HygonGenuine
Jul 10 23:47:54 blue kernel:   Centaur CentaurHauls
Jul 10 23:47:54 blue kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
Jul 10 23:47:54 blue kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
Jul 10 23:47:54 blue kernel: x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
Jul 10 23:47:54 blue kernel: x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers'
Jul 10 23:47:54 blue kernel: x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR'
Jul 10 23:47:54 blue kernel: x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
Jul 10 23:47:54 blue kernel: x86/fpu: xstate_offset[3]:  832, xstate_sizes[3]:   64
Jul 10 23:47:54 blue kernel: x86/fpu: xstate_offset[4]:  896, xstate_sizes[4]:   64
Jul 10 23:47:54 blue kernel: x86/fpu: Enabled xstate features 0x1f, context size is 960 bytes, using 'compacted' format.
Jul 10 23:47:54 blue kernel: BIOS-provided physical RAM map:
Jul 10 23:47:54 blue kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000005efff] usable
Jul 10 23:47:54 blue kernel: BIOS-e820: [mem 0x000000000005f000-0x000000000005ffff] reserved
Jul 10 23:47:54 blue kernel: BIOS-e820: [mem 0x0000000000060000-0x000000000009ffff] usable
Jul 10 23:47:54 blue kernel: BIOS-e820: [mem 0x00000000000a0000-0x00000000000fffff] reserved
Jul 10 23:47:54 blue kernel: BIOS-e820: [mem 0x0000000000100000-0x00000000383affff] usable
Jul 10 23:47:54 blue kernel: BIOS-e820: [mem 0x00000000383b0000-0x00000000383b0fff] ACPI NVS
Jul 10 23:47:54 blue kernel: BIOS-e820: [mem 0x00000000383b1000-0x00000000383b1fff] reserved
Jul 10 23:47:54 blue kernel: BIOS-e820: [mem 0x00000000383b2000-0x000000003dbd0fff] usable
Jul 10 23:47:54 blue kernel: BIOS-e820: [mem 0x000000003dbd1000-0x000000003e04cfff] reserved
Jul 10 23:47:54 blue kernel: BIOS-e820: [mem 0x000000003e04d000-0x000000003e1cbfff] usable
Jul 10 23:47:54 blue kernel: BIOS-e820: [mem 0x000000003e1cc000-0x000000003e5d4fff] ACPI NVS
Jul 10 23:47:54 blue kernel: BIOS-e820: [mem 0x000000003e5d5000-0x000000003ee4ffff] reserved
Jul 10 23:47:54 blue kernel: BIOS-e820: [mem 0x000000003ee50000-0x000000003eefefff] type 20
Jul 10 23:47:54 blue kernel: BIOS-e820: [mem 0x000000003eeff000-0x000000003eefffff] usable
Jul 10 23:47:54 blue kernel: BIOS-e820: [mem 0x000000003ef00000-0x000000003fffffff] reserved
Jul 10 23:47:54 blue kernel: BIOS-e820: [mem 0x00000000e0000000-0x00000000efffffff] reserved
Jul 10 23:47:54 blue kernel: BIOS-e820: [mem 0x00000000fe000000-0x00000000fe010fff] reserved
Jul 10 23:47:54 blue kernel: BIOS-e820: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
Jul 10 23:47:54 blue kernel: BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
Jul 10 23:47:54 blue kernel: BIOS-e820: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
Jul 10 23:47:54 blue kernel: BIOS-e820: [mem 0x0000000100000000-0x00000004bdffffff] usable
Jul 10 23:47:54 blue kernel: NX (Execute Disable) protection: active
Jul 10 23:47:54 blue kernel: efi: EFI v2.70 by American Megatrends
Jul 10 23:47:54 blue kernel: efi:  ACPI 2.0=0x3e4e9000  ACPI=0x3e4e9000  SMBIOS=0x3ec41000  SMBIOS 3.0=0x3ec40000  MPS=0xfcb20  ESRT=0x3c154f98  MEMATTR=0x3c151018 
Jul 10 23:47:54 blue kernel: SMBIOS 3.1.1 present.
Jul 10 23:47:54 blue kernel: DMI: Gigabyte Technology Co., Ltd. Z390 M GAMING/Z390 M GAMING-CF, BIOS F2 08/29/2018
Jul 10 23:47:54 blue kernel: tsc: Detected 3600.000 MHz processor
Jul 10 23:47:54 blue kernel: e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
Jul 10 23:47:54 blue kernel: e820: remove [mem 0x000a0000-0x000fffff] usable
Jul 10 23:47:54 blue kernel: last_pfn = 0x4be000 max_arch_pfn = 0x400000000
Jul 10 23:47:54 blue kernel: MTRR default type: write-back
Jul 10 23:47:54 blue kernel: MTRR fixed ranges enabled:
Jul 10 23:47:54 blue kernel:   00000-9FFFF write-back
Jul 10 23:47:54 blue kernel:   A0000-BFFFF uncachable
Jul 10 23:47:54 blue kernel:   C0000-FFFFF write-protect
Jul 10 23:47:54 blue kernel: MTRR variable ranges enabled:

Offline

#4 2019-07-11 09:11:31

V1del
Forum Moderator
Registered: 2012-10-16
Posts: 21,415

Re: [SOLVED] Reliability Issues With Intel AX200 Wifi Adapter

That's limited by your pager use --no-pager or redirect into a file for the complete output.

Online

#5 2019-07-11 10:14:44

john01dav
Member
Registered: 2018-05-08
Posts: 7

Re: [SOLVED] Reliability Issues With Intel AX200 Wifi Adapter

V1del wrote:

That's limited by your pager use --no-pager or redirect into a file for the complete output.

I used that flag and sent the output to a file. I then looked at the file to see if there is any private information there. Due to what I found, I can not post the full log. Some examples of things that I have found include the name of my WiFi network (which would risk giving away my location), my public IP address (which, again, gives *far* more location data that I want, in addition to other risks), and some other information (eg. a WiFi group key, I think) that I don't know enough to know if I can safely release or not. I can, of course, look for specific things in this log that may cause these symptoms, but it is not reasonable to compromise my own security by placing the whole log on the public Internet.

Last edited by john01dav (2019-07-11 10:15:23)

Offline

#6 2019-07-11 11:07:46

V1del
Forum Moderator
Registered: 2012-10-16
Posts: 21,415

Re: [SOLVED] Reliability Issues With Intel AX200 Wifi Adapter

Well to properly diagnose wifi issues we will need at least partially some of that information, mark things you feel to be sensitive with a clear <redacted> or similar. FWIW if that seems like too much work initially we might get some good leads from just the kernel log

journalctl -kb

that shouldn't contain much that is really sensitive.  But we would likely need to have some log of the network management solution you are using which will contain bits and pieces of that. FWIW something that people often run into, do you have any conflicting services started? What's the output of

systemctl list-unit-files --state=enabled
systemctl list-units | grep -iE '(net|wpa|dhcp|conn|iwd|wicd)'

Online

#7 2019-07-12 00:10:56

john01dav
Member
Registered: 2018-05-08
Posts: 7

Re: [SOLVED] Reliability Issues With Intel AX200 Wifi Adapter

I continued researching this issue on my own after posting this thread, as I always do. I seem to have found a solution. Specifically, this post¹ about a different Intel WiFi chip suggested disabling power save mode as a workaround for a driver error.

1: This thread is titled "[SOLVED] slow intermittent wireless on AC-8260" and the user who posted the useful response is "javamarket." I include this information so that future readers can find the solution if Arch Linux's forums change their link structure.

Offline

#8 2019-07-12 07:05:07

V1del
Forum Moderator
Registered: 2012-10-16
Posts: 21,415

Re: [SOLVED] Reliability Issues With Intel AX200 Wifi Adapter

Glad to hear, please mark your own thread as [SOLVED] by editing the title in your first post.

Online

#9 2019-11-13 04:39:46

narutowindy
Member
Registered: 2019-09-10
Posts: 4

Re: [SOLVED] Reliability Issues With Intel AX200 Wifi Adapter

this chip firmware has a problem with the 5Ghz connections on Linux,  often disconnects to the AP.  hopefully solves the problem in future firmwares...


https://bugzilla.kernel.org/buglist.cgi … h=AX%20200

Last edited by narutowindy (2019-11-13 04:40:38)

Offline

#10 2020-04-05 07:52:09

henno
Member
Registered: 2007-11-30
Posts: 14

Re: [SOLVED] Reliability Issues With Intel AX200 Wifi Adapter

I don't mean to necrobump this, but I have some updates of my own that might help other uses that find themselves in this thread.

Manually setting the power_save to 'off' fixed the issue for me every time, but I couldn't find a stateful way of making this remain the case after reboots (particularly as I access this machine remotely most of the time).

I tried passing this to the iwlwifi driver module in /etc/modprobe.d/iwlwifi.conf:

options iwlwifi power_save=0

But after each reboot power_save was still set to on.

I tried scores of other ways, including custom udev scripts but none of them were particularly graceful, so I won't bore you with them.

In the end, the solution (and reason power_save=0 was not 'sticking') was actually the module iwlmvm. Adding this to /etc/modprobe.d/iwlwifi.conf solved it, and power_save is now 'off' post reboot:

options iwlmvm power_scheme=1

Offline

#11 2020-06-01 08:55:01

Cirelli94
Member
Registered: 2016-12-13
Posts: 37

Re: [SOLVED] Reliability Issues With Intel AX200 Wifi Adapter

henno wrote:

I don't mean to necrobump this, but I have some updates of my own that might help other uses that find themselves in this thread.

Manually setting the power_save to 'off' fixed the issue for me every time, but I couldn't find a stateful way of making this remain the case after reboots (particularly as I access this machine remotely most of the time).

I tried passing this to the iwlwifi driver module in /etc/modprobe.d/iwlwifi.conf:

options iwlwifi power_save=0

But after each reboot power_save was still set to on.

I tried scores of other ways, including custom udev scripts but none of them were particularly graceful, so I won't bore you with them.

In the end, the solution (and reason power_save=0 was not 'sticking') was actually the module iwlmvm. Adding this to /etc/modprobe.d/iwlwifi.conf solved it, and power_save is now 'off' post reboot:

options iwlmvm power_scheme=1

I henno, is your solution equal to javamarket's one here but using kernel module flag instead of the script, am I right?
Thanks

Offline

Board footer

Powered by FluxBB