On first time boot ath11k_pci loads well, wifi works. Then I execute rmmod ath11k_pci: [ 86.505243] wlan0: deauthenticating from 04:bf:6d:42:3b:f6 by local choice (Reason: 3=DEAUTH_LEAVING) [ 87.017404] ath11k_pci 0000:72:00.0: link down error during global reset [ 87.017599] DMAR: DRHD: handling fault status reg 2 [ 87.017618] DMAR: [INTR-REMAP] Request device [0x72:0x00.0] fault index 0x60 [fault reason 0x22] Present field in the IRTE entry is clear Then after a while (1-2 mins - ass suggested in arch wiki) - modprobe ath11k_pci [ 135.374698] ath11k_pci 0000:72:00.0: BAR 0: assigned [mem 0xa2500000-0xa25fffff 64bit] [ 135.375686] ath11k_pci 0000:72:00.0: qca6390 hw2.0 [ 135.532445] mhi mhi0: Requested to power ON [ 135.532737] mhi mhi0: Power on setup success [ 135.853985] mhi mhi0: Wait for device to enter SBL or Mission mode And the card never starts again. If I try to rmmod again - it hangs. Even --force helps rmmod --force ath11k_pci rmmod: ERROR: could not remove 'ath11k_pci': Device or resource busy rmmod: ERROR: could not remove module ath11k_pci: Device or resource busy
Have exactly same issue. [ 5.777419] ath11k_pci 0000:72:00.0: BAR 0: assigned [mem 0xa2500000-0xa25fffff 64bit] [ 5.777442] ath11k_pci 0000:72:00.0: enabling device (0000 -> 0002) [ 5.777783] ath11k_pci 0000:72:00.0: qca6390 hw2.0 [ 5.934955] Loading firmware: ath11k/QCA6390/hw2.0/amss.bin [ 6.376059] ath11k_pci 0000:72:00.0: chip_id 0x0 chip_family 0xb board_id 0xff soc_id 0xffffffff [ 6.377450] ath11k_pci 0000:72:00.0: fw_version 0x101c06cc fw_build_timestamp 2020-06-24 19:50 fw_build_id [ 6.378909] Loading firmware: ath11k/QCA6390/hw2.0/board-2.bin [ 6.394521] Loading firmware: ath11k/QCA6390/hw2.0/m3.bin rmmod ath11k_pci [ 100.322300] ath11k_pci 0000:72:00.0: link down error during global reset [ 100.322472] DMAR: DRHD: handling fault status reg 2 [ 100.322491] DMAR: [INTR-REMAP] Request device [0x72:0x00.0] fault index 0x60 [fault reason 0x22] Present field in the IRTE entry is clear modprobe ath11k_pci [ 235.222223] ath11k_pci 0000:72:00.0: BAR 0: assigned [mem 0xa2500000-0xa25fffff 64bit] [ 235.223161] ath11k_pci 0000:72:00.0: qca6390 hw2.0 [ 235.379984] mhi mhi0: Requested to power ON [ 235.380244] mhi mhi0: Power on setup success [ 235.380331] Loading firmware: ath11k/QCA6390/hw2.0/amss.bin [ 235.701567] mhi mhi0: Wait for device to enter SBL or Mission mode Currently I am on 5.14.10 kernel , but have tried ath11k git tree as well - same story. Also one more point - if I configure MHI bus as a module, ath11k never comes up even on first boot. It stays in this state forever mhi mhi0: Wait for device to enter SBL or Mission mode
I'm not able to reproduce this. On my test box I do 'rmmod ath11k_pci' all the time, it's part of my regression tests. But I also tested on Dell XPS 13 9310 laptop with QCA6390 hw2.0, did 'sudo rmmod ath11k_pci', waited a minute or so and then did 'sudo modprobe ath11k_pci' without issues. Same thing with 'modprobe -r ath11k_pci'. Am I missing something? I'm testing on master branch of my ath.git tree, eventually all code goes to official Linux releases.
(In reply to Kalle Valo from comment #2) > I'm not able to reproduce this. On my test box I do 'rmmod ath11k_pci' all > the time, it's part of my regression tests. But I also tested on Dell XPS 13 > 9310 laptop with QCA6390 hw2.0, did 'sudo rmmod ath11k_pci', waited a minute > or so and then did 'sudo modprobe ath11k_pci' without issues. Same thing > with 'modprobe -r ath11k_pci'. Am I missing something? > > I'm testing on master branch of my ath.git tree, eventually all code goes to > official Linux releases. With the latest ath11.git it works almost OK now. Do not know which patches actually fixed the thing. Loading module too fast still makes it hang from time to time but now even if modprobe fails it can be reloaded again. One ore point I've noticed the firmware from Dell Windows drivers: fw_version 0x10110341 fw_build_timestamp 2021-05-02 15:16 fw_build_id works more stable. It does not require to wait 1 minute arfter rmmod bfore modprobe and is faster when switching to other network or resuming from hibernation.
Thanks, closing the bug as the bug seems to be fixed.