QCA6174 on Asus Z170I Pro Gaming

QCA6174 on Asus Z170I Pro Gaming

[Per Östlund]

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:

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

The interface can't be brought up though:
# ip link set wlp5s0 up
RTNETLINK answers: Resource temporarily unavailable

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

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.

Now I'm out of ideas, so does anyone have any suggestion on what to try 
next?

[1] 
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1383184/comments/115

Regards,
Per


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

Re: QCA6174 on Asus Z170I Pro Gaming

[Michal Kazior]

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

Re: QCA6174 on Asus Z170I Pro Gaming

[Per Östlund]

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

Re: QCA6174 on Asus Z170I Pro Gaming

[Per Östlund]

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?

/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

Re: QCA6174 on Asus Z170I Pro Gaming

[Michal Kazior]

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.

Otherwise maybe it's somehow related to regulatory. Kernel logs may
contain some useful info.

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


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

Re: QCA6174 on Asus Z170I Pro Gaming

[Per Östlund]

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

Re: QCA6174 on Asus Z170I Pro Gaming

[Per Östlund]

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

Re: QCA6174 on Asus Z170I Pro Gaming

[Michal Kazior]

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

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