Description of problem: Upgrading atheros-firmware to 20250509-1.fc42 broke WiFi support on my Lenovo T14s AMD Gen 6, ouput of `inxi -n` is: ``` Network: Device-1: Qualcomm WCN785x Wi-Fi 7 320MHz 2x2 [FastConnect 7800] driver: ath12k_pci IF: wlp194s0 state: up mac: 76:8c:8d:a3:ee:29 Device-2: Realtek RTL8153 Gigabit Ethernet Adapter driver: r8152 type: USB IF: eth0 state: up speed: 1000 Mbps duplex: full mac: bc:0f:9a:a1:c2:73 IF-ID-1: docker0 state: down mac: d6:eb:55:81:da:cc ``` Downgrading to `atheros-firmware-20250311-1.fc42` fixed the issue Version-Release number of selected component (if applicable): 20250311-1.fc42 How reproducible: Problem persists after rebooting multiple times. Steps to Reproduce: 1. Upgrade atheros-firmware to 20250509-1.fc42 2. Reboot Actual results: WiFi does not show up in Gnome settings anymore, any attempt to connect to a WiFi network fails. Expected results: WiFi continues working as before Additional info: Similar issues seem to have been reported for Arch Linux in https://www.reddit.com/r/archlinux/comments/1kja6f9/ath12k_regression_on_latest_linuxfirmware_upgrade/
I have the same issue. The card shows when lspci is run. The version I have issue with is 20250509. Version 20250311 works just fine. No interface is created on the latest version. Downgrading to the previous package version provides expected behavior. If you want dmesg output or anything like that I can upgrade it again and provide it.
Speaking with the vendor it's a known issue and they're working on a fix. For the moment users should stick with the april release. For reference the problematic commit is: 360fd4530 ath12k: WCN7850 hw2.0: update to WLAN.HMT.1.1.c5-00284-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3
Wouldn't it be better to revert the update? It took me over an hour to find the right RPM package and finally this BZ report. I don't think all Fedora users can do it :-/ dnf rollback also does not work: ~ $ sudo dnf history undo 55 Place your right middle finger on the fingerprint reader Updating and loading repositories: Copr repo for PyCharm owned by phracek 100% | 8.8 KiB/s | 2.1 KiB | 00m00s RPM Fusion for Fedora 42 - Nonfree - NVIDIA Driver 100% | 15.4 KiB/s | 8.6 KiB | 00m01s RPM Fusion for Fedora 42 - Nonfree - Steam 100% | 16.2 KiB/s | 8.3 KiB | 00m01s Docker CE Stable - x86_64 100% | 23.2 KiB/s | 3.5 KiB | 00m00s Fedora 42 - x86_64 - Updates 100% | 77.9 KiB/s | 24.0 KiB | 00m00s google-chrome-canary 100% | 5.2 KiB/s | 1.3 KiB | 00m00s google-chrome 100% | 5.7 KiB/s | 1.3 KiB | 00m00s Google Cloud CLI 100% | 4.1 KiB/s | 1.4 KiB | 00m00s Kubernetes 100% | 4.4 KiB/s | 1.8 KiB | 00m00s slack 100% | 1.3 KiB/s | 1.8 KiB | 00m01s Fedora 42 - x86_64 - Updates 100% | 2.5 MiB/s | 1.7 MiB | 00m01s google-chrome-canary 100% | 7.0 KiB/s | 3.3 KiB | 00m00s google-chrome 100% | 6.9 KiB/s | 3.3 KiB | 00m00s Google Cloud CLI 100% | 1.1 MiB/s | 811.2 KiB | 00m01s Repositories loaded. Failed to resolve the transaction: Cannot perform Install action, no match for: amd-gpu-firmware-20250410-1.fc42.noarch. Cannot perform Install action, no match for: atheros-firmware-20250410-1.fc42.noarch. Cannot perform Install action, no match for: brcmfmac-firmware-20250410-1.fc42.noarch. Cannot perform Install action, no match for: intel-gpu-firmware-20250410-1.fc42.noarch. Cannot perform Install action, no match for: intel-vsc-firmware-20250410-1.fc42.noarch. Cannot perform Install action, no match for: iwlegacy-firmware-20250410-1.fc42.noarch. Cannot perform Install action, no match for: iwlwifi-dvm-firmware-20250410-1.fc42.noarch. Cannot perform Install action, no match for: cirrus-audio-firmware-20250410-1.fc42.noarch. Cannot perform Install action, no match for: nxpwireless-firmware-20250410-1.fc42.noarch. Cannot perform Install action, no match for: intel-audio-firmware-20250410-1.fc42.noarch. Cannot perform Install action, no match for: iwlwifi-mvm-firmware-20250410-1.fc42.noarch. Cannot perform Install action, no match for: tiwilink-firmware-20250410-1.fc42.noarch. Cannot perform Install action, no match for: mt7xxx-firmware-20250410-1.fc42.noarch. Cannot perform Install action, no match for: amd-ucode-firmware-20250410-1.fc42.noarch. Cannot perform Install action, no match for: linux-firmware-20250410-1.fc42.noarch. Cannot perform Install action, no match for: realtek-firmware-20250410-1.fc42.noarch. Cannot perform Install action, no match for: libertas-firmware-20250410-1.fc42.noarch. Cannot perform Install action, no match for: linux-firmware-whence-20250410-1.fc42.noarch. Cannot perform Install action, no match for: nvidia-gpu-firmware-20250410-1.fc42.noarch. You can try to add to command line: --skip-unavailable to skip unavailable packages And this bug prevented me from working this morning, so it is pretty urgent for everybody with Thinkpad T14 AMD Gen 6 and Fedora 42. I saw the same update for Fedora 41 in bodhi, so the same might apply there.
*** Bug 2366235 has been marked as a duplicate of this bug. ***
Same here on Lenovo ThinkPad T14s Gen 6 (AMD Strix Point)
Same issue here on my Lenovo ThinkPad T14s Gen 6 AMD. Down hard and can't work.
Can confirm the same issue on Thinkpad t14 gen 5 AMD with Qualcomm WCN785x WiFi. May 14 19:18:58 thinkfedora kernel: r8152 2-2.4:1.0 enp102s0u2u4: carrier on May 14 19:18:58 thinkfedora kernel: ath12k_pci 0000:02:00.0: failed to receive wmi unified ready event: -110 May 14 19:18:58 thinkfedora kernel: ath12k_pci 0000:02:00.0: failed to start core: -110 May 14 19:18:58 thinkfedora kernel: failed to send QMI message May 14 19:18:58 thinkfedora kernel: ath12k_pci 0000:02:00.0: qmi failed to send mode request, mode: 4, err = -5 May 14 19:18:58 thinkfedora kernel: ath12k_pci 0000:02:00.0: qmi failed to send wlan mode off May 14 19:19:04 thinkfedora kernel: [drm] DMUB HPD RX IRQ callback: link_index=7
Same here having the same issue with T14 Gen 5 AMD using Qualcomm Wi-Fi 7 WCN785x. Using Fedora 42 and Linux kernel 6.14.6-300.fc42.x86_64. Tried to downgrade but seems dnf's repository packages only have 'kernel.x86_64 6.14.0-63.fc42' as the oldest kernel version. Anyone find any other ways to temporarily fix the issue?
(In reply to Daniel Hakim Jamaluddin from comment #8) > Same here having the same issue with T14 Gen 5 AMD using Qualcomm Wi-Fi 7 > WCN785x. > Using Fedora 42 and Linux kernel 6.14.6-300.fc42.x86_64. > > Tried to downgrade but seems dnf's repository packages only have > 'kernel.x86_64 6.14.0-63.fc42' as the oldest kernel version. > > Anyone find any other ways to temporarily fix the issue? I didn't downgrade the kernel, just the firmware and it works perfectly... $ sudo dnf downgrade atheros-firmware-20250311-1.fc42
(In reply to lbtrs1911 from comment #9) > (In reply to Daniel Hakim Jamaluddin from comment #8) > > Same here having the same issue with T14 Gen 5 AMD using Qualcomm Wi-Fi 7 > > WCN785x. > > Using Fedora 42 and Linux kernel 6.14.6-300.fc42.x86_64. > > > > Tried to downgrade but seems dnf's repository packages only have > > 'kernel.x86_64 6.14.0-63.fc42' as the oldest kernel version. > > > > Anyone find any other ways to temporarily fix the issue? > > I didn't downgrade the kernel, just the firmware and it works perfectly... > > $ sudo dnf downgrade atheros-firmware-20250311-1.fc42 It works perfectly on my side too. Thank you. I thought I need to downgrade the kernel to restore the previous state for the driver.
Downgrading firmware doesn't seem to work here with rawhide kernels FWIW.
FWIW, I build 6.15-rc7 on fc42. WiFi failed to start with the latest atheros-firmware but downgrading it is working.
> Wouldn't it be better to revert the update? It took me over an hour to find the right RPM package and finally this BZ report. I don't think all Fedora users can do it :-/ > And this bug prevented me from working this morning, so it is pretty urgent for everybody with Thinkpad T14 AMD Gen 6 and Fedora 42. I saw the same update for Fedora 41 in bodhi, so the same might apply there. I 100% agree with this. I upgraded this morning, and it prevented me from working. It's baffling to me that this is known for a week now, but the latest release still keeps breaking people's computers. Btw, I'm on ThinkPad T14s AMD Gen 6 with Fedora 41.
We're still testing to confirm - but Qualcomm are pointing at this patch as a fix: https://web.git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git/commit/?id=1ab2e9046b4f3b298274ad4cc08ff456d3e4274e Mark
FWIW, downgrade is actually working here now. I mistakenly had some old (non compressed) versions in place and they were loaded over the xz compressed ones. ;(
Mark Pearson, I added that commit to my build for both 6.14.7 and 6.15-rc7 and on both builds WiFi failed to initialize on boot. I get the same dmesg entries that I normally see when I boot without downgrading the firmware: May 22 18:46:50 lambtop kernel: ath12k_pci 0000:c2:00.0: BAR 0 [mem 0xb0600000-0xb07fffff 64bit]: assigned May 22 18:46:50 lambtop kernel: ath12k_pci 0000:c2:00.0: enabling device (0000 -> 0002) May 22 18:46:50 lambtop kernel: ath12k_pci 0000:c2:00.0: MSI vectors: 16 May 22 18:46:50 lambtop kernel: ath12k_pci 0000:c2:00.0: Hardware name: wcn7850 hw2.0 May 22 18:46:51 lambtop kernel: ath12k_pci 0000:c2:00.0: chip_id 0x2 chip_family 0x4 board_id 0xff soc_id 0x40170200 May 22 18:46:51 lambtop kernel: ath12k_pci 0000:c2:00.0: fw_version 0x1105811c fw_build_timestamp 2025-03-11 07:08 fw_build_id QC_IMAGE_VERSION_STRING=WLAN.HMT.1.1.c5-00284-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 May 22 18:46:51 lambtop kernel: ath12k_pci 0000:c2:00.0: ignore reset dev flags 0x200 May 22 18:46:56 lambtop kernel: ath12k_pci 0000:c2:00.0: failed to receive wmi unified ready event: -110 May 22 18:46:56 lambtop kernel: ath12k_pci 0000:c2:00.0: failed to start core: -110 May 22 18:46:56 lambtop kernel: ath12k_pci 0000:c2:00.0: qmi failed to send mode request, mode: 4, err = -5 May 22 18:46:56 lambtop kernel: ath12k_pci 0000:c2:00.0: qmi failed to send wlan mode off I do wonder though if this might help (or even fix?) this bug: https://bugzilla.redhat.com/show_bug.cgi?id=2367697 That bug is a NULL pointer access in ath12k_scan_vdev_clean_work which is the function mentioned in the commit message as getting called after the avrif has already been released.
A fix has been landed upstream. You can pick it up here. https://gitlab.com/kernel-firmware/linux-firmware/-/commit/2e91d8c3c4bd34a27177180a38f62d3ba3c96031
This didn't fix it for me running fc42 with a custom 6.15-rc7 kernel: May 23 14:57:49 lambtop kernel: ath12k_pci 0000:c2:00.0: BAR 0 [mem 0xb0600000-0xb07fffff 64bit]: assigned May 23 14:57:49 lambtop kernel: ath12k_pci 0000:c2:00.0: enabling device (0000 -> 0002) May 23 14:57:49 lambtop kernel: ath12k_pci 0000:c2:00.0: MSI vectors: 16 May 23 14:57:49 lambtop kernel: ath12k_pci 0000:c2:00.0: Hardware name: wcn7850 hw2.0 May 23 14:57:49 lambtop kernel: ath12k_pci 0000:c2:00.0: chip_id 0x2 chip_family 0x4 board_id 0xff soc_id 0x40170200 May 23 14:57:49 lambtop kernel: ath12k_pci 0000:c2:00.0: fw_version 0x1108811c fw_build_timestamp 2025-05-17 00:21 fw_build_id QC_IMAGE_VERSION_STRING=WLAN.HMT.1.1.c5-00284.1-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 May 23 14:57:49 lambtop kernel: ath12k_pci 0000:c2:00.0: invalid ACPI DSM TAS config size: 1 May 23 14:57:49 lambtop kernel: ath12k_pci 0000:c2:00.0: failed to get ACPI TAS config table: -22 May 23 14:57:50 lambtop kernel: ath12k_pci 0000:c2:00.0: ignore reset dev flags 0x200 May 23 14:57:55 lambtop kernel: ath12k_pci 0000:c2:00.0: failed to receive wmi unified ready event: -110 May 23 14:57:55 lambtop kernel: ath12k_pci 0000:c2:00.0: failed to start core: -110 May 23 14:57:55 lambtop kernel: ath12k_pci 0000:c2:00.0: qmi failed to send mode request, mode: 4, err = -5 May 23 14:57:55 lambtop kernel: ath12k_pci 0000:c2:00.0: qmi failed to send wlan mode off
(In reply to Christopher R. Palmer from comment #19) > This didn't fix it for me running fc42 with a custom 6.15-rc7 kernel: > > May 23 14:57:49 lambtop kernel: ath12k_pci 0000:c2:00.0: BAR 0 [mem > 0xb0600000-0xb07fffff 64bit]: assigned > May 23 14:57:49 lambtop kernel: ath12k_pci 0000:c2:00.0: enabling device > (0000 -> 0002) > May 23 14:57:49 lambtop kernel: ath12k_pci 0000:c2:00.0: MSI vectors: 16 > May 23 14:57:49 lambtop kernel: ath12k_pci 0000:c2:00.0: Hardware name: > wcn7850 hw2.0 > May 23 14:57:49 lambtop kernel: ath12k_pci 0000:c2:00.0: chip_id 0x2 > chip_family 0x4 board_id 0xff soc_id 0x40170200 > May 23 14:57:49 lambtop kernel: ath12k_pci 0000:c2:00.0: fw_version > 0x1108811c fw_build_timestamp 2025-05-17 00:21 fw_build_id > QC_IMAGE_VERSION_STRING=WLAN.HMT.1.1.c5-00284.1-QCAHMTSWPL_V1.0_V2. > 0_SILICONZ-3 > May 23 14:57:49 lambtop kernel: ath12k_pci 0000:c2:00.0: invalid ACPI DSM > TAS config size: 1 > May 23 14:57:49 lambtop kernel: ath12k_pci 0000:c2:00.0: failed to get ACPI > TAS config table: -22 > May 23 14:57:50 lambtop kernel: ath12k_pci 0000:c2:00.0: ignore reset dev > flags 0x200 > May 23 14:57:55 lambtop kernel: ath12k_pci 0000:c2:00.0: failed to receive > wmi unified ready event: -110 > May 23 14:57:55 lambtop kernel: ath12k_pci 0000:c2:00.0: failed to start > core: -110 > May 23 14:57:55 lambtop kernel: ath12k_pci 0000:c2:00.0: qmi failed to send > mode request, mode: 4, err = -5 > May 23 14:57:55 lambtop kernel: ath12k_pci 0000:c2:00.0: qmi failed to send > wlan mode off It works for me, you can try this tree : https://git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git/
Ummm, no thank you? It's sad that my Lenovo laptop's wifi driver works in an obselete kernel (6.13), doesn't work in the latest stable (6.14) and doesn't work in the next rc (6.15-rc7). I say no thank you because: $ git diff --stat v6.15-rc7 ath/master drivers/net/wireless/ath/ath12k/ | cat drivers/net/wireless/ath/ath12k/Kconfig | 8 + drivers/net/wireless/ath/ath12k/Makefile | 1 + drivers/net/wireless/ath/ath12k/ahb.c | 1155 ++++++++++++++++ drivers/net/wireless/ath/ath12k/ahb.h | 80 ++ drivers/net/wireless/ath/ath12k/ce.c | 103 +- drivers/net/wireless/ath/ath12k/ce.h | 18 +- drivers/net/wireless/ath/ath12k/core.c | 329 ++++- drivers/net/wireless/ath/ath12k/core.h | 169 ++- drivers/net/wireless/ath/ath12k/debugfs.c | 497 +++++-- drivers/net/wireless/ath/ath12k/debugfs.h | 17 +- .../net/wireless/ath/ath12k/debugfs_htt_stats.c | 3 + drivers/net/wireless/ath/ath12k/dp.c | 154 ++- drivers/net/wireless/ath/ath12k/dp.h | 53 +- drivers/net/wireless/ath/ath12k/dp_mon.c | 1097 ++++++++++++++- drivers/net/wireless/ath/ath12k/dp_mon.h | 8 +- drivers/net/wireless/ath/ath12k/dp_rx.c | 596 +++++--- drivers/net/wireless/ath/ath12k/dp_rx.h | 41 +- drivers/net/wireless/ath/ath12k/dp_tx.c | 209 ++- drivers/net/wireless/ath/ath12k/dp_tx.h | 3 +- drivers/net/wireless/ath/ath12k/fw.c | 9 +- drivers/net/wireless/ath/ath12k/fw.h | 3 +- drivers/net/wireless/ath/ath12k/hal.c | 153 ++- drivers/net/wireless/ath/ath12k/hal.h | 80 +- drivers/net/wireless/ath/ath12k/hal_desc.h | 13 +- drivers/net/wireless/ath/ath12k/hal_rx.c | 121 +- drivers/net/wireless/ath/ath12k/hal_rx.h | 27 +- drivers/net/wireless/ath/ath12k/hw.c | 511 ++++++- drivers/net/wireless/ath/ath12k/hw.h | 30 +- drivers/net/wireless/ath/ath12k/mac.c | 1439 +++++++++++++++----- drivers/net/wireless/ath/ath12k/mac.h | 56 + drivers/net/wireless/ath/ath12k/mhi.c | 9 +- drivers/net/wireless/ath/ath12k/pci.c | 66 +- drivers/net/wireless/ath/ath12k/pci.h | 5 +- drivers/net/wireless/ath/ath12k/peer.c | 5 +- drivers/net/wireless/ath/ath12k/peer.h | 3 +- drivers/net/wireless/ath/ath12k/qmi.c | 238 +++- drivers/net/wireless/ath/ath12k/qmi.h | 5 +- drivers/net/wireless/ath/ath12k/reg.c | 526 ++++--- drivers/net/wireless/ath/ath12k/reg.h | 20 +- drivers/net/wireless/ath/ath12k/testmode.c | 4 +- drivers/net/wireless/ath/ath12k/wmi.c | 558 ++++++-- drivers/net/wireless/ath/ath12k/wmi.h | 119 +- 42 files changed, 7099 insertions(+), 1442 deletions(-)
(In reply to Christopher R. Palmer from comment #21) > Ummm, no thank you? It's sad that my Lenovo laptop's wifi driver works in > an obselete kernel (6.13), doesn't work in the latest stable (6.14) and > doesn't work in the next rc (6.15-rc7). > > I say no thank you because: > > $ git diff --stat v6.15-rc7 ath/master drivers/net/wireless/ath/ath12k/ | cat > drivers/net/wireless/ath/ath12k/Kconfig | 8 + > drivers/net/wireless/ath/ath12k/Makefile | 1 + > drivers/net/wireless/ath/ath12k/ahb.c | 1155 ++++++++++++++++ > drivers/net/wireless/ath/ath12k/ahb.h | 80 ++ > drivers/net/wireless/ath/ath12k/ce.c | 103 +- > drivers/net/wireless/ath/ath12k/ce.h | 18 +- > drivers/net/wireless/ath/ath12k/core.c | 329 ++++- > drivers/net/wireless/ath/ath12k/core.h | 169 ++- > drivers/net/wireless/ath/ath12k/debugfs.c | 497 +++++-- > drivers/net/wireless/ath/ath12k/debugfs.h | 17 +- > .../net/wireless/ath/ath12k/debugfs_htt_stats.c | 3 + > drivers/net/wireless/ath/ath12k/dp.c | 154 ++- > drivers/net/wireless/ath/ath12k/dp.h | 53 +- > drivers/net/wireless/ath/ath12k/dp_mon.c | 1097 ++++++++++++++- > drivers/net/wireless/ath/ath12k/dp_mon.h | 8 +- > drivers/net/wireless/ath/ath12k/dp_rx.c | 596 +++++--- > drivers/net/wireless/ath/ath12k/dp_rx.h | 41 +- > drivers/net/wireless/ath/ath12k/dp_tx.c | 209 ++- > drivers/net/wireless/ath/ath12k/dp_tx.h | 3 +- > drivers/net/wireless/ath/ath12k/fw.c | 9 +- > drivers/net/wireless/ath/ath12k/fw.h | 3 +- > drivers/net/wireless/ath/ath12k/hal.c | 153 ++- > drivers/net/wireless/ath/ath12k/hal.h | 80 +- > drivers/net/wireless/ath/ath12k/hal_desc.h | 13 +- > drivers/net/wireless/ath/ath12k/hal_rx.c | 121 +- > drivers/net/wireless/ath/ath12k/hal_rx.h | 27 +- > drivers/net/wireless/ath/ath12k/hw.c | 511 ++++++- > drivers/net/wireless/ath/ath12k/hw.h | 30 +- > drivers/net/wireless/ath/ath12k/mac.c | 1439 > +++++++++++++++----- > drivers/net/wireless/ath/ath12k/mac.h | 56 + > drivers/net/wireless/ath/ath12k/mhi.c | 9 +- > drivers/net/wireless/ath/ath12k/pci.c | 66 +- > drivers/net/wireless/ath/ath12k/pci.h | 5 +- > drivers/net/wireless/ath/ath12k/peer.c | 5 +- > drivers/net/wireless/ath/ath12k/peer.h | 3 +- > drivers/net/wireless/ath/ath12k/qmi.c | 238 +++- > drivers/net/wireless/ath/ath12k/qmi.h | 5 +- > drivers/net/wireless/ath/ath12k/reg.c | 526 ++++--- > drivers/net/wireless/ath/ath12k/reg.h | 20 +- > drivers/net/wireless/ath/ath12k/testmode.c | 4 +- > drivers/net/wireless/ath/ath12k/wmi.c | 558 ++++++-- > drivers/net/wireless/ath/ath12k/wmi.h | 119 +- > 42 files changed, 7099 insertions(+), 1442 deletions(-) It looks like this firmware is only compatible with a driver that hasn’t been merged yet, which explains why it’s not working for you. You need at least ath-20250424.
Thanks for the details - reviewing with the Qualcomm engineers. For our internal testing the ath.git tree worked, but trying to figure out all the combo's kernel vs FW and to see if other upstream fixes are also needed. If we can identify which are the critical fixes needed I'll look to get those pulled into Fedora more quickly.
Following this, as I have the same exact problem with my brand new T14s, let me know if you need any details.
Update from Qualcomm: For the load failure, FW needs to be upgraded to https://git.codelinaro.org/clo/ath-firmware/ath12k-firmware/-/tree/main/WCN7850/hw2.0/1.1/WLAN.HMT.1.1.c5-00284.1-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3?ref_type=heads For the kernel crash, the patch needs to be merged from the commit https://web.git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git/commit/?id=1ab2e9046b4f3b298274ad4cc08ff456d3e4274e The amss.bin FW file is also in linux-firmware (https://gitlab.com/kernel-firmware/linux-firmware/-/commit/2e91d8c3c4bd34a27177180a38f62d3ba3c96031) - not in Fedora yet that I can tell We haven't tested this yet - it's in progress. Mark
> The amss.bin FW file is also in linux-firmware > (https://gitlab.com/kernel-firmware/linux-firmware/-/commit/ > 2e91d8c3c4bd34a27177180a38f62d3ba3c96031) - not in Fedora yet that I can tell It's not, I'm awaiting a complete and confirmed fix. It's easy enough for users to downgrade ATM, and that currently feels like the most straight forward fix. linux-firmware is a large update so I won't push until I know I have a complete fix as it's unfair to force everyone to update unecessarily.
(In reply to Peter Robinson from comment #26) > > The amss.bin FW file is also in linux-firmware > > (https://gitlab.com/kernel-firmware/linux-firmware/-/commit/ > > 2e91d8c3c4bd34a27177180a38f62d3ba3c96031) - not in Fedora yet that I can tell > > It's not, I'm awaiting a complete and confirmed fix. It's easy enough for > users to downgrade ATM, and that currently feels like the most straight > forward fix. linux-firmware is a large update so I won't push until I know I > have a complete fix as it's unfair to force everyone to update unecessarily. I agree. The older version is usable, even if a bit unstable.
(In reply to Peter Robinson from comment #26) > > The amss.bin FW file is also in linux-firmware > > (https://gitlab.com/kernel-firmware/linux-firmware/-/commit/ > > 2e91d8c3c4bd34a27177180a38f62d3ba3c96031) - not in Fedora yet that I can tell > > It's not, I'm awaiting a complete and confirmed fix. It's easy enough for > users to downgrade ATM, and that currently feels like the most straight > forward fix. linux-firmware is a large update so I won't push until I know I > have a complete fix as it's unfair to force everyone to update unecessarily. Agreed and understood. We're doing some testing here too (specifically with Fedora). Will update when we have some results
(In reply to Mark Pearson from comment #25) > For the kernel crash, the patch needs to be merged from the commit > https://web.git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git/commit/ > ?id=1ab2e9046b4f3b298274ad4cc08ff456d3e4274e I have been running this patch for a week now (6.15) with no crashes. I was having multiple crashes a day on both 6.14 and 6.15 before applying it.
v3 here is the one that seems to be heading upstream but it's not yet in 6.16/master https://patchwork.kernel.org/project/linux-wireless/patch/20250418064008.7172-1-quic_lingbok@quicinc.com/
Looks like the patch has been merged into master: https://github.com/torvalds/linux/commit/1ab2e9046b4f3b298274ad4cc08ff456d3e4274e Any idea when to expect a backport of the fix in f42? Would be nice to finally have wifi working reliably
Is that patch + the new firmware alone enough? If so; it should be sent up to the stable M/L per the stable rules: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html I suggest grabbing the F42 kernel, adding that patch and testing to confirm.
I'm looking at testing it. Initial results were not good - I think another patch is needed but am trying to identify what (bisect on the ath tree is pretty painful unfortunately - lots of build breaks). Once I've tested and confirmed what is needed, and if it looks good, I'll look into doing a MR for Fedora. Not sure why they didn't tag for stable upstream - will check with Qualcomm on that
(In reply to Mark Pearson from comment #33) > I'm looking at testing it. Initial results were not good - I think another > patch is needed but am trying to identify what (bisect on the ath tree is > pretty painful unfortunately - lots of build breaks). > > Once I've tested and confirmed what is needed, and if it looks good, I'll > look into doing a MR for Fedora. > Not sure why they didn't tag for stable upstream - will check with Qualcomm > on that What didn't got well with the initial testing? Firmware loading or system stability? I installed the older firmware for all my testing. In terms of the system stability, with this patch, I've been running 6.15.0 (and the rc's before it) for about 10-14 days without issue. I switched to 6.14.9 (with the patch) for a couple of days and had two instances where my T14s G6 AMD didn't wake up properly after sleeping. There was nothing to note in journalctl -b -1 -k in either case. I gave up the 6.14 branch for now. I did wonder if there were lingering AMD GPU issues in the 6.14 branch that could have been the cause of what I experienced rather than of it being yet more ath12k problems.
> What didn't got well with the initial testing? Firmware loading or system > stability? It's not a clean apply. > I installed the older firmware for all my testing. Well that invalidated everything. Unfortunately we need the patches and the new firmware to move forward. I will not push anything until I am satisfied.
(In reply to Peter Robinson from comment #35) > > What didn't got well with the initial testing? Firmware loading or system > > stability? > > It's not a clean apply. That's true, but my resolution of the conflict did end up being the same as what was committed in master. > > I installed the older firmware for all my testing. > > Well that invalidated everything. Not entirely. It says that this commit does resolve a kernel crash that was easily reproducible (put the laptop to sleep, open the lid for 2 seconds and close it). It also says that 6.14.9 is still not stable even with this fix. It also says that the firmware loading issue is unrelated to this commit. > Unfortunately we need the patches and the new firmware to move forward. I > will not push anything until I am satisfied. I wholeheartedly agree with that statement, I am merely providing information in the hopes of helping for the sake of those that don't currently have a stable system.
> Unfortunately we need the patches and the new firmware to move forward. >I will not push anything until I am satisfied. No issue with that statement but can anyone epxlain why the official fedora update repo still offers atheros-firmware-20250509-1.fc42 when it is known for at least 3 weeks that it doesn't work with the current fedora kernel? Feel free to explain like i'm 5 as i really don't see why this is the right thing to do. To the maintainers: Please don't take that personally and as you probably do not hear it often enough 'Thank you for all the hard work keeping Fedora working and making it better'
From testing (not extensive but quite a few suspends/resume cycles): - 6.14 Fedora kernel + series https://patchwork.kernel.org/project/linux-wireless/cover/20250204-unlink_link_arvif_from_chanctx-v2-0-764fb5973c1a@oss.qualcomm.com/ - 'Newer' FW (https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/ath12k/WCN7850/hw2.0). I believe this is what is in the Fedora repo's right now. My wifi is working and doesn't crash on suspend and resume. Main thing of note is the signal strength in Gnome isn't always displaying correctly - but nmcli is fine so I'm going to assume that's a Gnome thing and unrelated. Peter - Does it makes sense if I go ahead and do a MR for this in the 6.14 kernel? I think (hope) that will give us some stability until 6.15 is out (which admittedly is probably soon) I'm a bit concerned that I also need this commit (https://web.git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git/commit/?id=1ab2e9046b4f3b298274ad4cc08ff456d3e4274e) which Qualcomm flagged; but at least in my testing everything is working (and it doesn't apply cleanly to Fedora 6.14) so I skipped it. If anybody else is able to sanity check my results that would be helpful (I can share an RPM if that would be helpful) Thanks Mark
FYI the wifi signal showing with 1 bar occurs to me too, and my install is 100% from the repos (The only divergence is atheros-firmware running the older version).
(In reply to Mark Pearson from comment #38) > I'm a bit concerned that I also need this commit > (https://web.git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git/commit/ > ?id=1ab2e9046b4f3b298274ad4cc08ff456d3e4274e) which Qualcomm flagged; but at > least in my testing everything is working (and it doesn't apply cleanly to > Fedora 6.14) so I skipped it. > If anybody else is able to sanity check my results that would be helpful (I > can share an RPM if that would be helpful) My testing indicated that it was absolutely necessary. Without this commit, I could easily crash my kernel by repeating this process: * close lid * wait for device to enter sleep state (flashing led on cover) * open lid, don't login or anything else that takes time * wait 2 seconds * close lid * wait This sequence causes a scan to occur (when you wake up the laptop, the wifi must start a scan to connect but closing the lid again causes the scan to not have a chance to complete before removing the link to go to sleep) which, for me, triggers the bug being fixed in the mentioned commit.
Would you mind trying https://drive.google.com/file/d/1-jB5GqrqGE36z9CWxmjsO5x01nBO4h20/view?usp=sharing - it's the kernel I built. I've tried those same steps, and am not seeing the issue. Would love to get confirmation if I'm just missing something. Kernel is built from kernel-ark repo, fedora-6.14 branch, with the series highlighted above applied. It can take a while for the system to go to sleep (20s?) - but no crashes and it resumes quickly I should note - I have a trial BIOS on my system (testing a fix for the T14s G6 waking up when power is removed). I don't think it should have any impact on this issue though as that's a USB-c port power issue. Mark
(In reply to Mark Pearson from comment #41) > Would you mind trying > https://drive.google.com/file/d/1-jB5GqrqGE36z9CWxmjsO5x01nBO4h20/ > view?usp=sharing - it's the kernel I built. > I've tried those same steps, and am not seeing the issue. Would love to get > confirmation if I'm just missing something. > > Kernel is built from kernel-ark repo, fedora-6.14 branch, with the series > highlighted above applied. > It can take a while for the system to go to sleep (20s?) - but no crashes > and it resumes quickly > > I should note - I have a trial BIOS on my system (testing a fix for the T14s > G6 waking up when power is removed). I don't think it should have any impact > on this issue though as that's a USB-c port power issue. I can confirm that your kernel does appear to fix the crash as I haven't been able to reproduce it. At this point, I'm guessing that the commit that you are unsure about adding to the patch set was actually a bandaid that solved the original crash. But, perhaps, the underlying problem was the incorrect handling of link removal that looks like it was fixed in this patch set. Not that my opinion matters, but I think you're right to be reluctant to include the additional patch at this time. This was tested with the latest firmware (not the current fedora 42 version but the updated version that was released to fix the firmware crash: WLAN.HMT.1.1.c5-00284.1-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3). I believe this is the same version you were using. FWIW, I also get incorrect signal strength reporting in gnome. Both before and after this set of patches in 6.14. I do not see it in 6.15 which makes me think it's a problem with the 6.14 driver but also unrelated to this problem. Strangely, 6.15 contains the set of patches that fix the problems for 6.14 but, at least in my builds, I cannot load the latest firmware in 6.15. I have to revert to the 202503... version of the firmware to get WiFi working in 6.15.
(In reply to Steve Cossette from comment #39) > FYI the wifi signal showing with 1 bar occurs to me too, and my install is > 100% from the repos (The only divergence is atheros-firmware running the > older version). I see the problem with wifi signal in gnome even with ath11k on the Lenovo x13s. I don't think that problem is related to this one.
(In reply to Peter Robinson from comment #43) > (In reply to Steve Cossette from comment #39) > > FYI the wifi signal showing with 1 bar occurs to me too, and my install is > > 100% from the repos (The only divergence is atheros-firmware running the > > older version). > > I see the problem with wifi signal in gnome even with ath11k on the Lenovo > x13s. I don't think that problem is related to this one. I agree that the signal strength problem is not related to this bug, but it may be yet another atheros driver issue. For the record on 2 lenovo laptops: T14s G6 (AMD) w/ ath12k * 6.14.x has this problem * 6.15.x does not have this problem * 6.13.x did not have this problem T14s G6 (Intel) w/ BE02 (?) * 6.14.9 does not have this problem
> - 6.14 Fedora kernel + series > https://patchwork.kernel.org/project/linux-wireless/cover/20250204- > unlink_link_arvif_from_chanctx-v2-0-764fb5973c1a.com/ So this series is in 6.15. We have a 6.15.1 kernel for test week here, it would be useful to get confirmation from people this build fixes the issue: https://koji.fedoraproject.org/koji/buildinfo?buildID=2727708 > - 'Newer' FW > (https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/ > tree/ath12k/WCN7850/hw2.0). I believe this is what is in the Fedora repo's > right now. No, I think it's upstream and will be in the 202506 upstream release due any moment. > Main thing of note is the signal strength in Gnome isn't always displaying > correctly - but nmcli is fine so I'm going to assume that's a Gnome thing > and unrelated. As mentioned I see this also with ath11k on the x13s on gnome. It should be tracked separately against the kernel and not pollute this. > Peter - Does it makes sense if I go ahead and do a MR for this in the 6.14 > kernel? I think (hope) that will give us some stability until 6.15 is out > (which admittedly is probably soon) As mentioned above 6.15 is already in testing so I suspect by the time I get FW done it'll be almost here, let me check in and see what timelines are and coordinate with firmware updates. > I'm a bit concerned that I also need this commit > (https://web.git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git/commit/ > ?id=1ab2e9046b4f3b298274ad4cc08ff456d3e4274e) which Qualcomm flagged; This is upstream in 6.16 but it doesn't apply cleanly to 6.15, let alone 6.14, let's get confirmation as to what 6.15.1 looks like and we can revisit.
(In reply to Peter Robinson from comment #45) > > - 6.14 Fedora kernel + series > > https://patchwork.kernel.org/project/linux-wireless/cover/20250204- > > unlink_link_arvif_from_chanctx-v2-0-764fb5973c1a.com/ > > So this series is in 6.15. We have a 6.15.1 kernel for test week here, it > would be useful to get confirmation from people this build fixes the issue: > https://koji.fedoraproject.org/koji/buildinfo?buildID=2727708 Using the "newer" firmware (exact version below) and this kernel, the ath12k driver fails to initialize and WiFi is completely broken (ath12 T14s G6 AMD): Linux version 6.15.1-200.fc42.x86_64 (mockbuild@cbd98297be28464d8a272d5d674f697e) (gcc (GCC) 15.1.1 20250521 (Red Hat 15.1.1-2), GNU ld version 2.44-3.fc42) #1 SMP PREEMPT_DYNAMIC Fri Jun 6 09:32:26 UTC 2025 $ sudo dmesg | grep ath12k [sudo] password for crpalmer: [ 4.493183] ath12k_pci 0000:c2:00.0: BAR 0 [mem 0xb0600000-0xb07fffff 64bit]: assigned [ 4.493201] ath12k_pci 0000:c2:00.0: enabling device (0000 -> 0002) [ 4.493524] ath12k_pci 0000:c2:00.0: MSI vectors: 16 [ 4.493533] ath12k_pci 0000:c2:00.0: Hardware name: wcn7850 hw2.0 [ 5.033361] ath12k_pci 0000:c2:00.0: chip_id 0x2 chip_family 0x4 board_id 0xff soc_id 0x40170200 [ 5.033372] ath12k_pci 0000:c2:00.0: fw_version 0x1108811c fw_build_timestamp 2025-05-17 00:21 fw_build_id QC_IMAGE_VERSION_STRING=WLAN.HMT.1.1.c5-00284.1-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 [ 5.034012] ath12k_pci 0000:c2:00.0: invalid ACPI DSM TAS config size: 1 [ 5.034015] ath12k_pci 0000:c2:00.0: failed to get ACPI TAS config table: -22 [ 5.321963] ath12k_pci 0000:c2:00.0: ignore reset dev flags 0x200 [ 10.281780] ath12k_pci 0000:c2:00.0: failed to receive wmi unified ready event: -110 [ 10.282331] ath12k_pci 0000:c2:00.0: failed to start core: -110 [ 10.285173] ath12k_pci 0000:c2:00.0: qmi failed to send mode request, mode: 4, err = -5 [ 10.285174] ath12k_pci 0000:c2:00.0: qmi failed to send wlan mode off
> > So this series is in 6.15. We have a 6.15.1 kernel for test week here, it > > would be useful to get confirmation from people this build fixes the issue: > > https://koji.fedoraproject.org/koji/buildinfo?buildID=2727708 > > Using the "newer" firmware (exact version below) and this kernel, the ath12k > driver fails to initialize and WiFi is completely broken (ath12 T14s G6 AMD): Mark can you test 6.15.x + new firmware on your setup please. Probably also worth trying 6.16-rc1
Confirmed Fedora 6.15 isn't working for me either (same error messages). Will debug and find the fix (dammit)
(In reply to Mark Pearson from comment #48) > Confirmed Fedora 6.15 isn't working for me either (same error messages). > Will debug and find the fix (dammit) These two reverts: commit 83d5cc3cf9567cae6dfb3f0ea860e13e2c65d960 (HEAD -> crp-6.15) Author: Christopher R. Palmer <crpalmer> Date: Tue Jun 10 16:10:27 2025 -0400 Revert "wifi: ath12k: Enable MLO for single split-phy PCI device" This reverts commit 4f4bd1f8a5c2f7b1b24ecc553033b210de2a0513. commit 32e1b4d27854eeb6044f6438564cc1aa09cb7bc1 Author: Christopher R. Palmer <crpalmer> Date: Tue Jun 10 16:01:58 2025 -0400 Revert "wifi: ath12k: Remove dependency on single_chip_mlo_support for mlo_capable flag" This reverts commit 7082013fa53bf583f12d380aba2dd009b74d265e. allow the firmware to load and I have WiFi working here. I haven't tested it much yet and I haven't tested the stability. I will do some more testing later, but I wanted to share my results in case it helps and gives you something to talk to Qualcomm about if you can verify what I'm seeing. It is worth noting that these two commits were tested against Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 but no mention of testing on WCN7850.
Thanks Christopher - will follow up with Qualcomm. Those are very useful As an extra data point on my side - 6.16-rc1 is working nicely. Looked quickly at the logs and I'm guessing https://github.com/torvalds/linux/commit/32f7b19668bd2894f1a236580c2132fc4b9f4449 will be important Mark
(In reply to Mark Pearson from comment #50) > Thanks Christopher - will follow up with Qualcomm. Those are very useful > > As an extra data point on my side - 6.16-rc1 is working nicely. > Looked quickly at the logs and I'm guessing > https://github.com/torvalds/linux/commit/ > 32f7b19668bd2894f1a236580c2132fc4b9f4449 will be important The last time I tried 6.16 I saw frequent CPU spikes from NetworkManager and I decided to wait another rc or so to try it more extensively. I'm glad to hear it's working well for you. That MLO commit does look very promising. Cherry picking it and the two commits needed to get it to compile: wifi: ath12k: support MLO as well if single_chip_mlo_support flag is set wifi: ath12k: use fw_features only when it is valid wifi: ath12k: introduce ath12k_fw_feature_supported() appears to be working as a better alternative to my reverts on 6.15.
Thanks Christopher - that made my life easier :) Confirmed those patches work (I picked up the reset-MLO-global-memory-during-recovery patch too as it looked important, but maybe not needed) I'll review with Qualcomm and get this backported to the 6.15 kernel once they give the thumbs up. Not seeing any CPU spikes so far - how frequently do they occur? I'll keep an eye out for them Mark
(In reply to Mark Pearson from comment #52) > Thanks Christopher - that made my life easier :) Confirmed those patches > work (I picked up the reset-MLO-global-memory-during-recovery patch too as > it looked important, but maybe not needed) > > I'll review with Qualcomm and get this backported to the 6.15 kernel once > they give the thumbs up. > Not seeing any CPU spikes so far - how frequently do they occur? I'll keep > an eye out for them Weird. My NetworkManager is very active (uptime of 11 minutes, 5 minutes of CPU time for NetworkManager): 13:15:06 up 11 min, 2 users, load average: 1.41, 1.43, 0.87 1107 ? Rsl 4:56 /usr/bin/NetworkManager --no-daemon I don't see anything in the logs (journalctl / dmesg) other than normal looking messages when I moved outside thereby causing the WiFi to roam to a new AP. I ended up going back to 6.15 after 17 minutes of uptime, 8:11 cpu time for NetworkManager and load averages were constantly above 1. I'm not going to bother to look at it any more but will keep checking the RCs to see if anything changes and watch for any updates to NetworkManager.
The NM CPU problem I suspect is fixed with this patch set: https://www.spinics.net/lists/linux-wireless/msg266885.html
> That MLO commit does look very promising. Cherry picking it and the two > commits needed to get it to compile: > > wifi: ath12k: support MLO as well if single_chip_mlo_support flag is set > wifi: ath12k: use fw_features only when it is valid > wifi: ath12k: introduce ath12k_fw_feature_supported() > > appears to be working as a better alternative to my reverts on 6.15. OK, so I pulled those 3 back to 6.15 and Justin has kindly kicked off a build for the 6.15 test week [1], the 6.14 upstream is now EOL so it's likely the next update kernel will be a 6.15 build once testing is done. There's also a new upstream linux-firmware tagged, I'm just working through some changes I need to make to that build process and I hope to have an official rawhide build for that later today. Once we have both of those builds done if we can get confirmation that the combo of kernel-6.15.2-201.fc42 + linux-firmware-20250613-1.fc43 fixes it I'll coordinate with Justin to push the new firmware with the 6.15 bump. [1] https://koji.fedoraproject.org/koji/buildinfo?buildID=2732058
Thanks Peter - I'm still waiting for confirmation from Qualcomm, but this sounds like a good plan to me. Will test when the builds are ready
OK, both kernel and new linux-firmware builds are complete. linux-firmware: https://koji.fedoraproject.org/koji/packageinfo?packageID=9736 Please test with kernel-6.15.2-201.fc42+ or kernel-6.16-rc1+ and report back.
(In reply to Peter Robinson from comment #55) > > That MLO commit does look very promising. Cherry picking it and the two > > commits needed to get it to compile: > > > > wifi: ath12k: support MLO as well if single_chip_mlo_support flag is set > > wifi: ath12k: use fw_features only when it is valid > > wifi: ath12k: introduce ath12k_fw_feature_supported() > > > > appears to be working as a better alternative to my reverts on 6.15. > > OK, so I pulled those 3 back to 6.15 and Justin has kindly kicked off a > build for the 6.15 test week [1], the 6.14 upstream is now EOL so it's > likely the next update kernel will be a 6.15 build once testing is done. > There's also a new upstream linux-firmware tagged, I'm just working through > some changes I need to make to that build process and I hope to have an > official rawhide build for that later today. > > Once we have both of those builds done if we can get confirmation that the > combo of kernel-6.15.2-201.fc42 + linux-firmware-20250613-1.fc43 fixes it > I'll coordinate with Justin to push the new firmware with the 6.15 bump. > > [1] https://koji.fedoraproject.org/koji/buildinfo?buildID=2732058 I just tested with the new 6.15-2 kernel that was built and the firmware from https://koji.fedoraproject.org/koji/packageinfo?packageID=9736 Everything is looking good to me here (T14s G6 AMD with WCN chipset).
Updated to the new f42 kernel (6.15.2-201.fc42.x86_64) along with the new firmware from https://koji.fedoraproject.org/koji/buildinfo?buildID=2732083 and so far so good: Rebooted and wifi is working. Will update later.
I can confirm that it works for me again on my MSI X870E Tomahawk motherboard too.
(In reply to Peter Robinson from comment #54) > The NM CPU problem I suspect is fixed with this patch set: > https://www.spinics.net/lists/linux-wireless/msg266885.html FWIW, I think you are correct. I pulled in the slightly larger set of changes from the master-pending branch of git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git f6c994a3230843a4d1cdcf16a2d639c0f4d5f3fb (ath/pending) wifi: ath12k: don't wait when there is no vdev started 1135b3b67de3c97761dcc9984dcbac3e84b44877 wifi: ath12k: don't use static variables in ath12k_wmi_fw_stats_process() 32ec6eb9625f333433040b5ca27aba9577af04d5 wifi: ath12k: avoid burning CPU while waiting for firmware stats 93ba393799a68f70824b36f9fa49425ec52a3400 wifi: ath12k: fix documentation on firmware stats cde5a321e44bfbed8379f791dca2d060d96eb29e wifi: ath12k: don't activate more links than firmware supports 21e828b3f79132d0efa3576f2d737beec4b29da1 wifi: ath12k: update link active in case two links fall on the same MAC 0792f546b22149fbd1799d01869054045a700eaf wifi: ath12k: support WMI_MLO_LINK_SET_ACTIVE_CMDID command 08a1904f6911c68b7bcdc54b0ba849265b83a878 wifi: ath12k: update freq range for each hardware mode 7f50d011ffe710a79a73ff48ab4e992d4cd903c7 wifi: ath12k: parse and save sbs_lower_band_end_freq from WMI_SERVICE_READY_EXT2_EVENTID event 351b38d02da553e74a1d5181fac7f36aa7b90a18 wifi: ath12k: parse and save hardware mode info from WMI_SERVICE_READY_EXT_EVENTID event for later use 31376d90efe3d3d8c67c394231e203e8a7f8d7b7 wifi: ath12k: Avoid CPU busy-wait by handling VDEV_STAT and BCN_STAT and the NetworkManager problem seems to have gone away. This makes 6.16 seem like it working fine for me.
FYI, the experience on 6.15.2 has been pretty flawless since yesterday. Still is a limited timespan for testing mind you, but "So far so good" *knock on wood*