Re: ath10k_pci: QCA9377 hard lock on resume from S3/deep suspend

[Jeff Johnson]

On 8/24/2026 11:41 PM, Omar Abuzaid wrote:
> Qualcomm Atheros QCA9377 using ath10k_pci can cause a complete system
> hard lock when resuming from deep/S3 suspend. During the failed
> resume, the kernel log shows repeated PCIe AER Physical Layer and Data
> Link Layer errors involving the QCA9377.
> 
> Unloading ath10k_pci before suspend prevents the problem.
> 
> System
> 
> Fedora Linux 44
> 
> Kernel:
> 7.1.10-200.fc44.x86_64
> 
> Architecture:
> x86_64
> 
> Kernel taint:
> 0
> 
> BIOS:
> 1.32.0
> 09/03/2024
> 
> Suspend modes:
> s2idle [deep]
> 
> Wi-Fi device:
> Qualcomm Atheros QCA9377 802.11ac Wireless Network Adapter [168c:0042] (rev 31)
> 
> Subsystem:
> Dell Device [1028:1810]
> 
> Driver:
> ath10k_pci
> 
> Problem
> 
> When the system resumes from deep/S3 suspend with ath10k_pci loaded,
> the entire system can hard-freeze.
> 
> When this happens:
> 
> The system becomes completely unresponsive.
> Caps Lock does not toggle.
> Magic SysRq does not respond.
> A forced power-off is required.
> 
> The kernel log around resume contains repeated PCIe AER errors such as:
> 
> ath10k_pci 0000:02:00.0: PCIe Bus Error: severity=Correctable,
> type=Physical Layer, (Receiver ID)
> ath10k_pci 0000:02:00.0: device [168c:0042] error status/mask=000000c1/00006000
> ath10k_pci 0000:02:00.0: [ 0] RxErr (First)
> 
> pcieport 0000:00:1c.7: AER: Multiple Correctable error message
> received from 0000:02:00.0
> 
> ath10k_pci 0000:02:00.0: PCIe Bus Error: severity=Correctable,
> type=Data Link Layer, (Receiver ID)
> 
> There are also ACPI errors during resume:
> 
> ACPI BIOS Error (bug): Could not resolve symbol [_SB.PCI0.GLAN.GPEH],
> AE_NOT_FOUND
> ACPI Error: Aborting method _GPE._L6D due to previous error (AE_NOT_FOUND)
> ACPI Error: AE_NOT_FOUND, while evaluating GPE method [_L6D]
> 
> Steps to reproduce
> 
> Boot normally with ath10k_pci loaded.
> Confirm the QCA9377 is using ath10k_pci.
> Suspend using deep/S3 suspend.
> Wake the system.
> The system may completely hard-lock during resume.
> 
> Isolation test / workaround
> 
> Before suspend:
> 
> sudo modprobe -r ath10k_pci
> systemctl suspend
> 
> With ath10k_pci unloaded, the system resumes normally without the hard lock.
> 
> After resume:
> 
> sudo modprobe ath10k_pci
> 
> The driver reloads and Wi-Fi reconnects normally.
> 
> Simply unloading and reloading ath10k_pci without suspending also
> works normally.
> 
> PCIe information
> 
> LnkCap: Speed 2.5GT/s, Width x1, ASPM L0s L1
> LnkCtl: ASPM L0s L1 Enabled
> LnkSta: Speed 2.5GT/s, Width x1
> 
> L1 PM substates are enabled:
> 
> PCI-PM_L1.2+
> PCI-PM_L1.1+
> ASPM_L1.2+
> ASPM_L1.1+
> 
> This appears to involve the QCA9377/ath10k PCIe resume or PCIe
> power-management path, although I cannot determine whether the root
> cause is ath10k, PCIe power management, device firmware, or system
> ACPI firmware.
> 
> I also filed this with Fedora as Bugzilla #2523243.
> 
> I can provide the complete previous-boot kernel log and perform
> additional tests if needed.

Please see:
https://wireless.docs.kernel.org/en/latest/en/users/drivers/ath11k/bugreport.html

Although that is an ath11k link, the same guidance should be used for ath10k,
substituting ath10k for ath11k where necessary. Having a Bugzilla record
allows the issue to be assigned and tracked.