Trouble with multiple cards

Mon Apr 4 06:06:15 PDT 2016

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 (michal.kazior at tieto.com(mailto:michal.kazior at tieto.com)) 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ł