QCA6174 on Asus Z170I Pro Gaming

Wed Jan 20 05:04:06 PST 2016

I happened to glance at the result of the scan I made, and to my 
surprise I found my 5 GHz network at the bottom. When I scanned again it 
was gone, and after a few more scans I found it again. Pulling my router 
out from behind my monitor so that there's only air between the router 
and the antenna made me able to establish a connection. But the 
performance is poor compared with 2.4 GHz, about 5 Mb/s when 
transferring a file compared with the ~80 Mb/s I got from 2.4 GHz.

Putting the router back to where I usually keep it broke the connection, 
while my laptop or phone has no issues with the connection wherever I am 
in my apartment. The wifi antenna is ~4 meters from the router with no 
walls or anything between. So the issue seems to be very poor reception, 
but I can't see any good reasons for it.

/Per

On 2016-01-20 13:37, Per Östlund wrote:
> On 2016-01-20 11:28, Michal Kazior wrote:
>> On 19 January 2016 at 19:26, Per Östlund <perost86 at gmail.com> wrote:
>>> After some more testing it seems that 5 GHz isn't working. iw shows 
>>> that the
>>> card is capable of using the channel my router is set to (channel 
>>> 36), and
>>> iw event says it's scanning the correct frequence. But it doesn't 
>>> find my
>>> router, and none of the other handful of APs using 5 GHz in range. 
>>> Any clues
>>> on what the issue might be?
>> Hmm.. My suspicion is you might still be running off of wrong board
>> data. Can you double check? Perhaps there's a narrower matching rule
>> somewhere else which picks a different eeprom file.
> The ini-file contains only one entry for 1043:86cd, which says:
> %ATHR.DeviceDesc.6320_3%   = ATHR_DEV_OS63_988x_AS_NFA344A.ndi, 
> PCI\VEN_168C&DEV_003E&SUBSYS_86CD1043&REV_32 ;for Asus
>
> There are only three eeprom-files that contains NFA344A:
> eeprom_ar6320_3p0_NFA344a.bin
> eeprom_ar6320_3p0_NFA344a_BLP.bin
> eeprom_ar6320_3p0_NFA344A_power1213.bin
>
> I used the first one, but now I also tried to other two to be sure. I 
> didn't notice any difference with them, 2.4 GHz still works fine with 
> them but 5 GHz finds nothing.
>> Otherwise maybe it's somehow related to regulatory. Kernel logs may
>> contain some useful info.
> I set it to use the Swedish domain, made no difference.
>> You might want to enable debugging by either:
>>   * load ath10k_core with param debug_mask=0xffffff3f
>>   * echo 0xffffff3f > /sys/module/ath10k_core/parameters/debug_mask
>>
>> You can try looking at the logs and look for scanning events and mgmt
>> rx events while scan is running. From the prints you should be able to
>> tell when certain frequencies are visited and if any frames are
>> reports are interleaved between visits. Perhaps FW reports them but
>> driver fails to deliver them up the stack for some reason..
> The kernel log says this when scanning 5.18 GHz (the channel I use):
>
> ath10k_pci 0000:05:00.0: scan event foreign channel type 8 reason 5 
> freq 5180 req_id 40961 scan_id 40960 vdev_id 0 state running (2)
> ath10k_pci 0000:05:00.0: pci rx ce pipe 2 len 40
> ath10k_pci 0000:05:00.0: htc rx completion ep 2 skb ffff880249687700
> ath10k_pci 0000:05:00.0: chan info err_code 0 freq 5180 cmd_flags 0 
> noise_floor 0 rx_clear_count 29943088 cycle_count 80350296
> ath10k_pci 0000:05:00.0: pci ps timer refcount 0 awake 1
> ath10k_pci 0000:05:00.0: pci ps sleep reg refcount 0 awake 1
> ath10k_pci 0000:05:00.0: pci ps wake reg refcount 0 awake 0
> ath10k_pci 0000:05:00.0: pci rx ce pipe 2 len 40
> ath10k_pci 0000:05:00.0: htc rx completion ep 2 skb ffff880249687800
> ath10k_pci 0000:05:00.0: scan event bss channel type 4 reason 5 freq 
> 5180 req_id 40961 scan_id 40960 vdev_id 0 state running (2)
> ath10k_pci 0000:05:00.0: pci rx ce pipe 2 len 40
> ath10k_pci 0000:05:00.0: htc rx completion ep 2 skb ffff8802486bae00
> ath10k_pci 0000:05:00.0: chan info err_code 0 freq 5180 cmd_flags 1 
> noise_floor -101 rx_clear_count 29945248 cycle_count 93248214
> ath10k_pci 0000:05:00.0: pci rx ce pipe 2 len 40
> ath10k_pci 0000:05:00.0: htc rx completion ep 2 skb ffff880248710500
>
> Doesn't mean much to me, but maybe you can make sense of it. I 
> uploaded the whole log with ath10k messages here (but stripped out 
> sleep/wake refcount messages that made up ~90% of the log otherwise):
>
> https://mega.nz/#!TJRFjCjZ!MUeBRH-kFmfco8B7ZcnBo2MVK_KhBC1aUZGSBNIu3kA
>
>>
>> Michał
>>
>>> /Per
>>>
>>>
>>> On 2016-01-19 09:59, Per Östlund wrote:
>>>> I could've sworn that the driver failed completely when it couldn't 
>>>> find
>>>> firmware-5.bin, but when cold booting the machine I now see that it 
>>>> actually
>>>> falls back to another firmware as you say. Anyway, looking at the 
>>>> ini file
>>>> as you suggested told me that eeprom_ar6320_3p0_NFA344a.bin was the 
>>>> correct
>>>> file. Replacing /lib/firmware/ath10k/QCA6174/hw3.0/board.bin with 
>>>> it made
>>>> the wifi spring to life, and I get usable performance (~80 Mbit/s). 
>>>> Thanks a
>>>> lot for the help!
>>>>
>>>> /Per
>>>>
>>>> On 2016-01-19 09:39, Michal Kazior wrote:
>>>>> On 18 January 2016 at 19:39, Per Östlund <perost86 at gmail.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I'm trying to get the wifi on my Asus Z170I Pro Gaming to work, but
>>>>>> haven't
>>>>>> had any luck so far.
>>>>>>
>>>>>> lspci says:
>>>>>> Network controller [0280]: Qualcomm Atheros QCA6174 802.11ac 
>>>>>> Wireless
>>>>>> Network Adapter [168c:003e] (rev 32)
>>>>>> Subsystem: ASUSTeK Computer Inc. Device [1043:86cd]
>>>>>>
>>>>>> I'm using the 4.4 kernel, on Arch Linux 64-bit (linux-4.4-3 
>>>>>> package from
>>>>>> testing repo). Out of the box ath10k doesn't work at all, 
>>>>>> complaining
>>>>>> that
>>>>>> it can't find firmware-5.bin. Copying firmware-4.bin to 
>>>>>> firmware-5.bin
>>>>>> gets
>>>>>> me further, with dmesg saying this:
>>>>> Please, don't do that. It's pointless.
>>>>>
>>>>> ath10k has a fallback system. If it doesn't find firmware-5.bin it'll
>>>>> look for -4, -3, -2 as well. The message you see in the kernel log is
>>>>> just a side effect of how to kernel API works at this time.
>>>>>
>>>>>
>>>>>> [ 4237.917517] ath10k_pci 0000:05:00.0: pci irq msi interrupts 1
>>>>>> irq_mode 0
>>>>>> reset_mode 0
>>>>>> [ 4238.139726] ath10k_pci 0000:05:00.0: Direct firmware load for
>>>>>> ath10k/cal-pci-0000:05:00.0.bin failed with error -2
>>>>>> [ 4238.139742] ath10k_pci 0000:05:00.0: Direct firmware load for
>>>>>> ath10k/QCA6174/hw3.0/firmware-5.bin failed with error -2
>>>>>> [ 4238.139745] ath10k_pci 0000:05:00.0: could not fetch firmware 
>>>>>> file
>>>>>> 'ath10k/QCA6174/hw3.0/firmware-5.bin': -2
>>>>>> [ 4238.202052] ath10k_pci 0000:05:00.0: Direct firmware load for
>>>>>> ath10k/QCA6174/hw3.0/board-2.bin failed with error -2
>>>>>> [ 4240.318396] ath10k_pci 0000:05:00.0: qca6174 hw3.2 (0x05030000,
>>>>>> 0x00340aff sub 1043:86cd) fw WLAN.RM.2.0-00180-QCARMSWPZ-1 fwapi 
>>>>>> 4 bdapi
>>>>>> 1
>>>>>> htt-ver 3.26 wmi-op 4 htt-op 3 cal otp max-sta 32 raw 0 hwcrypto 1
>>>>>> features
>>>>>> wowlan,ignore-otp,no-4addr-pad
>>>>> You have the hw3.2. It is sensitive to board data files (board.bin /
>>>>> board-2.bin).
>>>>>
>>>>>
>>>>>> [ 4240.318399] ath10k_pci 0000:05:00.0: debug 0 debugfs 1 tracing 
>>>>>> 0 dfs
>>>>>> 0
>>>>>> testmode 0
>>>>>> [ 4243.317764] ath10k_pci 0000:05:00.0: could not suspend target 
>>>>>> (-11)
>>>>>> [ 4243.378790] ath: EEPROM regdomain: 0x6c
>>>>>> [ 4243.378794] ath: EEPROM indicates we should expect a direct 
>>>>>> regpair
>>>>>> map
>>>>>> [ 4243.378796] ath: Country alpha2 being used: 00
>>>>>> [ 4243.378797] ath: Regpair used: 0x6c
>>>>>> [ 4243.380678] ath10k_pci 0000:05:00.0 wlp5s0: renamed from wlan0
>>>>> Looks okay.
>>>>>
>>>>>
>>>>>> [ 4365.040838] ath10k_pci 0000:05:00.0: pci irq msi interrupts 1
>>>>>> irq_mode 0
>>>>>> reset_mode 0
>>>>>> [ 4365.264862] ath10k_pci 0000:05:00.0: Direct firmware load for
>>>>>> ath10k/cal-pci-0000:05:00.0.bin failed with error -2
>>>>>> [ 4365.327022] ath10k_pci 0000:05:00.0: Direct firmware load for
>>>>>> ath10k/QCA6174/hw3.0/board-2.bin failed with error -2
>>>>> Looks like you reloaded the driver and nothing actually happened in
>>>>> between. Perhaps your syslog (or journald I suppose) filtered some
>>>>> messages?
>>>>>
>>>>>
>>>>>> The interface can't be brought up though:
>>>>>> # ip link set wlp5s0 up
>>>>>> RTNETLINK answers: Resource temporarily unavailable
>>>>> The kernel log doesn't really match what you're doing here.
>>>>>
>>>>> The error is EAGAIN (11). This is very likely due to a FW timeout
>>>>> which would be seen in the kernel log.
>>>>>
>>>>> The most common reason FW times out on QCA6174 hw3.2 is incorrect
>>>>> board file. The reason is the default board.bin doesn't work with
>>>>> hw3.2 and the board-2.bin doesn't include the proper mappings either
>>>>> yet (see the other thread in the archives - there's a lot of similar
>>>>> complaints).
>>>>>
>>>>>
>>>>>> I've tried various other firmwares (kvalo's, and other ones in 
>>>>>> the pull
>>>>>> requests for his repo), but they either give me a "found invalid 
>>>>>> board
>>>>>> magic" error or doesn't work any better than the one I got with the
>>>>> That's what you get when you rename files however you like. You
>>>>> probably wanted to use board.bin as board-2.bin file, right? This
>>>>> won't work.
>>>>>
>>>>>
>>>>>> linux-firmware package. I tried extracting the firmware myself 
>>>>>> from the
>>>>>> Windows drivers from Asus, which had both qca61x4_1_1_2.bin and
>>>>>> qca61x4_2_2.bin, using the instructions from [1]. The first 
>>>>>> failed with
>>>>>> "failed to receive control response completion, polling..", the 
>>>>>> second
>>>>>> worked as well as the one in linux-firmware.
>>>>> You encoded the binary incorrect probably.
>>>>>
>>>>> The problem you're facing isn't firmware problem per se. It is board
>>>>> file problem most likely.
>>>>>
>>>>>
>>>>>> The Asus driver also comes with a lot of eeprom-files, and I 
>>>>>> didn't know
>>>>>> which one to use. So I wrote a script that copied each one to
>>>>>> /lib/firmware/ath10k/QCA6174/hw3.0/board-2.bin and reloaded the 
>>>>>> driver,
>>>>>> but
>>>>>> all of them failed with the invalid board magic error.
>>>>> Yada yada. board-2.bin is TLV formatted. The eeprom files are
>>>>> basically board.bin files (the API1 board files). You need to remove
>>>>> board-2.bin and use the eeprom files from windows driver as 
>>>>> board.bin.
>>>>>
>>>>> You can actually figure out which one to use if you look at the .inf
>>>>> file in the windows driver. There's a section containing mappings for
>>>>> vendor/product ids (including subsystem ids, which is 1043:86cd in
>>>>> your case which can be seen in both ath10k print and lspci).
>>>>>
>>>>>
>>>>> Michał
>>>>
>>>
>>> _______________________________________________
>>> ath10k mailing list
>>> ath10k at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/ath10k
>