Re: QCA6174 on Asus Z170I Pro Gaming

["Per Östlund" <perost86@gmail.com>]

On 2016-01-20 11:28, Michal Kazior wrote:
> On 19 January 2016 at 19:26, Per Östlund <perost86@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@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@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/ath10k


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k