Wifi with Qualcomm Atheros QCA6174 802.11ac randomly disconnects, although it shows it's connected (but nothing loads)

Hi folks,

I’ve just reinstalled Manjaro i3 on my XPS 9560 after having to replace the SSD. I have a problem with wifi connectivity, that was not present before I changed the SSD and reinstalled everything.

The wifi connects right away upon load, however, after a short time, say one minute, nothing loads: no web pages, can’t check emails, the vpn doesn’t connect, etc etc. However network-manager shows that the connection is still up and running. If I manually reconnect, then everything works for some time, could be a minute again or an hour, I haven’t figured out what’s the trigger, and then nothing loads again — but the wifi connection is nominally working.

What I’ve tried to do:

  1. change grub parameters as suggested here
  2. I tried adding the line options ath10k_core skip_otp=y to modprobe.conf (this should be the same as adding this in /etc/default/grub as in the previous point)
  3. blacklist a bunch of stuff, following an older discussion about the same wifi chip here — in particular, I tried blacklisting: dell_wmi mxm_wmi wmi cfg80211 mac80211 dell_laptop
  4. disabling power save from grub (my iwconfig now shows powersave is off)
  5. disabling IPv6 in grub
  6. reinstalling the firmware
  7. disabling MAC address randomization as suggested here

All of this to no avail. I have another dell with the same Manjaro i3 (same kernel, etc) but with an Intel wifi card and the wifi works just fine, so I know it’s not the wifi, although with another router the problem is less severe, i.e., the “disconnections” don’t happen so often — they still happen though.

I haven’t noticed anything special in dmesg when I look for ath10k (which is the wifi module). Any help is greatly appreciated, thanks!

Here’s my system:

System: Host: izanami Kernel: 5.8.18-1-MANJARO x86_64 bits: 64 compiler: gcc v: 10.2.0 Desktop: i3 4.19 dm: LightDM Distro: Manjaro Linux
Machine: Type: Laptop System: Dell product: XPS 15 9560 v: N/A serial: <superuser/root required> Chassis: type: 10 serial: <superuser/root required> Mobo: Dell model: 05FFDN v: A00 serial: <superuser/root required> UEFI: Dell v: 1.7.1 date: 01/25/2018
Battery: ID-1: BAT0 charge: 41.9 Wh condition: 41.9/97.0 Wh (43%) volts: 13.0/11.4 model: SMP DELL GPM0365 serial: 4834 status: Full Device-1: apple_mfi_fastcharge model: N/A serial: N/A charge: N/A status: N/A
CPU: Info: Quad Core model: Intel Core i7-7700HQ bits: 64 type: MT MCP arch: Kaby Lake rev: 9 L2 cache: 6144 KiB flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 44817 Speed: 800 MHz min/max: 800/3800 MHz Core speeds (MHz): 1: 800 2: 800 3: 800 4: 800 5: 800 6: 800 7: 800 8: 800
Graphics: Device-1: Intel HD Graphics 630 vendor: Dell driver: i915 v: kernel bus ID: 00:02.0 chip ID: 8086:591b Device-2: NVIDIA GP107M [GeForce GTX 1050 Mobile] vendor: Dell driver: nouveau v: kernel bus ID: 01:00.0 chip ID: 10de:1c8d Device-3: Microdia Integrated_Webcam_HD type: USB driver: uvcvideo bus ID: 1-12:4 chip ID: 0c45:6713
Display: x11 server: X.Org 1.20.9 compositor: picom driver: intel,nouveau unloaded: modesetting alternate: fbdev,nv,vesa resolution: 1920x1080~60Hz s-dpi: 96 OpenGL: renderer: Mesa Intel HD Graphics 630 (KBL GT2) v: 4.6 Mesa 20.2.2 direct render: Yes
Audio: Device-1: Intel CM238 HD Audio vendor: Dell driver: snd_hda_intel v: kernel bus ID: 00:1f.3 chip ID: 8086:a171 Sound Server: ALSA v: k5.8.18-1-MANJARO
Network: Device-1: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter vendor: Bigfoot Networks driver: ath10k_pci v: kernel port: e000 bus ID: 02:00.0 chip ID: 168c:003e IF: wlp2s0 state: up mac: 9c:b6:d0:fb:d4:25 Device-2: Qualcomm Atheros QCA61x4 Bluetooth 4.0 type: USB driver: btusb bus ID: 1-4:3 chip ID: 0cf3:e300 IF-ID-1: enp0s20f0u2c4i2 state: down mac: 66:70:33:20:d2:48 IF-ID-2: tun0 state: unknown speed: 10 Mbps duplex: full mac: N/A
Drives: Local Storage: total: 931.51 GiB used: 97.67 GiB (10.5%) ID-1: /dev/nvme0n1 vendor: Samsung model: SSD 970 EVO Plus 1TB size: 931.51 GiB speed: 31.6 Gb/s lanes: 4 serial: S4EWNMFN913535Z
Partition: ID-1: / size: 898.83 GiB used: 97.67 GiB (10.9%) fs: ext4 dev: /dev/nvme0n1p2
Swap: ID-1: swap-1 type: partition size: 17.04 GiB used: 0 KiB (0.0%) priority: -2 dev: /dev/nvme0n1p3
Sensors: System Temperatures: cpu: 42.0 C mobo: 35.0 C sodimm: 35.0 C gpu: nouveau temp: 37.0 C Fan Speeds (RPM): cpu: 0
Info: Processes: 248 Uptime: 1h 26m Memory: 15.49 GiB used: 3.00 GiB (19.4%) Init: systemd v: 246 Compilers: gcc: 10.2.0 Packages: pacman: 1323 Shell: Bash v: 5.0.18 running in: urxvtd inxi: 3.1.08

You should add pcie_aspm=off in /etc/default/grub inline. file too. Next be sure that tlp have whitelisted modules:


# Exclude PCI(e) devices assigned to the listed drivers from Runtime PM.
# Default when unconfigured is "amdgpu nouveau nvidia radeon" which
# prevents accidential power-on of dGPU in hybrid graphics setups.
# Separate multiple drivers with spaces.
# Default: "amdgpu mei_me nouveau nvidia pcieport radeon", use "" to disable
# completely.

RUNTIME_PM_DRIVER_BLACKLIST="mei_me nvidia pcieport "

Thanks for the reply. I have pcie_aspm=off already in /etc/default/grub together with ath10k_core.skip_otp=y. I have tried uncommenting the RUNTIME_PM_DRIVER_BLACKLIST line in /etc/tlp.conf and now it reads:

RUNTIME_PM_DRIVER_BLACKLIST=“amdgpu mei_me nouveau nvidia pcieport radeon”

and rebooted — the problem still persits.

Share full dmesg.log

sudo dmesg > ~/dmesg.log

to pastebin.com in reply use URL.

Create log AFTER happen issue.

Here it is: https://pastebin.com/xJc4fKc2

Across that dmesg the issue has happened several times. Thanks again.

Do you using hibernation?

When I close the lid it should hibernate, yes.

Use sleep instead of hibernate.

Hibernation is Windows thing. Does not work well in Linux at all.

And mainly:

WORKAROUND for crashing driver after RESUME from suspend based on @NaX post

PROPER SYSTEMD SERVICE UNITS DIRS are /usr/lib/systemd/* and after enabling them these creating symling to /etc/systemd/*

REFERENCE: https://unix.stackexchange.com/a/367237

After reviewing several other examples I have adapted and are using the following and seems to work. Slight delay of a few seconds for wireless to come back after logging back in, but it seems to works.

To adapt to other systems or drivers you will need to find the drivers module equivalents for ath10k_pci && ath10k_core and the device name wlp3s0 . @see ip link .


This seems to work as a workaround , but for me feel like it should be unnecessary as this was working out the box and I believe is still a regression in the drivers power management.

I cant remember when setting up the machine but I think I was on ath9k and have not tried going back to it.

Systemd Suspend Service

Create file:

sudo nano /usr/lib/systemd/system/network-suspend.service

File content:

## -----------------------------------------------------------------------------
# Atheros "ath10k" driver suspend service for "wlp3s0" device
## -----------------------------------------------------------------------------
# /usr/lib/systemd/system/network-suspend.service
# sudo systemctl enable network-suspend.service
# sudo systemctl start network-suspend.service
# sudo systemctl status network-suspend.service
# sudo systemctl daemon-reload
## -----------------------------------------------------------------------------

Description=Network suspend service

ExecStart=/usr/bin/sudo -u $USER /bin/bash -lc 'nmcli networking off'
ExecStart=/usr/bin/sleep 1
ExecStart=/usr/bin/systemctl stop NetworkManager
ExecStart=/usr/bin/sleep 1
ExecStart=/usr/bin/ip link set wlp3s0 down
ExecStart=/usr/bin/sleep 1
ExecStart=/usr/bin/rmmod  ath10k_pci
ExecStart=/usr/bin/sleep 1
ExecStartPost=/usr/bin/rmmod  ath10k_core


Systemd Resume Service

Create file:

sudo nano /usr/lib/systemd/system/network-resume.service

File content:

## -----------------------------------------------------------------------------
# Atheros "ath10k" driver resume service for "wlp3s0" device
## -----------------------------------------------------------------------------
# /usr/lib/systemd/system/network-resume.service
# sudo systemctl enable network-resume.service
# sudo systemctl start network-resume.service
# sudo systemctl status network-resume.service
# sudo systemctl daemon-reload
## -----------------------------------------------------------------------------

Description=Network resume service

ExecStartPre=/usr/bin/sleep 2
ExecStart=/usr/bin/modprobe ath10k_pci
ExecStart=/usr/bin/sleep 1
ExecStart=/usr/bin/modprobe ath10k_core
ExecStart=/usr/bin/sleep 1
ExecStart=/usr/bin/ip link set wlp3s0 up
ExecStart=/usr/bin/sleep 1
ExecStart=/usr/bin/systemctl start NetworkManager
ExecStart=/usr/bin/sleep 1
ExecStart=/usr/bin/sudo -u $USER /bin/bash -lc 'nmcli networking on'
ExecStart=/usr/bin/sleep 1
ExecStart=/usr/bin/sudo -u $USER /bin/bash -lc 'nmcli r wifi off'
ExecStart=/usr/bin/sleep 1
ExecStart=/usr/bin/sudo -u $USER /bin/bash -lc 'nmcli r wifi on'


Enable Service

sudo systemctl enable network-suspend.service
sudo systemctl enable network-resume.service

Restart system or sudo systemctl daemon-reload

Okay I have switched to suspend everywhere instead of hibernate.

I don’t understand the other suggestion (WORKAROUND for crashing driver after RESUME from suspend): the problem I have is happening after fresh boot and reboot, not only after resume. Or did I misunderstand you? Thanks.

A quick update: a perfect example of this behaviour occurs when I try to update the system: pacman starts retrieving the packages but at some point in the download it freezes because, although network manager claims there is a connection, in fact nothing is being tranferred.

Another example is when I’m downloading something for example with a torrent client: the connection doesn’t last more than a few seconds — then it shows it’s connected, but nothing is being downloaded.

you may have a look at this page

1 Like

Thanks for the tip. I have replaced the firmware with those in the page you linked and it seems like the connection is more stable (though not as stable as that on the other laptop with the Intel chipset). I will keep testing for a few days and let you know how it goes. In the meantime any further hint or tips will be appreciated :slight_smile:

1 Like

After a week of testing on several networks the problem seems solved. Thanks!

1 Like