QCA6174 on Asus Z170I Pro Gaming

Michal Kazior michal.kazior at tieto.com
Wed Jan 20 05:04:21 PST 2016 

On 20 January 2016 at 13:37, Per Östlund <perost86 at gmail.com> 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

I found this in your logs:

 jan 20 21:11:28 media kernel: ath10k_pci 0000:05:00.0: event mgmt rx
status 00000000
 jan 20 21:11:28 media kernel: ath10k_pci 0000:05:00.0: event mgmt rx
skb ffff880248648700 len 211 ftype 00 stype 80
 jan 20 21:11:28 media kernel: ath10k_pci 0000:05:00.0: event mgmt rx
freq 5180 band 1 snr -89, rate_idx 0

Looks like you did receive a beacon frame at some point but the signal
was very very weak (-89dBm). No dumps (the missing 0x30 in the
debug_mask) so I can't say what BSS/SSID it came from.

You either picked up a very far-away AP or for some reason the device
is having signal problems on 5GHz band.

Can you confirm that your AP is actually reachable by any other
5GHz-capable device other than your QCA6174? Perhaps antenna on your
AP became loose or is broken?

Other than that I'm out of ideas for now.


Michał


>
>
>>
>> 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
>
>

More information about the ath10k mailing list