The upgraded packages were tzdata (2016a-1 -> 2016c-1) iana-etc (20151016-1 -> 20160314-1) libdbus (1.10.6-1 -> 1.10.8-1) expat (2.1.0-4 -> 2.1.1-1) dbus (1.10.6-1 -> 1.10.8-1) device-mapper (2.02.145-1 -> 2.02.146-1) geoip-database (20160105-1 -> 20160301-2) geoip (1.6.6-1 -> 1.6.6-2) groff (1.22.3-5 -> 1.22.3-6) iproute2 (4.1.1-1 -> 4.4.0-1) libnl (3.2.26-1 -> 3.2.27-1) iw (4.1-1 -> 4.3-1) lvm2 (2.02.145-1 -> 2.02.146-1) man-pages (4.04-1(http://airmail.calendar/2016-04-04%2016:04:00%20EDT) -> 4.05-1(http://airmail.calendar/2016-04-04%2016:05:00%20EDT)) mkinitcpio-busybox (1.21.1-2 -> 1.24.1-1) mpfr (3.1.3.p5-1 -> 3.1.4-1) pacman-mirrorlist (20160314-1 -> 20160320-1) vim-runtime (7.4.1529-1 -> 7.4.1639-1) vim (7.4.1529-1 -> 7.4.1639-1) wireshark-cli (2.0.2-2 -> 2.0.2-3)
I thought that maybe iw, libnl and iproute2 were potential culprits, so I tried downgrading these back to the original versions but it didn’t seem to help. As for regulatory information I thought it may have been that too and was the first thing I started looking into. Nothing seems to have changed as far as the eeprom->regdomain matching or with iw reg get output. I have crda running and up to date (v3.18-1 for the arch package). When it works the logs look like: [167611.256654] ath10k_pci 0000:01:00.0: pci irq msi interrupts 1 irq_mode 0 reset_mode 0 [167611.321383] ath10k_pci 0000:02:00.0: pci irq msi interrupts 1 irq_mode 0 reset_mode 0 [167611.391651] ath10k_pci 0000:01:00.0: Direct firmware load for ath10k/cal-pci-0000:01:00.0.bin failed with error -2 [167611.447564] ath10k_pci 0000:01:00.0: Direct firmware load for ath10k/QCA988X/hw2.0/board-2.bin failed with error -2 [167611.451462] ath10k_pci 0000:02:00.0: Direct firmware load for ath10k/cal-pci-0000:02:00.0.bin failed with error -2 [167611.507126] ath10k_pci 0000:02:00.0: Direct firmware load for ath10k/QCA988X/hw2.0/board-2.bin failed with error -2 [167612.644356] ath10k_pci 0000:01:00.0: qca988x hw2.0 (0x4100016c, 0x043202ff sub 0000:0000) fw 10.2.4.70.9-2 fwapi 5 bdapi 1 htt-ver 2.1 wmi-op 5 htt-op 2 cal otp max-sta 128 raw 0 hwcrypto 1 features no-p2p,raw-mode [167612.644391] ath10k_pci 0000:01:00.0: debug 0 debugfs 1 tracing 0 dfs 0 testmode 0 [167612.708936] ath: EEPROM regdomain: 0x0 [167612.708946] ath: EEPROM indicates default country code should be used [167612.708949] ath: doing EEPROM country->regdmn map search [167612.708952] ath: country maps to regdmn code: 0x3a [167612.708955] ath: Country alpha2 being used: US [167612.708958] ath: Regpair used: 0x3a [167612.715753] ath10k_pci 0000:01:00.0 wlan5: renamed from wlan0 [167612.721065] ath10k_pci 0000:02:00.0: qca988x hw2.0 (0x4100016c, 0x043202ff sub 0000:0000) fw 10.2.4.70.9-2 fwapi 5 bdapi 1 htt-ver 2.1 wmi-op 5 htt-op 2 cal otp max-sta 128 raw 0 hwcrypto 1 features no-p2p,raw-mode [167612.721074] ath10k_pci 0000:02:00.0: debug 0 debugfs 1 tracing 0 dfs 0 testmode 0 [167612.780766] ath: EEPROM regdomain: 0x0 [167612.780773] ath: EEPROM indicates default country code should be used [167612.780776] ath: doing EEPROM country->regdmn map search [167612.780780] ath: country maps to regdmn code: 0x3a [167612.780783] ath: Country alpha2 being used: US [167612.780785] ath: Regpair used: 0x3a [167612.789432] ath10k_pci 0000:02:00.0 wlan2: renamed from wlan0 As you can see both cards have EEPROM regdomain set to 0 and its gets mapped to the proper regulatory domain. Right now after the rmmod hack its working and others are using the wireless so I don’t have the exact failure logs although from memory they look the same (I can reboot tomorrow morning to get the other logs as it almost always fails during a reboot). As for iw reg get, in both situations it shows the same thing (except after a fresh boot the phy numbers are 0 and 1): global country US: DFS-FCC (2402 - 2472 @ 40), (N/A, 30), (N/A) (5170 - 5250 @ 80), (N/A, 17), (N/A), AUTO-BW (5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW (5490 - 5730 @ 160), (N/A, 23), (0 ms), DFS (5735 - 5835 @ 80), (N/A, 30), (N/A) (57240 - 63720 @ 2160), (N/A, 40), (N/A) phy#9 country US: DFS-FCC (2402 - 2472 @ 40), (N/A, 30), (N/A) (5170 - 5250 @ 80), (N/A, 17), (N/A), AUTO-BW (5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW (5490 - 5730 @ 160), (N/A, 23), (0 ms), DFS (5735 - 5835 @ 80), (N/A, 30), (N/A) (57240 - 63720 @ 2160), (N/A, 40), (N/A) phy#8 country US: DFS-FCC (2402 - 2472 @ 40), (N/A, 30), (N/A) (5170 - 5250 @ 80), (N/A, 17), (N/A), AUTO-BW (5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW (5490 - 5730 @ 160), (N/A, 23), (0 ms), DFS (5735 - 5835 @ 80), (N/A, 30), (N/A) (57240 - 63720 @ 2160), (N/A, 40), (N/A) global country US: DFS-FCC (2402 - 2472 @ 40), (N/A, 30), (N/A) (5170 - 5250 @ 80), (N/A, 17), (N/A), AUTO-BW (5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW (5490 - 5730 @ 160), (N/A, 23), (0 ms), DFS (5735 - 5835 @ 80), (N/A, 30), (N/A) (57240 - 63720 @ 2160), (N/A, 40), (N/A) -- Matthew Keeler On April 4, 2016 at 07:41:35, Michal Kazior ([email protected](mailto:[email protected])) wrote: > On 4 April 2016 at 13:26, Matthew Keeler wrote: > > > > I have been running two QCA9880 based cards for a couple of months now. > > Recently I needed to update some packages on the router and reboot and ever > > since I have not been able to get both working again. I have tried > > downgrading the packages (although none were related to the kernel/driver > > or the firmware to no avail. > > Can you list what packages were updated, please? > > > > Cards: Airetos AEX-QCA988-NX > > System: Arch Linux with kernel 4.4.5 > > Firmwares tried: Everything from 10.2.4.70.9-2 through 10.2.4.70.31-2 > > > > The symptoms are that upon boot most of the time one of the two cards > > doesn’t think it can/should transmit on any 5GHz frequency (I haven’t seen > > the issue with 2.4GHz frequency band). With dmesg I can see two sets of > > logs about the EEPROM regdomain being 0x0 and it eventually setting my > > regulatory domain to 0x3a US. iw reg get also confirms that both cards have > > the right US regulatory domain. One thing which does sometimes clear it up > > is to "rmmod ath10k_pci ath10k_core && modprobe ath10k_pci”. It doesn’t > > work every time though. > > Smells like regulatory problem, not ath10k per se. > > > > So 1) Should 2 ath10k cards coexist properly and 2) Has anyone seen similar > > behavior and know how to fix it. > > This should work fine. > > Can you post kernel logs when it works/breaks? Do you have CRDA > installed/up-to-date? Can you try checking output of `iw reg get` when > it works/breaks? > > > Michał _______________________________________________ ath10k mailing list [email protected] http://lists.infradead.org/mailman/listinfo/ath10k
