Re: QCA6174 hw2.1 Firmware crash when connecting to a 5GHz network
Sorry for my late answer. Sadly the AP's im connecting to, are part of my universities wifi so i can't tell you the excat chipset they use. I tried to connect without the network manager so i followed the instructions and did a try with wpa_supplicant. I attached you the log i got, but sadly it didn't work either. Btw... connecting to a unencrypted 5Ghz network works fine. But when i try to build up a connection with an VPN over an unencrypted wifi fails too. Gesendet: Donnerstag, 19. November 2015 um 11:09 Uhr Von: "Bartosz Markowski" An: "Roman Bange" Cc: ath10k Betreff: Re: QCA6174 hw2.1 Firmware crash when connecting to a 5GHz network On 18 November 2015 at 16:28, Roman Bange wrote: > Hey, > > im getting a firmware crash when i try to connect to a 5GHz network. > I tested the older firmware WLAN.RM.1.1-00141, which is now provided in > linux-firmware, and SW_RM.1.1.1-00157-QCARMSWPZ-1, which is provided by you > in ath10k-firmware. > > SW_RM.1.1.1-00157-QCARMSWPZ-1 didn't crash but i wasn't able to connect > either. > > In addition i tested a solution that worked for me with the 4.1 Kernel where > i extracted the firmware out of the windows driver (and can be found here > (https://github.com/sumdog/ath10k-firmware). This solution didn't worked for > me too. > > I tested the firmware with 4.2.0-16 under Ubuntu, but experienced the same > problem with the stable releases 4.2.6 and 4.3 too. I have not tested the > 4.4-rc1 Kernel yet because its not compilable with the Ubuntu packages. The firmware crash you experience with "older" firmwares got fixed in the 000157. It's most likely related with wrong txbf capability advertisement, which your card (and firmware for it) does not support. May I ask what AP you test with? > I attached the related dmesg logs to this mail. When you use the 000157 firmware you can see there's a successful auth/assoc seq. but later on for some reason there's a local deauth triggered. [ 58.966382] wlp3s0: authenticate with f0:7f:06:2a:44:2d [ 59.008957] wlp3s0: send auth to f0:7f:06:2a:44:2d (try 1/3) [ 59.009546] wlp3s0: authenticated [ 59.014268] wlp3s0: associate with f0:7f:06:2a:44:2d (try 1/3) [ 59.019139] wlp3s0: RX AssocResp from f0:7f:06:2a:44:2d (capab=0x11 status=0 aid=6) [ 59.022291] wlp3s0: associated [ 59.022324] IPv6: ADDRCONF(NETDEV_CHANGE): wlp3s0: link becomes ready ... [ 62.130412] wlp3s0: deauthenticating from f0:7f:06:2a:44:2d by local choice (Reason: 3=DEAUTH_LEAVING) And these steps repeat in your log. Could you try to connect with the AP w/o the network manager (using wpa_supplicant / wpa_cli directly)? > Best regards, > Roman > ___ > ath10k mailing list > ath10k@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/ath10k[http://lists.infradead.org/mailman/listinfo/ath10k] > -- Bartosz wpasupplicant log Description: Binary data ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: QCA6174 hw2.1 Firmware crash when connecting to a 5GHz network
On 18 November 2015 at 16:28, Roman Bange wrote: > Hey, > > im getting a firmware crash when i try to connect to a 5GHz network. > I tested the older firmware WLAN.RM.1.1-00141, which is now provided in > linux-firmware, and SW_RM.1.1.1-00157-QCARMSWPZ-1, which is provided by you > in ath10k-firmware. > > SW_RM.1.1.1-00157-QCARMSWPZ-1 didn't crash but i wasn't able to connect > either. > > In addition i tested a solution that worked for me with the 4.1 Kernel where > i extracted the firmware out of the windows driver (and can be found here > (https://github.com/sumdog/ath10k-firmware). This solution didn't worked for > me too. > > I tested the firmware with 4.2.0-16 under Ubuntu, but experienced the same > problem with the stable releases 4.2.6 and 4.3 too. I have not tested the > 4.4-rc1 Kernel yet because its not compilable with the Ubuntu packages. The firmware crash you experience with "older" firmwares got fixed in the 000157. It's most likely related with wrong txbf capability advertisement, which your card (and firmware for it) does not support. May I ask what AP you test with? > I attached the related dmesg logs to this mail. When you use the 000157 firmware you can see there's a successful auth/assoc seq. but later on for some reason there's a local deauth triggered. [ 58.966382] wlp3s0: authenticate with f0:7f:06:2a:44:2d [ 59.008957] wlp3s0: send auth to f0:7f:06:2a:44:2d (try 1/3) [ 59.009546] wlp3s0: authenticated [ 59.014268] wlp3s0: associate with f0:7f:06:2a:44:2d (try 1/3) [ 59.019139] wlp3s0: RX AssocResp from f0:7f:06:2a:44:2d (capab=0x11 status=0 aid=6) [ 59.022291] wlp3s0: associated [ 59.022324] IPv6: ADDRCONF(NETDEV_CHANGE): wlp3s0: link becomes ready ... [ 62.130412] wlp3s0: deauthenticating from f0:7f:06:2a:44:2d by local choice (Reason: 3=DEAUTH_LEAVING) And these steps repeat in your log. Could you try to connect with the AP w/o the network manager (using wpa_supplicant / wpa_cli directly)? > Best regards, > Roman > ___ > ath10k mailing list > ath10k@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/ath10k > -- Bartosz ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: QCA6174 hw2.1 irq_mode=0 broken on 4.2-rc3, working on 4.1.2
Hi there, it's been a while, but I have good news: tried Kernel 4.2.3 from Fedora and it just works! No need to use irq_mode=1 (and I also removed skip_opt), tested with firmware API 5 from ath10k-firmware since a couple of days now. No issue so far. Thank you for the help and the work, and sorry for not being very useful in investigating this eheheh. Cheers! Enrico On 8 September 2015 at 10:17, Enrico Tagliavini wrote: > Hi there, > > sorry for the late and still no results. Life never goes as planned > does it? I will still try to find the time to bisect this, however I > cannot foresee when this might happen. If anybody has urgency to fix > this might as well bisecting instead of waiting for me. My apologize > :( > > Best regards. > Enrico > > On 5 August 2015 at 19:52, Enrico Tagliavini > wrote: >> Bisect is done, unfortunately I think there is no good news >> >> $ git bisect log >> git bisect start '--' 'drivers/net/wireless/ath/ath10k/' >> # bad: [86ea07ca846a7c352f39dd0b7d81f15f403c7db8] Merge branch >> 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux >> git bisect bad 86ea07ca846a7c352f39dd0b7d81f15f403c7db8 >> # good: [b953c0d234bc72e8489d3bf51a276c5c4ec85345] Linux 4.1 >> git bisect good b953c0d234bc72e8489d3bf51a276c5c4ec85345 >> # good: [8e9904f5b9e5e0a126020211218c401d601ef74b] ath10k: mac: match >> wait_for_completion_timeout return type >> git bisect good 8e9904f5b9e5e0a126020211218c401d601ef74b >> # good: [8e9904f5b9e5e0a126020211218c401d601ef74b] ath10k: mac: match >> wait_for_completion_timeout return type >> git bisect good 8e9904f5b9e5e0a126020211218c401d601ef74b >> # good: [0cd9bc147f0b8d805972cbb4b7b5e5529f9624e0] ath10k: enable ibss-rsn >> git bisect good 0cd9bc147f0b8d805972cbb4b7b5e5529f9624e0 >> # good: [48f4ca34f36bb947d8a7cd4ff8c8e282f14d51e6] ath10k: add new >> 4addr related fw_feature >> git bisect good 48f4ca34f36bb947d8a7cd4ff8c8e282f14d51e6 >> # good: [163f52647a0f7e34e803b51456c60deedd26ca1d] ath10k: bypass PLL >> setting on target init for QCA9888 >> git bisect good 163f52647a0f7e34e803b51456c60deedd26ca1d >> # good: [d7bf4b4aba056f3e7eb88a3d8d45ee1a6f4873e9] ath10k: fix >> ar->rx_channel updating logic >> git bisect good d7bf4b4aba056f3e7eb88a3d8d45ee1a6f4873e9 >> # good: [0e6eb417fc1facda1c9a9189be85f16cb5b8b69f] ath10k: fix channel >> switching >> git bisect good 0e6eb417fc1facda1c9a9189be85f16cb5b8b69f >> # good: [30686bf7f5b3c30831761e188a6e3cb33580fa48] mac80211: convert >> HW flags to unsigned long bitmap >> git bisect good 30686bf7f5b3c30831761e188a6e3cb33580fa48 >> # good: [469d479f91b8277cc921d7525f31c832b25d9efb] ath10k: prevent >> memory leak in wmi rx ops >> git bisect good 469d479f91b8277cc921d7525f31c832b25d9efb >> # good: [fa433354f042105fc7a299253f904bb48dae0950] Merge tag >> 'wireless-drivers-next-for-davem-2015-06-18' of >> git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next >> git bisect good fa433354f042105fc7a299253f904bb48dae0950 >> >> as you can see I tried to restrict the bisect to the ath10k folder >> only and none of the commit was faulty. Probably because all the >> commit were actually still on kernel 4.1 rc, none of them was on 4.2 >> except the starting bad one (which was the latest when I cloned the >> repo for rc4). >> >> So I guess we are switching to plan B here and bisecting the entire >> tree right? If so, starting from the same bad commit as for this one >> and using the newest good commit I tested (so last entry in the bisect >> I just did) >> >> $ git bisect good fa433354f042105fc7a299253f904bb48dae0950 >> Bisecting: 6373 revisions left to test after this (roughly 13 steps) >> [4aa705b18bf17c4ff33ff7bbcd3f0c596443fa81] Merge tag 'armsoc-soc' of >> git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc >> >> 13 steps are not crazy sigh. Give me enough days, in the weekend >> I'll be on the road the I'll see if I can get few quiet hours to get >> this done. >> >> Any last minute advise or question before I reset this bisect? >> >> On 1 August 2015 at 14:30, Enrico Tagliavini >> wrote: >>> Hi there, >>> >>> I got 4.2 rc4 running and I'm going to start the bisect. Before >>> compiling I enabled ath10k debug and this is the output for with >>> default irq_mode: >>> >>> enrico@alientux ~ $ dmesg | grep ath >>> [ 16.234853] ath10k_pci :03:00.0: enabling device ( -> 0002) >>> [ 16.234979] ath10k_pci :03:00.0: boot pci_mem 0xc9000200 >>> [ 16.235351] ath10k_pci :03:00.0: pci irq msi-x interrupts 8 >>> irq_mode 0 reset_mode 0 >>> [ 16.235517] ath10k_pci :03:00.0: boot qca6174 chip reset >>> [ 16.235518] ath10k_pci :03:00.0: boot cold reset >>> [ 16.239030] ath10k_pci :03:00.0: boot cold reset complete >>> [ 16.239032] ath10k_pci :03:00.0: boot waiting target to initialise >>> [ 16.239037] ath10k_pci :03:00.0: boot target indicator 0 >>> [ 16.249046] ath10k_pci :03:00.0: boot target indicator 2 >>> [ 16.249055] ath10k
Re: QCA6174 hw2.1 irq_mode=0 broken on 4.2-rc3, working on 4.1.2
Hi there, sorry for the late and still no results. Life never goes as planned does it? I will still try to find the time to bisect this, however I cannot foresee when this might happen. If anybody has urgency to fix this might as well bisecting instead of waiting for me. My apologize :( Best regards. Enrico On 5 August 2015 at 19:52, Enrico Tagliavini wrote: > Bisect is done, unfortunately I think there is no good news > > $ git bisect log > git bisect start '--' 'drivers/net/wireless/ath/ath10k/' > # bad: [86ea07ca846a7c352f39dd0b7d81f15f403c7db8] Merge branch > 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux > git bisect bad 86ea07ca846a7c352f39dd0b7d81f15f403c7db8 > # good: [b953c0d234bc72e8489d3bf51a276c5c4ec85345] Linux 4.1 > git bisect good b953c0d234bc72e8489d3bf51a276c5c4ec85345 > # good: [8e9904f5b9e5e0a126020211218c401d601ef74b] ath10k: mac: match > wait_for_completion_timeout return type > git bisect good 8e9904f5b9e5e0a126020211218c401d601ef74b > # good: [8e9904f5b9e5e0a126020211218c401d601ef74b] ath10k: mac: match > wait_for_completion_timeout return type > git bisect good 8e9904f5b9e5e0a126020211218c401d601ef74b > # good: [0cd9bc147f0b8d805972cbb4b7b5e5529f9624e0] ath10k: enable ibss-rsn > git bisect good 0cd9bc147f0b8d805972cbb4b7b5e5529f9624e0 > # good: [48f4ca34f36bb947d8a7cd4ff8c8e282f14d51e6] ath10k: add new > 4addr related fw_feature > git bisect good 48f4ca34f36bb947d8a7cd4ff8c8e282f14d51e6 > # good: [163f52647a0f7e34e803b51456c60deedd26ca1d] ath10k: bypass PLL > setting on target init for QCA9888 > git bisect good 163f52647a0f7e34e803b51456c60deedd26ca1d > # good: [d7bf4b4aba056f3e7eb88a3d8d45ee1a6f4873e9] ath10k: fix > ar->rx_channel updating logic > git bisect good d7bf4b4aba056f3e7eb88a3d8d45ee1a6f4873e9 > # good: [0e6eb417fc1facda1c9a9189be85f16cb5b8b69f] ath10k: fix channel > switching > git bisect good 0e6eb417fc1facda1c9a9189be85f16cb5b8b69f > # good: [30686bf7f5b3c30831761e188a6e3cb33580fa48] mac80211: convert > HW flags to unsigned long bitmap > git bisect good 30686bf7f5b3c30831761e188a6e3cb33580fa48 > # good: [469d479f91b8277cc921d7525f31c832b25d9efb] ath10k: prevent > memory leak in wmi rx ops > git bisect good 469d479f91b8277cc921d7525f31c832b25d9efb > # good: [fa433354f042105fc7a299253f904bb48dae0950] Merge tag > 'wireless-drivers-next-for-davem-2015-06-18' of > git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next > git bisect good fa433354f042105fc7a299253f904bb48dae0950 > > as you can see I tried to restrict the bisect to the ath10k folder > only and none of the commit was faulty. Probably because all the > commit were actually still on kernel 4.1 rc, none of them was on 4.2 > except the starting bad one (which was the latest when I cloned the > repo for rc4). > > So I guess we are switching to plan B here and bisecting the entire > tree right? If so, starting from the same bad commit as for this one > and using the newest good commit I tested (so last entry in the bisect > I just did) > > $ git bisect good fa433354f042105fc7a299253f904bb48dae0950 > Bisecting: 6373 revisions left to test after this (roughly 13 steps) > [4aa705b18bf17c4ff33ff7bbcd3f0c596443fa81] Merge tag 'armsoc-soc' of > git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc > > 13 steps are not crazy sigh. Give me enough days, in the weekend > I'll be on the road the I'll see if I can get few quiet hours to get > this done. > > Any last minute advise or question before I reset this bisect? > > On 1 August 2015 at 14:30, Enrico Tagliavini > wrote: >> Hi there, >> >> I got 4.2 rc4 running and I'm going to start the bisect. Before >> compiling I enabled ath10k debug and this is the output for with >> default irq_mode: >> >> enrico@alientux ~ $ dmesg | grep ath >> [ 16.234853] ath10k_pci :03:00.0: enabling device ( -> 0002) >> [ 16.234979] ath10k_pci :03:00.0: boot pci_mem 0xc9000200 >> [ 16.235351] ath10k_pci :03:00.0: pci irq msi-x interrupts 8 >> irq_mode 0 reset_mode 0 >> [ 16.235517] ath10k_pci :03:00.0: boot qca6174 chip reset >> [ 16.235518] ath10k_pci :03:00.0: boot cold reset >> [ 16.239030] ath10k_pci :03:00.0: boot cold reset complete >> [ 16.239032] ath10k_pci :03:00.0: boot waiting target to initialise >> [ 16.239037] ath10k_pci :03:00.0: boot target indicator 0 >> [ 16.249046] ath10k_pci :03:00.0: boot target indicator 2 >> [ 16.249055] ath10k_pci :03:00.0: boot target initialised >> [ 16.249057] ath10k_pci :03:00.0: boot warm reset >> [ 16.271106] ath10k_pci :03:00.0: boot init ce src ring id 0 >> entries 16 base_addr 88003f00a000 >> [ 16.271128] ath10k_pci :03:00.0: boot ce dest ring id 1 entries >> 512 base_addr 88003f3c8000 >> [ 16.271146] ath10k_pci :03:00.0: boot ce dest ring id 2 entries >> 128 base_addr 88003eb6a000 >> [ 16.271166] ath10k_pci :03:00.0: boot init ce src ring id 3 >> entries 32 base_addr 88003f3
Re: qca6174 hw2.1 fw and kernel crash on 5GHz network connection attempt
2015-08-07 6:46 GMT+02:00 Michal Kazior : > On 6 August 2015 at 16:42, Lapo Calamandrei wrote: >> Hi Michal, first of all thank you for your time. So, looks like the >> patch provided makes no difference [to me], attached the dmesg output >> with and without the patch applied against a fresh checkout. > > This is weird. I'm pretty sure this is TxBF related. Can you get > traces[1] with the patch applied, please? > > [1]: https://wireless.wiki.kernel.org/en/users/drivers/ath10k/debug#tracing > > > Michał Here's the trace.dat https://dl.dropboxusercontent.com/u/208474/ath/trace.dat.xz Lapo ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: qca6174 hw2.1 fw and kernel crash on 5GHz network connection attempt
On 6 August 2015 at 16:42, Lapo Calamandrei wrote: > Hi Michal, first of all thank you for your time. So, looks like the > patch provided makes no difference [to me], attached the dmesg output > with and without the patch applied against a fresh checkout. This is weird. I'm pretty sure this is TxBF related. Can you get traces[1] with the patch applied, please? [1]: https://wireless.wiki.kernel.org/en/users/drivers/ath10k/debug#tracing Michał ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: qca6174 hw2.1 fw and kernel crash on 5GHz network connection attempt
...and this is the dmesg output with yesterday's build with the patch applied. 2015-08-06 15:52 GMT+02:00 Lapo Calamandrei : > Hi Michal, first of all thank you for your time. So, looks like the > patch provided makes no difference [to me], attached the dmesg output > with and without the patch applied against a fresh checkout. > > Ciao > Lapo > > 2015-08-06 7:03 GMT+02:00 Michal Kazior : [SNIP] ago 06 16:36:31 localhost.localdomain kernel: wlp3s0: authenticate with 10:bf:48:d8:91:74 ago 06 16:36:31 localhost.localdomain kernel: wlp3s0: send auth to 10:bf:48:d8:91:74 (try 1/3) ago 06 16:36:31 localhost.localdomain kernel: wlp3s0: authenticated ago 06 16:36:31 localhost.localdomain kernel: wlp3s0: associate with 10:bf:48:d8:91:74 (try 1/3) ago 06 16:36:31 localhost.localdomain kernel: wlp3s0: RX AssocResp from 10:bf:48:d8:91:74 (capab=0x11 status=0 aid=2) ago 06 16:36:31 localhost.localdomain kernel: ath10k_pci :03:00.0: firmware crashed! (uuid e745169f-b1a4-4197-bf50-fe2358311086) ago 06 16:36:31 localhost.localdomain kernel: [231B blob data] ago 06 16:36:31 localhost.localdomain kernel: ath10k_pci :03:00.0: debug 0 debugfs 1 tracing 0 dfs 0 testmode 0 ago 06 16:36:31 localhost.localdomain kernel: ath10k_pci :03:00.0: firmware register dump: ago 06 16:36:31 localhost.localdomain kernel: ath10k_pci :03:00.0: [00]: 0x0501 0x15B3 0x00939797 0x00955B31 ago 06 16:36:31 localhost.localdomain kernel: ath10k_pci :03:00.0: [04]: 0x00939797 0x00060330 0x 0x ago 06 16:36:31 localhost.localdomain kernel: ath10k_pci :03:00.0: [08]: 0x00413980 0x 0x 0x ago 06 16:36:31 localhost.localdomain kernel: ath10k_pci :03:00.0: [12]: 0x0009 0x 0x0096C09C 0x0096C0A7 ago 06 16:36:31 localhost.localdomain kernel: ath10k_pci :03:00.0: [16]: 0x0096BDBC 0x009287BD 0x 0x009287BD ago 06 16:36:31 localhost.localdomain kernel: ath10k_pci :03:00.0: [20]: 0x40939797 0x0041A700 0x00407124 0x ago 06 16:36:31 localhost.localdomain kernel: ath10k_pci :03:00.0: [24]: 0x8093D6C4 0x0041A760 0x00A8 0xC0939797 ago 06 16:36:31 localhost.localdomain kernel: ath10k_pci :03:00.0: [28]: 0x8094777F 0x0041A780 0x0046D5D8 0x0001 ago 06 16:36:31 localhost.localdomain kernel: ath10k_pci :03:00.0: [32]: 0x800AA41F 0x0041A7B0 0x0046D5D8 0x0001 ago 06 16:36:31 localhost.localdomain kernel: ath10k_pci :03:00.0: [36]: 0x800AA586 0x0041A7D0 0x004246F4 0x0001 ago 06 16:36:31 localhost.localdomain kernel: ath10k_pci :03:00.0: [40]: 0x80994CC4 0x0041A7F0 0x004246F4 0x0041A838 ago 06 16:36:31 localhost.localdomain kernel: ath10k_pci :03:00.0: [44]: 0x80996CFA 0x0041A820 0x0046F888 0x00412984 ago 06 16:36:31 localhost.localdomain kernel: ath10k_pci :03:00.0: [48]: 0x800B43DD 0x0041A860 0x004221C8 0x5008 ago 06 16:36:31 localhost.localdomain kernel: ath10k_pci :03:00.0: [52]: 0x809A69BC 0x0041A8F0 0x004291DC 0x0042C8F0 ago 06 16:36:31 localhost.localdomain kernel: ath10k_pci :03:00.0: [56]: 0x809A6010 0x0041A930 0x0041A958 0x00426FE0 ago 06 16:36:31 localhost.localdomain kernel: ath10k_pci :03:00.0: failed to poke peer 10:bf:48:d8:91:74 param for ps workaround on vdev 0: -108 ago 06 16:36:31 localhost.localdomain kernel: wlp3s0: associated ago 06 16:36:31 localhost.localdomain kernel: IPv6: ADDRCONF(NETDEV_CHANGE): wlp3s0: link becomes ready ago 06 16:36:31 localhost.localdomain kernel: ieee80211 phy0: Hardware restart was requested ago 06 16:36:33 localhost.localdomain kernel: ath10k_pci :03:00.0: firmware crashed! (uuid b3a0ceb0-6985-466a-9370-ffcd9b4ff51f) ago 06 16:36:33 localhost.localdomain kernel: [231B blob data] ago 06 16:36:33 localhost.localdomain kernel: ath10k_pci :03:00.0: debug 0 debugfs 1 tracing 0 dfs 0 testmode 0 ago 06 16:36:33 localhost.localdomain kernel: ath10k_pci :03:00.0: firmware register dump: ago 06 16:36:33 localhost.localdomain kernel: ath10k_pci :03:00.0: [00]: 0x0501 0x15B3 0x00939797 0x00955B31 ago 06 16:36:33 localhost.localdomain kernel: ath10k_pci :03:00.0: [04]: 0x00939797 0x00060330 0x 0x ago 06 16:36:33 localhost.localdomain kernel: ath10k_pci :03:00.0: [08]: 0x00413980 0x 0x 0x ago 06 16:36:33 localhost.localdomain kernel: ath10k_pci :03:00.0: [12]: 0x0009 0x 0x0096C09C 0x0096C0A7 ago 06 16:36:33 localhost.localdomain kernel: ath10k_pci :03:00.0: [16]: 0x0096BDBC 0x009287BD 0x 0x ago 06 16:36:33 localhost.localdomain kernel: ath10k_pci :03:00.0: [20]: 0x40939797 0x0041A700 0x00407124 0x ago 06 16:36:33 localhost.localdomain kernel: ath10k_pci :03:00.0: [24]: 0x8093D6C4 0x0041A760 0x00A8 0xC0939797 ago 06 16:36:33 localhost.localdomain kernel: ath10k_pci :03:00.0: [28]: 0x8094777F 0x0041A780 0x0046D5D8 0x0001 ago 06 16:36:33 localhost.localdomain kernel: ath10k_pci :03:00.0: [32]: 0x800AA4
Re: qca6174 hw2.1 fw and kernel crash on 5GHz network connection attempt
On 5 August 2015 at 15:25, Lapo Calamandrei wrote:
> Hi,
>
> I have an alienware 17 r2 with a fedora 22 installed, I'm using kvalo
> ath kernel master branch from today, built with fedora rawhide
> 4.2.0-rc4 kernel config. The firmware is made following the
> instructions on the list by the windows drivers.
> I'm using skip_otp=1 on ath10k_core and irq_mode=1 on ath10k_pci
> otherwise I run into the same issues reported by Enrico Tagliavini.
> Everything works reasonably well on my 2.4GHz network, but trying to
> connect to my other 5Ghz I get a firmware crash followed by a kernel
> crash. Attached a dmesg output, feel free to ask any additional info.
There's no kernel crash here. It's just a warning splat with call
trace. This happens because - apparently - the device double-crashed
and got wedged so mac80211 complained verbosely.
The firmware crash itself seems to be related to TxBF. I'm guessing
the firmware wrongly advertises vht capabilities and crashes when
associating to TxBF capable AP.
As a temporary measure (and confirmation) you can try the diff below
(warning, whitespace damaged).
Michał
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -6732,23 +6732,10 @@ static struct ieee80211_sta_vht_cap
ath10k_create_vht_cap(struct ath10k *ar)
vht_cap.vht_supported = 1;
vht_cap.cap = ar->vht_cap_info;
- if (ar->vht_cap_info & (IEEE80211_VHT_CAP_SU_BEAMFORMEE_CAPABLE |
- IEEE80211_VHT_CAP_MU_BEAMFORMEE_CAPABLE)) {
- val = ar->num_rf_chains - 1;
- val <<= IEEE80211_VHT_CAP_BEAMFORMEE_STS_SHIFT;
- val &= IEEE80211_VHT_CAP_BEAMFORMEE_STS_MASK;
-
- vht_cap.cap |= val;
- }
-
- if (ar->vht_cap_info & (IEEE80211_VHT_CAP_SU_BEAMFORMER_CAPABLE |
- IEEE80211_VHT_CAP_MU_BEAMFORMER_CAPABLE)) {
- val = ar->num_rf_chains - 1;
- val <<= IEEE80211_VHT_CAP_SOUNDING_DIMENSIONS_SHIFT;
- val &= IEEE80211_VHT_CAP_SOUNDING_DIMENSIONS_MASK;
-
- vht_cap.cap |= val;
- }
+ ar->vht_cap_info &= ~(IEEE80211_VHT_CAP_SU_BEAMFORMEE_CAPABLE |
+ IEEE80211_VHT_CAP_MU_BEAMFORMEE_CAPABLE |
+ IEEE80211_VHT_CAP_SU_BEAMFORMER_CAPABLE |
+ IEEE80211_VHT_CAP_MU_BEAMFORMER_CAPABLE);
mcs_map = 0;
for (i = 0; i < 8; i++) {
___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
Re: QCA6174 hw2.1 irq_mode=0 broken on 4.2-rc3, working on 4.1.2
Bisect is done, unfortunately I think there is no good news $ git bisect log git bisect start '--' 'drivers/net/wireless/ath/ath10k/' # bad: [86ea07ca846a7c352f39dd0b7d81f15f403c7db8] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux git bisect bad 86ea07ca846a7c352f39dd0b7d81f15f403c7db8 # good: [b953c0d234bc72e8489d3bf51a276c5c4ec85345] Linux 4.1 git bisect good b953c0d234bc72e8489d3bf51a276c5c4ec85345 # good: [8e9904f5b9e5e0a126020211218c401d601ef74b] ath10k: mac: match wait_for_completion_timeout return type git bisect good 8e9904f5b9e5e0a126020211218c401d601ef74b # good: [8e9904f5b9e5e0a126020211218c401d601ef74b] ath10k: mac: match wait_for_completion_timeout return type git bisect good 8e9904f5b9e5e0a126020211218c401d601ef74b # good: [0cd9bc147f0b8d805972cbb4b7b5e5529f9624e0] ath10k: enable ibss-rsn git bisect good 0cd9bc147f0b8d805972cbb4b7b5e5529f9624e0 # good: [48f4ca34f36bb947d8a7cd4ff8c8e282f14d51e6] ath10k: add new 4addr related fw_feature git bisect good 48f4ca34f36bb947d8a7cd4ff8c8e282f14d51e6 # good: [163f52647a0f7e34e803b51456c60deedd26ca1d] ath10k: bypass PLL setting on target init for QCA9888 git bisect good 163f52647a0f7e34e803b51456c60deedd26ca1d # good: [d7bf4b4aba056f3e7eb88a3d8d45ee1a6f4873e9] ath10k: fix ar->rx_channel updating logic git bisect good d7bf4b4aba056f3e7eb88a3d8d45ee1a6f4873e9 # good: [0e6eb417fc1facda1c9a9189be85f16cb5b8b69f] ath10k: fix channel switching git bisect good 0e6eb417fc1facda1c9a9189be85f16cb5b8b69f # good: [30686bf7f5b3c30831761e188a6e3cb33580fa48] mac80211: convert HW flags to unsigned long bitmap git bisect good 30686bf7f5b3c30831761e188a6e3cb33580fa48 # good: [469d479f91b8277cc921d7525f31c832b25d9efb] ath10k: prevent memory leak in wmi rx ops git bisect good 469d479f91b8277cc921d7525f31c832b25d9efb # good: [fa433354f042105fc7a299253f904bb48dae0950] Merge tag 'wireless-drivers-next-for-davem-2015-06-18' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next git bisect good fa433354f042105fc7a299253f904bb48dae0950 as you can see I tried to restrict the bisect to the ath10k folder only and none of the commit was faulty. Probably because all the commit were actually still on kernel 4.1 rc, none of them was on 4.2 except the starting bad one (which was the latest when I cloned the repo for rc4). So I guess we are switching to plan B here and bisecting the entire tree right? If so, starting from the same bad commit as for this one and using the newest good commit I tested (so last entry in the bisect I just did) $ git bisect good fa433354f042105fc7a299253f904bb48dae0950 Bisecting: 6373 revisions left to test after this (roughly 13 steps) [4aa705b18bf17c4ff33ff7bbcd3f0c596443fa81] Merge tag 'armsoc-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc 13 steps are not crazy sigh. Give me enough days, in the weekend I'll be on the road the I'll see if I can get few quiet hours to get this done. Any last minute advise or question before I reset this bisect? On 1 August 2015 at 14:30, Enrico Tagliavini wrote: > Hi there, > > I got 4.2 rc4 running and I'm going to start the bisect. Before > compiling I enabled ath10k debug and this is the output for with > default irq_mode: > > enrico@alientux ~ $ dmesg | grep ath > [ 16.234853] ath10k_pci :03:00.0: enabling device ( -> 0002) > [ 16.234979] ath10k_pci :03:00.0: boot pci_mem 0xc9000200 > [ 16.235351] ath10k_pci :03:00.0: pci irq msi-x interrupts 8 > irq_mode 0 reset_mode 0 > [ 16.235517] ath10k_pci :03:00.0: boot qca6174 chip reset > [ 16.235518] ath10k_pci :03:00.0: boot cold reset > [ 16.239030] ath10k_pci :03:00.0: boot cold reset complete > [ 16.239032] ath10k_pci :03:00.0: boot waiting target to initialise > [ 16.239037] ath10k_pci :03:00.0: boot target indicator 0 > [ 16.249046] ath10k_pci :03:00.0: boot target indicator 2 > [ 16.249055] ath10k_pci :03:00.0: boot target initialised > [ 16.249057] ath10k_pci :03:00.0: boot warm reset > [ 16.271106] ath10k_pci :03:00.0: boot init ce src ring id 0 > entries 16 base_addr 88003f00a000 > [ 16.271128] ath10k_pci :03:00.0: boot ce dest ring id 1 entries > 512 base_addr 88003f3c8000 > [ 16.271146] ath10k_pci :03:00.0: boot ce dest ring id 2 entries > 128 base_addr 88003eb6a000 > [ 16.271166] ath10k_pci :03:00.0: boot init ce src ring id 3 > entries 32 base_addr 88003f349000 > [ 16.271187] ath10k_pci :03:00.0: boot init ce src ring id 4 > entries 4096 base_addr 8800ba94 > [ 16.271207] ath10k_pci :03:00.0: boot init ce src ring id 7 > entries 2 base_addr 8800c4888000 > [ 16.271223] ath10k_pci :03:00.0: boot ce dest ring id 7 entries > 2 base_addr 8800ba889000 > [ 16.271224] ath10k_pci :03:00.0: boot waiting target to initialise > [ 16.271229] ath10k_pci :03:00.0: boot target indicator 0 > [ 16.281316] ath10k_pci :03:00.0: b
Re: QCA6174 hw2.1 irq_mode=0 broken on 4.2-rc3, working on 4.1.2
Hi there, I got 4.2 rc4 running and I'm going to start the bisect. Before compiling I enabled ath10k debug and this is the output for with default irq_mode: enrico@alientux ~ $ dmesg | grep ath [ 16.234853] ath10k_pci :03:00.0: enabling device ( -> 0002) [ 16.234979] ath10k_pci :03:00.0: boot pci_mem 0xc9000200 [ 16.235351] ath10k_pci :03:00.0: pci irq msi-x interrupts 8 irq_mode 0 reset_mode 0 [ 16.235517] ath10k_pci :03:00.0: boot qca6174 chip reset [ 16.235518] ath10k_pci :03:00.0: boot cold reset [ 16.239030] ath10k_pci :03:00.0: boot cold reset complete [ 16.239032] ath10k_pci :03:00.0: boot waiting target to initialise [ 16.239037] ath10k_pci :03:00.0: boot target indicator 0 [ 16.249046] ath10k_pci :03:00.0: boot target indicator 2 [ 16.249055] ath10k_pci :03:00.0: boot target initialised [ 16.249057] ath10k_pci :03:00.0: boot warm reset [ 16.271106] ath10k_pci :03:00.0: boot init ce src ring id 0 entries 16 base_addr 88003f00a000 [ 16.271128] ath10k_pci :03:00.0: boot ce dest ring id 1 entries 512 base_addr 88003f3c8000 [ 16.271146] ath10k_pci :03:00.0: boot ce dest ring id 2 entries 128 base_addr 88003eb6a000 [ 16.271166] ath10k_pci :03:00.0: boot init ce src ring id 3 entries 32 base_addr 88003f349000 [ 16.271187] ath10k_pci :03:00.0: boot init ce src ring id 4 entries 4096 base_addr 8800ba94 [ 16.271207] ath10k_pci :03:00.0: boot init ce src ring id 7 entries 2 base_addr 8800c4888000 [ 16.271223] ath10k_pci :03:00.0: boot ce dest ring id 7 entries 2 base_addr 8800ba889000 [ 16.271224] ath10k_pci :03:00.0: boot waiting target to initialise [ 16.271229] ath10k_pci :03:00.0: boot target indicator 0 [ 16.281316] ath10k_pci :03:00.0: boot target indicator 2 [ 16.281373] ath10k_pci :03:00.0: boot target initialised [ 16.292100] ath10k_pci :03:00.0: boot init ce src ring id 0 entries 16 base_addr 88003f00a000 [ 16.292169] ath10k_pci :03:00.0: boot ce dest ring id 1 entries 512 base_addr 88003f3c8000 [ 16.292186] ath10k_pci :03:00.0: boot ce dest ring id 2 entries 128 base_addr 88003eb6a000 [ 16.292206] ath10k_pci :03:00.0: boot init ce src ring id 3 entries 32 base_addr 88003f349000 [ 16.292228] ath10k_pci :03:00.0: boot init ce src ring id 4 entries 4096 base_addr 8800ba94 [ 16.292248] ath10k_pci :03:00.0: boot init ce src ring id 7 entries 2 base_addr 8800c4888000 [ 16.292265] ath10k_pci :03:00.0: boot ce dest ring id 7 entries 2 base_addr 8800ba889000 [ 16.292267] ath10k_pci :03:00.0: boot waiting target to initialise [ 16.292272] ath10k_pci :03:00.0: boot target indicator 0 [ 16.302326] ath10k_pci :03:00.0: boot target indicator 2 [ 16.302335] ath10k_pci :03:00.0: boot target initialised [ 16.302336] ath10k_pci :03:00.0: boot warm reset complete [ 16.302337] ath10k_pci :03:00.0: boot qca6174 chip reset complete (cold) [ 16.302350] ath10k_pci :03:00.0: boot hif power up [ 16.302408] ath10k_pci :03:00.0: boot qca6174 chip reset [ 16.302409] ath10k_pci :03:00.0: boot cold reset [ 16.306030] ath10k_pci :03:00.0: boot cold reset complete [ 16.306033] ath10k_pci :03:00.0: boot waiting target to initialise [ 16.306037] ath10k_pci :03:00.0: boot target indicator 0 [ 16.316044] ath10k_pci :03:00.0: boot target indicator 2 [ 16.316056] ath10k_pci :03:00.0: boot target initialised [ 16.316057] ath10k_pci :03:00.0: boot warm reset [ 16.338057] ath10k_pci :03:00.0: boot init ce src ring id 0 entries 16 base_addr 88003f00a000 [ 16.338075] ath10k_pci :03:00.0: boot ce dest ring id 1 entries 512 base_addr 88003f3c8000 [ 16.338092] ath10k_pci :03:00.0: boot ce dest ring id 2 entries 128 base_addr 88003eb6a000 [ 16.338111] ath10k_pci :03:00.0: boot init ce src ring id 3 entries 32 base_addr 88003f349000 [ 16.338132] ath10k_pci :03:00.0: boot init ce src ring id 4 entries 4096 base_addr 8800ba94 [ 16.338152] ath10k_pci :03:00.0: boot init ce src ring id 7 entries 2 base_addr 8800c4888000 [ 16.338169] ath10k_pci :03:00.0: boot ce dest ring id 7 entries 2 base_addr 8800ba889000 [ 16.338169] ath10k_pci :03:00.0: boot waiting target to initialise [ 16.338174] ath10k_pci :03:00.0: boot target indicator 0 [ 16.348187] ath10k_pci :03:00.0: boot target indicator 2 [ 16.348196] ath10k_pci :03:00.0: boot target initialised [ 16.359038] ath10k_pci :03:00.0: boot init ce src ring id 0 entries 16 base_addr 88003f00a000 [ 16.359055] ath10k_pci :03:00.0: boot ce dest ring id 1 entries 512 base_addr 88003f3c8000 [ 16.359072] ath10k_pci :03:00.0: boot ce dest ring id 2 entries 128 base_addr 88003eb6a000 [ 16.359092] ath10k_pci :03:00.0: boot init ce src ring id 3 ent
Re: QCA6174 hw2.1 irq_mode=0 broken on 4.2-rc3, working on 4.1.2
Sound! I'll keep a copy of the log then. If the bisect on ath10k folder will lead nowhere I'll see if I can make it over the whole tree. At least by doing it on the ath10k tree I hope to narrow down the number of commit. Ok then I'll use Linus' master, no problem with this. I hope to at least get started this weekend. On 29 July 2015 at 11:30, Kalle Valo wrote: > Enrico Tagliavini writes: > >> Yeah that's what I meant. My idea was to first bisect only the ath10k >> directory, so restricting the bisect on the commits touching stuff >> there. I guess if the issue is more broad it will come up somewhere >> else as well, so this is a good starting point, I hope. Thank you for >> pointing it out though, this will actually be the first time I do a >> proper bisect. > > And remember to always to mention if you have restricted the bisect > somehow, that's important information. And better if you provide 'git > bisect log' output as well. > >> Also do you want me to bisect Kalle's sources or Linus' master? By >> what Michał said I guess Kalle's but I ask to be sure. >> >> Also to be clear: I'm using Linus' sources at the moment, as provided >> by Fedora rawhide. >> >> For me it's the same, so let me know what you prefer and is more >> useful to solve this issue. > > Good that you brought this up. As ath.git master branch gets rebased > every rc1 release you really cannot use that for bisect. Either you > should use ath.git ath-next branch or Linus' tree. To be on the safe > side I always recommend to use Linus' tree if at all possible. > > -- > Kalle Valo ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: QCA6174 hw2.1 irq_mode=0 broken on 4.2-rc3, working on 4.1.2
Enrico Tagliavini writes: > Yeah that's what I meant. My idea was to first bisect only the ath10k > directory, so restricting the bisect on the commits touching stuff > there. I guess if the issue is more broad it will come up somewhere > else as well, so this is a good starting point, I hope. Thank you for > pointing it out though, this will actually be the first time I do a > proper bisect. And remember to always to mention if you have restricted the bisect somehow, that's important information. And better if you provide 'git bisect log' output as well. > Also do you want me to bisect Kalle's sources or Linus' master? By > what Michał said I guess Kalle's but I ask to be sure. > > Also to be clear: I'm using Linus' sources at the moment, as provided > by Fedora rawhide. > > For me it's the same, so let me know what you prefer and is more > useful to solve this issue. Good that you brought this up. As ath.git master branch gets rebased every rc1 release you really cannot use that for bisect. Either you should use ath.git ath-next branch or Linus' tree. To be on the safe side I always recommend to use Linus' tree if at all possible. -- Kalle Valo ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: QCA6174 hw2.1 irq_mode=0 broken on 4.2-rc3, working on 4.1.2
Yeah that's what I meant. My idea was to first bisect only the ath10k directory, so restricting the bisect on the commits touching stuff there. I guess if the issue is more broad it will come up somewhere else as well, so this is a good starting point, I hope. Thank you for pointing it out though, this will actually be the first time I do a proper bisect. Also do you want me to bisect Kalle's sources or Linus' master? By what Michał said I guess Kalle's but I ask to be sure. Also to be clear: I'm using Linus' sources at the moment, as provided by Fedora rawhide. For me it's the same, so let me know what you prefer and is more useful to solve this issue. On 29 July 2015 at 08:54, Kalle Valo wrote: > Michal Kazior writes: > >>> This wont work for bisecting. I have to setup something else. Is >>> it ok if I restrict the bisect on the ath10k tree? That has enough >>> commit already to begin with, plus I'm going to be on the road in less >>> than two weeks. >> >> As long as you establish a working and a non-working commit id on >> kvalo tree it should be fine I guess. > > And you can always limit the bisect to a certain directory, but the risk > here is that if the regression is outside ath10k bisect won't find it. > So you need to carefully consider is it safe to do or not. From the man > page: > > "Cutting down bisection by giving more parameters to bisect start > >You can further cut down the number of trials, if you know what >part of the tree is involved in the problem you are tracking >down, by specifying path parameters when issuing the bisect start >command: > >$ git bisect start -- arch/i386 include/asm-i386" > > Also if you can even just narrow down the regression to a smaller set of > patches, let's say few hundred, might make it easier to find the > regression. > > -- > Kalle Valo ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: QCA6174 hw2.1 irq_mode=0 broken on 4.2-rc3, working on 4.1.2
Michal Kazior writes: >> This wont work for bisecting. I have to setup something else. Is >> it ok if I restrict the bisect on the ath10k tree? That has enough >> commit already to begin with, plus I'm going to be on the road in less >> than two weeks. > > As long as you establish a working and a non-working commit id on > kvalo tree it should be fine I guess. And you can always limit the bisect to a certain directory, but the risk here is that if the regression is outside ath10k bisect won't find it. So you need to carefully consider is it safe to do or not. From the man page: "Cutting down bisection by giving more parameters to bisect start You can further cut down the number of trials, if you know what part of the tree is involved in the problem you are tracking down, by specifying path parameters when issuing the bisect start command: $ git bisect start -- arch/i386 include/asm-i386" Also if you can even just narrow down the regression to a smaller set of patches, let's say few hundred, might make it easier to find the regression. -- Kalle Valo ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: QCA6174 hw2.1 irq_mode=0 broken on 4.2-rc3, working on 4.1.2
On 28 July 2015 at 16:57, Enrico Tagliavini wrote: > I was testing the kernel from Fedora rawhide to test some issue > related to the sound card. So this is 4.2 rc3 as released by Linus > plus some Fedora patch. Nothing related to ath10k as far as I can see. > > Bisecting would require a lot of time. I'm doing the full RPM package, > including modules signature and so on and I'm doing this in my free > time. I understand. > This wont work for bisecting. I have to setup something else. Is > it ok if I restrict the bisect on the ath10k tree? That has enough > commit already to begin with, plus I'm going to be on the road in less > than two weeks. As long as you establish a working and a non-working commit id on kvalo tree it should be fine I guess. Michał ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: QCA6174 hw2.1 irq_mode=0 broken on 4.2-rc3, working on 4.1.2
On 28 July 2015 at 17:12, Alexandre Maloteaux wrote: [...] > It works on my archlinux system but firmware loading take 1 minute > between each retry, so it takes 2 minutes to get the card up and > running. I have not yet found a solution to this issue. Go ask on the arch forum or lurk for udev firmware timeouts thread. It's not entirely new and I'm betting this has been solved many times already. Michał ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: QCA6174 hw2.1 irq_mode=0 broken on 4.2-rc3, working on 4.1.2
Hi Alexandre, I think you have a different issue. In my case it doesn't take long to load the firmware. It works for me as well with irq_mode=1, however this was not needed with the previous kernel (4.1.2 as provided by fedora updates-testing repo). Also Michał sees a problem with my system. I should also mention I made my firmware from the Windows driver with dissect.py. I assume this is correct since it worked for an older kernel, but I actually have no idea. And I also have no idea how to generate the fw with API 5 (if this makes any difference, but since it was not mentioned already I suppose it does not). Thank you anyway :) On 28 July 2015 at 17:12, Alexandre Maloteaux wrote: > Hi Enrico > > I had the same issue a few days ago on an Eurocom P5 Pro. > I manage to get it working with the help of michal by compiling the > kvalo kernel master branch : https://github.com/kvalo/ath > > And then using this ath10k.conf file in /etc/modprobe.d > > options ath10k_core skip_otp=y > options ath10k_pci irq_mode=1 > > It works on my archlinux system but firmware loading take 1 minute > between each retry, so it takes 2 minutes to get the card up and > running. I have not yet found a solution to this issue. > > Best Regards > > On 07/28/2015 03:57 PM, Enrico Tagliavini wrote: >> I was testing the kernel from Fedora rawhide to test some issue >> related to the sound card. So this is 4.2 rc3 as released by Linus >> plus some Fedora patch. Nothing related to ath10k as far as I can see. >> >> Bisecting would require a lot of time. I'm doing the full RPM package, fe >> including modules signature and so on and I'm doing this in my free >> time.This wont work for bisecting. I have to setup something else. Is >> it ok if I restrict the bisect on the ath10k tree? That has enough >> commit already to begin with, plus I'm going to be on the road in less >> than two weeks. >> >> On 28 July 2015 at 13:26, Michal Kazior wrote: >>> On 28 July 2015 at 13:00, Enrico Tagliavini >>> wrote: Hi Michal, this is the dmesg output from a boot with kernel 4.1.2 with patch to make the firmware load [1] Jul 26 10:07:42 alientux.saurisiamonoi.org kernel: ath10k_pci :03:00.0: enabling device ( -> 0002) Jul 26 10:07:42 alientux.saurisiamonoi.org kernel: ath10k_pci :03:00.0: pci irq msi-x interrupts 8 irq_mode 0 reset_mode 0 Jul 26 10:07:42 alientux.saurisiamonoi.org kernel: ath10k_pci :03:00.0: Direct firmware load for ath10k/cal-pci-:03:00.0.bin failed with error -2 Jul 26 10:07:44 alientux.saurisiamonoi.org kernel: ath10k_pci :03:00.0: qca6174 hw2.1 (0x0501, 0x003405ff) fw killer-n1525-fw api 4 htt 3.0 wmi 4 cal otp max_sta 32 Jul 26 10:07:44 alientux.saurisiamonoi.org kernel: ath10k_pci :03:00.0: debug 0 debugfs 1 tracing 0 dfs 0 testmode 0 Jul 26 10:07:44 alientux.saurisiamonoi.org kernel: ath10k_pci :03:00.0 wlp3s0: renamed from wlan0 I saw the report you mentioned (I'm subscribed to ath10k and try to keep it up with it). Not being expert at all I was not sure it was the same or not. Also there seems to be a difference that with irq_mode=1 for me it just works like before. >>> I'm quite puzzled with the above printout. So either there's some >>> weird regression either in driver or the pci subsystem. It's good you >>> posted ;-) >>> >>> Just to be clear: were you using 4.2-rc3 as in from Linus' tree or Kalle's >>> tree? >>> >>> Asking for a `git bisect` is probably a bit excessive - but it would >>> help a lot. I guess you'd have to manually cherry-pick qca6174 hw2 fix >>> [1] while bisecting. >>> >>> If bisect is too much I guess you could try reverting (in order): >>> >>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/net/wireless/ath/ath10k?id=0bcbbe679b66fee1b56def5cb30bfb4f616b1127 >>> >>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/net/wireless/ath/ath10k?id=76d870ed09ab34154454b1adb823ae75f173c2d2 >>> >>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/net/wireless/ath/ath10k?id=77258d409ce45890104e3da11d0261402c49aee1 >>> >>> I'm shooting blind here though. >>> [1] https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/net/wireless/ath/ath10k/pci.c?id=11a002efbaa7fbd9f6e616695ab42aa9f1caf060 >>> >>> 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 ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: QCA6174 hw2.1 irq_mode=0 broken on 4.2-rc3, working on 4.1.2
Hi Enrico I had the same issue a few days ago on an Eurocom P5 Pro. I manage to get it working with the help of michal by compiling the kvalo kernel master branch : https://github.com/kvalo/ath And then using this ath10k.conf file in /etc/modprobe.d options ath10k_core skip_otp=y options ath10k_pci irq_mode=1 It works on my archlinux system but firmware loading take 1 minute between each retry, so it takes 2 minutes to get the card up and running. I have not yet found a solution to this issue. Best Regards On 07/28/2015 03:57 PM, Enrico Tagliavini wrote: > I was testing the kernel from Fedora rawhide to test some issue > related to the sound card. So this is 4.2 rc3 as released by Linus > plus some Fedora patch. Nothing related to ath10k as far as I can see. > > Bisecting would require a lot of time. I'm doing the full RPM package, fe > including modules signature and so on and I'm doing this in my free > time.This wont work for bisecting. I have to setup something else. Is > it ok if I restrict the bisect on the ath10k tree? That has enough > commit already to begin with, plus I'm going to be on the road in less > than two weeks. > > On 28 July 2015 at 13:26, Michal Kazior wrote: >> On 28 July 2015 at 13:00, Enrico Tagliavini >> wrote: >>> Hi Michal, >>> >>> this is the dmesg output from a boot with kernel 4.1.2 with patch to >>> make the firmware load [1] >>> >>> Jul 26 10:07:42 alientux.saurisiamonoi.org kernel: ath10k_pci >>> :03:00.0: enabling device ( -> 0002) >>> Jul 26 10:07:42 alientux.saurisiamonoi.org kernel: ath10k_pci >>> :03:00.0: pci irq msi-x interrupts 8 irq_mode 0 reset_mode 0 >>> Jul 26 10:07:42 alientux.saurisiamonoi.org kernel: ath10k_pci >>> :03:00.0: Direct firmware load for ath10k/cal-pci-:03:00.0.bin >>> failed with error -2 >>> Jul 26 10:07:44 alientux.saurisiamonoi.org kernel: ath10k_pci >>> :03:00.0: qca6174 hw2.1 (0x0501, 0x003405ff) fw >>> killer-n1525-fw api 4 htt 3.0 wmi 4 cal otp max_sta 32 >>> Jul 26 10:07:44 alientux.saurisiamonoi.org kernel: ath10k_pci >>> :03:00.0: debug 0 debugfs 1 tracing 0 dfs 0 testmode 0 >>> Jul 26 10:07:44 alientux.saurisiamonoi.org kernel: ath10k_pci >>> :03:00.0 wlp3s0: renamed from wlan0 >>> >>> I saw the report you mentioned (I'm subscribed to ath10k and try to >>> keep it up with it). Not being expert at all I was not sure it was the >>> same or not. Also there seems to be a difference that with irq_mode=1 >>> for me it just works like before. >> I'm quite puzzled with the above printout. So either there's some >> weird regression either in driver or the pci subsystem. It's good you >> posted ;-) >> >> Just to be clear: were you using 4.2-rc3 as in from Linus' tree or Kalle's >> tree? >> >> Asking for a `git bisect` is probably a bit excessive - but it would >> help a lot. I guess you'd have to manually cherry-pick qca6174 hw2 fix >> [1] while bisecting. >> >> If bisect is too much I guess you could try reverting (in order): >> >> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/net/wireless/ath/ath10k?id=0bcbbe679b66fee1b56def5cb30bfb4f616b1127 >> >> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/net/wireless/ath/ath10k?id=76d870ed09ab34154454b1adb823ae75f173c2d2 >> >> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/net/wireless/ath/ath10k?id=77258d409ce45890104e3da11d0261402c49aee1 >> >> I'm shooting blind here though. >> >>> [1] >>> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/net/wireless/ath/ath10k/pci.c?id=11a002efbaa7fbd9f6e616695ab42aa9f1caf060 >> >> 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 hw2.1 irq_mode=0 broken on 4.2-rc3, working on 4.1.2
I was testing the kernel from Fedora rawhide to test some issue related to the sound card. So this is 4.2 rc3 as released by Linus plus some Fedora patch. Nothing related to ath10k as far as I can see. Bisecting would require a lot of time. I'm doing the full RPM package, including modules signature and so on and I'm doing this in my free time.This wont work for bisecting. I have to setup something else. Is it ok if I restrict the bisect on the ath10k tree? That has enough commit already to begin with, plus I'm going to be on the road in less than two weeks. On 28 July 2015 at 13:26, Michal Kazior wrote: > On 28 July 2015 at 13:00, Enrico Tagliavini > wrote: >> Hi Michal, >> >> this is the dmesg output from a boot with kernel 4.1.2 with patch to >> make the firmware load [1] >> >> Jul 26 10:07:42 alientux.saurisiamonoi.org kernel: ath10k_pci >> :03:00.0: enabling device ( -> 0002) >> Jul 26 10:07:42 alientux.saurisiamonoi.org kernel: ath10k_pci >> :03:00.0: pci irq msi-x interrupts 8 irq_mode 0 reset_mode 0 >> Jul 26 10:07:42 alientux.saurisiamonoi.org kernel: ath10k_pci >> :03:00.0: Direct firmware load for ath10k/cal-pci-:03:00.0.bin >> failed with error -2 >> Jul 26 10:07:44 alientux.saurisiamonoi.org kernel: ath10k_pci >> :03:00.0: qca6174 hw2.1 (0x0501, 0x003405ff) fw >> killer-n1525-fw api 4 htt 3.0 wmi 4 cal otp max_sta 32 >> Jul 26 10:07:44 alientux.saurisiamonoi.org kernel: ath10k_pci >> :03:00.0: debug 0 debugfs 1 tracing 0 dfs 0 testmode 0 >> Jul 26 10:07:44 alientux.saurisiamonoi.org kernel: ath10k_pci >> :03:00.0 wlp3s0: renamed from wlan0 >> >> I saw the report you mentioned (I'm subscribed to ath10k and try to >> keep it up with it). Not being expert at all I was not sure it was the >> same or not. Also there seems to be a difference that with irq_mode=1 >> for me it just works like before. > > I'm quite puzzled with the above printout. So either there's some > weird regression either in driver or the pci subsystem. It's good you > posted ;-) > > Just to be clear: were you using 4.2-rc3 as in from Linus' tree or Kalle's > tree? > > Asking for a `git bisect` is probably a bit excessive - but it would > help a lot. I guess you'd have to manually cherry-pick qca6174 hw2 fix > [1] while bisecting. > > If bisect is too much I guess you could try reverting (in order): > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/net/wireless/ath/ath10k?id=0bcbbe679b66fee1b56def5cb30bfb4f616b1127 > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/net/wireless/ath/ath10k?id=76d870ed09ab34154454b1adb823ae75f173c2d2 > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/net/wireless/ath/ath10k?id=77258d409ce45890104e3da11d0261402c49aee1 > > I'm shooting blind here though. > >> [1] >> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/net/wireless/ath/ath10k/pci.c?id=11a002efbaa7fbd9f6e616695ab42aa9f1caf060 > > > Michał ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: QCA6174 hw2.1 irq_mode=0 broken on 4.2-rc3, working on 4.1.2
On 28 July 2015 at 13:00, Enrico Tagliavini wrote: > Hi Michal, > > this is the dmesg output from a boot with kernel 4.1.2 with patch to > make the firmware load [1] > > Jul 26 10:07:42 alientux.saurisiamonoi.org kernel: ath10k_pci > :03:00.0: enabling device ( -> 0002) > Jul 26 10:07:42 alientux.saurisiamonoi.org kernel: ath10k_pci > :03:00.0: pci irq msi-x interrupts 8 irq_mode 0 reset_mode 0 > Jul 26 10:07:42 alientux.saurisiamonoi.org kernel: ath10k_pci > :03:00.0: Direct firmware load for ath10k/cal-pci-:03:00.0.bin > failed with error -2 > Jul 26 10:07:44 alientux.saurisiamonoi.org kernel: ath10k_pci > :03:00.0: qca6174 hw2.1 (0x0501, 0x003405ff) fw > killer-n1525-fw api 4 htt 3.0 wmi 4 cal otp max_sta 32 > Jul 26 10:07:44 alientux.saurisiamonoi.org kernel: ath10k_pci > :03:00.0: debug 0 debugfs 1 tracing 0 dfs 0 testmode 0 > Jul 26 10:07:44 alientux.saurisiamonoi.org kernel: ath10k_pci > :03:00.0 wlp3s0: renamed from wlan0 > > I saw the report you mentioned (I'm subscribed to ath10k and try to > keep it up with it). Not being expert at all I was not sure it was the > same or not. Also there seems to be a difference that with irq_mode=1 > for me it just works like before. I'm quite puzzled with the above printout. So either there's some weird regression either in driver or the pci subsystem. It's good you posted ;-) Just to be clear: were you using 4.2-rc3 as in from Linus' tree or Kalle's tree? Asking for a `git bisect` is probably a bit excessive - but it would help a lot. I guess you'd have to manually cherry-pick qca6174 hw2 fix [1] while bisecting. If bisect is too much I guess you could try reverting (in order): https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/net/wireless/ath/ath10k?id=0bcbbe679b66fee1b56def5cb30bfb4f616b1127 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/net/wireless/ath/ath10k?id=76d870ed09ab34154454b1adb823ae75f173c2d2 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/net/wireless/ath/ath10k?id=77258d409ce45890104e3da11d0261402c49aee1 I'm shooting blind here though. > [1] > https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/net/wireless/ath/ath10k/pci.c?id=11a002efbaa7fbd9f6e616695ab42aa9f1caf060 Michał ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: QCA6174 hw2.1 irq_mode=0 broken on 4.2-rc3, working on 4.1.2
Hi Michal, this is the dmesg output from a boot with kernel 4.1.2 with patch to make the firmware load [1] Jul 26 10:07:42 alientux.saurisiamonoi.org kernel: ath10k_pci :03:00.0: enabling device ( -> 0002) Jul 26 10:07:42 alientux.saurisiamonoi.org kernel: ath10k_pci :03:00.0: pci irq msi-x interrupts 8 irq_mode 0 reset_mode 0 Jul 26 10:07:42 alientux.saurisiamonoi.org kernel: ath10k_pci :03:00.0: Direct firmware load for ath10k/cal-pci-:03:00.0.bin failed with error -2 Jul 26 10:07:44 alientux.saurisiamonoi.org kernel: ath10k_pci :03:00.0: qca6174 hw2.1 (0x0501, 0x003405ff) fw killer-n1525-fw api 4 htt 3.0 wmi 4 cal otp max_sta 32 Jul 26 10:07:44 alientux.saurisiamonoi.org kernel: ath10k_pci :03:00.0: debug 0 debugfs 1 tracing 0 dfs 0 testmode 0 Jul 26 10:07:44 alientux.saurisiamonoi.org kernel: ath10k_pci :03:00.0 wlp3s0: renamed from wlan0 I saw the report you mentioned (I'm subscribed to ath10k and try to keep it up with it). Not being expert at all I was not sure it was the same or not. Also there seems to be a difference that with irq_mode=1 for me it just works like before. [1] https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/net/wireless/ath/ath10k/pci.c?id=11a002efbaa7fbd9f6e616695ab42aa9f1caf060 On 28 July 2015 at 06:31, Michal Kazior wrote: > On 27 July 2015 at 22:08, Enrico Tagliavini > wrote: >> Hello there, >> >> I gave 4.2 rc3 a shot and I discovered the wireless was not working >> anymore with it. I tried adding irq_mode=1 alongside skip_otp=y in >> ath10k_core (I assume you need fw api 5 to remove this, is that >> correct?, I still have fw 4 only). >> >> Loading with irq_mode=0 >> >> [ 21.130224] ath10k_pci :03:00.0: enabling device ( -> 0002) >> [ 21.130734] ath10k_pci :03:00.0: pci irq msi-x interrupts 8 >> irq_mode 0 reset_mode 0 > > There was already a similar report[1]. Just for the record: what > number of interrupts did you have before 4.2-rc3? I assume it was "pci > irq msi interrupts 1 irq_mode 0 reset_mode 0". > > My suspicion is that either the firmware is buggy and doesn't play > well with multiple MSI interrupts or the MSI interrupt behaviour > changed significantly (compared to qca988x) and this remained hidden > because not an awful lot of machines seemed to have provided more than > 1 msi interrupt for ath10k. > > [1]: http://lists.infradead.org/pipermail/ath10k/2015-July/005695.html > > > Michał ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: QCA6174 hw2.1 irq_mode=0 broken on 4.2-rc3, working on 4.1.2
On 27 July 2015 at 22:08, Enrico Tagliavini wrote: > Hello there, > > I gave 4.2 rc3 a shot and I discovered the wireless was not working > anymore with it. I tried adding irq_mode=1 alongside skip_otp=y in > ath10k_core (I assume you need fw api 5 to remove this, is that > correct?, I still have fw 4 only). > > Loading with irq_mode=0 > > [ 21.130224] ath10k_pci :03:00.0: enabling device ( -> 0002) > [ 21.130734] ath10k_pci :03:00.0: pci irq msi-x interrupts 8 > irq_mode 0 reset_mode 0 There was already a similar report[1]. Just for the record: what number of interrupts did you have before 4.2-rc3? I assume it was "pci irq msi interrupts 1 irq_mode 0 reset_mode 0". My suspicion is that either the firmware is buggy and doesn't play well with multiple MSI interrupts or the MSI interrupt behaviour changed significantly (compared to qca988x) and this remained hidden because not an awful lot of machines seemed to have provided more than 1 msi interrupt for ath10k. [1]: http://lists.infradead.org/pipermail/ath10k/2015-July/005695.html Michał ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: QCA6174 hw2.1 on Clevo P750ZM
Hi i would like to test with other board.bin but i m facing the timeout issue. Each time the ath10k_pci module fail with a firmware there is a timeout of 1 minute before testing the next one. Any idea what could help ? [Fri Jul 24 11:10:02 2015] ath10k_pci :06:00.0: pci irq legacy interrupts 0 irq_mode 1 reset_mode 0 [Fri Jul 24 11:10:03 2015] ath10k_pci :06:00.0: Direct firmware load for ath10k/cal-pci-:06:00.0.bin failed with error -2 [Fri Jul 24 11:10:03 2015] ath10k_pci :06:00.0: Falling back to user helper [Fri Jul 24 11:11:03 2015] ath10k_pci :06:00.0: Direct firmware load for ath10k/QCA6174/hw2.1/firmware-5.bin failed with error -2 [Fri Jul 24 11:11:03 2015] ath10k_pci :06:00.0: Falling back to user helper [Fri Jul 24 11:12:03 2015] ath10k_pci :06:00.0: could not fetch firmware file 'ath10k/QCA6174/hw2.1/firmware-5.bin': -11 [Fri Jul 24 11:12:04 2015] ath10k_pci :06:00.0: qca6174 hw2.1 (0x0501, 0x003405ff, 168c:003e:1a56:1525) fw killer-n1525-fw api 4 htt-ver 3.0 wmi-op 4 htt-op 3 cal otp max-sta 32 features \xff80\xff94\xfff8\xff96\xff88\x\x [Fri Jul 24 11:12:04 2015] ath10k_pci :06:00.0: debug 1 debugfs 1 tracing 1 dfs 0 testmode 0 [Fri Jul 24 11:12:04 2015] ath: EEPROM regdomain: 0x6c [Fri Jul 24 11:12:04 2015] ath: EEPROM indicates we should expect a direct regpair map [Fri Jul 24 11:12:04 2015] ath: Country alpha2 being used: 00 [Fri Jul 24 11:12:04 2015] ath: Regpair used: 0x6c [Fri Jul 24 11:12:04 2015] ath10k_pci :06:00.0 wlp6s0: renamed from wlan0 [Fri Jul 24 11:14:42 2015] ath10k_pci :06:00.0: no channel configured; ignoring frame(s)! [Fri Jul 24 11:19:57 2015] ath10k_pci :06:00.0: no channel configured; ignoring frame(s)! [Fri Jul 24 11:21:00 2015] ath10k_pci :06:00.0: no channel configured; ignoring frame(s)! [Fri Jul 24 11:21:00 2015] ath10k_pci :06:00.0: no channel configured; ignoring frame(s)! [Fri Jul 24 11:34:54 2015] CPU: 2 PID: 14153 Comm: hexchat Tainted: P O4.2.0-rc3-wl-ath-KVALO-ATH-MASTER+ #4 [Fri Jul 24 11:34:54 2015] [] entry_SYSCALL_64_fastpath+0x12/0x71 [Fri Jul 24 11:37:50 2015] ath10k_pci :06:00.0: no channel configured; ignoring frame(s)! On 07/23/2015 03:03 PM, Kalle Valo wrote: > Alexandre Maloteaux writes: > >> 0x003405ff, 168c:003e:1a56:1525 fallback) fw killer-n1525-fw api 4 >> htt-ver 3.0 wmi-op 4 htt-op 3 cal otp max-sta 32 features >> \xff80\xffd4\xffa8\xfff9\xff88\x\x > What's happening with the features string here? What might cause that? > ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: QCA6174 hw2.1 on Clevo P750ZM
> What's happening with the features string here? What might cause that? I used the sumdog binaries from github,maybe this is related. I ll try with my own firmware-4.bin from dissect/assemble and board.bin from clevo driver and i ll report if i get the same string On 07/23/2015 03:03 PM, Kalle Valo wrote: > Alexandre Maloteaux writes: > >> 0x003405ff, 168c:003e:1a56:1525 fallback) fw killer-n1525-fw api 4 >> htt-ver 3.0 wmi-op 4 htt-op 3 cal otp max-sta 32 features >> \xff80\xffd4\xffa8\xfff9\xff88\x\x > What's happening with the features string here? What might cause that? > ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: QCA6174 hw2.1 on Clevo P750ZM
Alexandre Maloteaux writes: > 0x003405ff, 168c:003e:1a56:1525 fallback) fw killer-n1525-fw api 4 > htt-ver 3.0 wmi-op 4 htt-op 3 cal otp max-sta 32 features > \xff80\xffd4\xffa8\xfff9\xff88\x\x What's happening with the features string here? What might cause that? -- Kalle Valo ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: QCA6174 hw2.1 on Clevo P750ZM
Hi Michal It is finally working with irq_mode=1 and kvalo-master . The output is below; However it takes a lot of time to load/unload the device with successive firmwares. I ll try to find a solution for this on my own. Is it better to blacklist some module as you said earlier or create a modprobe.d rule with irq_mode=1 ? Thanks a lot for knowledge and time shared !! output : [ 315.417575] ath10k_pci :06:00.0: pci irq legacy interrupts 0 irq_mode 1 reset_mode 0 [ 315.661404] ath10k_pci :06:00.0: Direct firmware load for ath10k/cal-pci-:06:00.0.bin failed with error -2 [ 315.661406] ath10k_pci :06:00.0: Falling back to user helper [ 375.755105] ath10k_pci :06:00.0: Direct firmware load for ath10k/QCA6174/hw2.1/board-pci-168c:003e:1a56:1525.bin failed with error -2 [ 375.755107] ath10k_pci :06:00.0: Falling back to user helper [ 435.850288] ath10k_pci :06:00.0: failed to load spec board file, falling back to generic: -11 [ 435.850328] ath10k_pci :06:00.0: Direct firmware load for ath10k/QCA6174/hw2.1/firmware-5.bin failed with error -2 [ 435.850330] ath10k_pci :06:00.0: Falling back to user helper [ 495.945454] ath10k_pci :06:00.0: could not fetch firmware file 'ath10k/QCA6174/hw2.1/firmware-5.bin': -11 [ 497.140018] ath10k_pci :06:00.0: qca6174 hw2.1 (0x0501, 0x003405ff, 168c:003e:1a56:1525 fallback) fw killer-n1525-fw api 4 htt-ver 3.0 wmi-op 4 htt-op 3 cal otp max-sta 32 features \xff80\xffd4\xffa8\xfff9\xff88\x\x [ 497.140021] ath10k_pci :06:00.0: debug 1 debugfs 1 tracing 1 dfs 0 testmode 0 [ 497.218423] ath: EEPROM regdomain: 0x6c [ 497.218426] ath: EEPROM indicates we should expect a direct regpair map [ 497.218427] ath: Country alpha2 being used: 00 [ 497.218427] ath: Regpair used: 0x6c [ 497.222363] ath10k_pci :06:00.0 wlp6s0: renamed from wlan0 [ 1349.087696] ath10k_pci :06:00.0: no channel configured; ignoring frame(s)! Best Regards On 07/23/2015 11:38 AM, Alexandre Maloteaux wrote: > Yes sorry i reposted on the mailing list as soon as i noticed the > mistake :) > > On 07/23/2015 11:29 AM, Michal Kazior wrote: >> Try not to email me privately when discussing in public unless there's >> a good reason to do so, please. >> >> >> On 23 July 2015 at 12:11, Alexandre Maloteaux wrote: >>> Hi Michal >>> >>> With latest kvalo-master. I m getting this error on boot and after >>> irq_mode=1 >>> I used sumdog firmwares from github : >>> >>> [ 255.996373] ath10k_pci :06:00.0: enabling device ( -> 0002) >>> [ 255.997129] ath10k_pci :06:00.0: pci irq msi-x interrupts 8 >>> irq_mode 0 reset_mode 0 >>> [ 256.174560] ath10k_pci :06:00.0: Direct firmware load for >>> ath10k/cal-pci-:06:00.0.bin failed with error -2 >>> [ 256.174562] ath10k_pci :06:00.0: Falling back to user helper >>> [ 316.269053] ath10k_pci :06:00.0: Direct firmware load for >>> ath10k/QCA6174/hw2.1/board-pci-168c:003e:1a56:1525.bin failed with error -2 >>> [ 316.269061] ath10k_pci :06:00.0: Falling back to user helper >>> [ 376.362848] ath10k_pci :06:00.0: failed to load spec board file, >>> falling back to generic: -11 >>> [ 376.363326] ath10k_pci :06:00.0: Direct firmware load for >>> ath10k/QCA6174/hw2.1/firmware-5.bin failed with error -2 >>> [ 376.36] ath10k_pci :06:00.0: Falling back to user helper >>> [ 436.458041] ath10k_pci :06:00.0: could not fetch firmware file >>> 'ath10k/QCA6174/hw2.1/firmware-5.bin': -11 >>> [ 437.634407] ath10k_pci :06:00.0: received unsolicited fw crash >>> interrupt >>> [ 437.634415] ath10k_pci :06:00.0: received unsolicited fw crash >>> interrupt >>> [ 438.634688] ath10k_pci :06:00.0: failed to receive control >>> response completion, polling.. >>> [ 438.634767] ath10k_pci :06:00.0: received unsolicited fw crash >>> interrupt >>> [ 438.634790] ath10k_pci :06:00.0: received unsolicited fw crash >>> interrupt >>> [ 439.636320] ath10k_pci :06:00.0: Service connect timeout >>> [ 439.636325] ath10k_pci :06:00.0: failed to connect htt (-110) >>> [ 439.706905] ath10k_pci :06:00.0: could not init core (-110) >>> [ 439.706929] ath10k_pci :06:00.0: could not probe fw (-110) >> The above is previous attempt without irq_mode being set so can be ignored. >> >> >>> [ 515.965549] ath10k_pci :06:00.0: limiting irq mode to: 1 >>> >>> [ 515.965557] ath10k_pci :06:00.0: pci irq legacy interrupts 0 >>> irq_mode 1 reset_mode 0 >>> [ 516.202334] ath10k_pci :06:00.0: Direct firmware load for >>> ath10k/cal-pci-:06:00.0.bin failed with error -2 >>> [ 516.202335] ath10k_pci :06:00.0: Falling back to user helper >>> [ 576.296201] ath10k_pci :06:00.0: Direct firmware load for >>> ath10k/QCA6174/hw2.1/board-pci-168c:003e:1a56:1525.bin failed with error -2 >>> [ 576.296210] ath10k_pci :06:00.0: Falling back to user helper >> You seem to be having really long timeouts when probing fw fi
Re: QCA6174 hw2.1 on Clevo P750ZM
Hi Michal With latest kvalo-master. I m getting this error on boot and after irq_mode=1 I used sumdog firmwares from github : [ 255.996373] ath10k_pci :06:00.0: enabling device ( -> 0002) [ 255.997129] ath10k_pci :06:00.0: pci irq msi-x interrupts 8 irq_mode 0 reset_mode 0 [ 256.174560] ath10k_pci :06:00.0: Direct firmware load for ath10k/cal-pci-:06:00.0.bin failed with error -2 [ 256.174562] ath10k_pci :06:00.0: Falling back to user helper [ 316.269053] ath10k_pci :06:00.0: Direct firmware load for ath10k/QCA6174/hw2.1/board-pci-168c:003e:1a56:1525.bin failed with error -2 [ 316.269061] ath10k_pci :06:00.0: Falling back to user helper [ 376.362848] ath10k_pci :06:00.0: failed to load spec board file, falling back to generic: -11 [ 376.363326] ath10k_pci :06:00.0: Direct firmware load for ath10k/QCA6174/hw2.1/firmware-5.bin failed with error -2 [ 376.36] ath10k_pci :06:00.0: Falling back to user helper [ 436.458041] ath10k_pci :06:00.0: could not fetch firmware file 'ath10k/QCA6174/hw2.1/firmware-5.bin': -11 [ 437.634407] ath10k_pci :06:00.0: received unsolicited fw crash interrupt [ 437.634415] ath10k_pci :06:00.0: received unsolicited fw crash interrupt [ 438.634688] ath10k_pci :06:00.0: failed to receive control response completion, polling.. [ 438.634767] ath10k_pci :06:00.0: received unsolicited fw crash interrupt [ 438.634790] ath10k_pci :06:00.0: received unsolicited fw crash interrupt [ 439.636320] ath10k_pci :06:00.0: Service connect timeout [ 439.636325] ath10k_pci :06:00.0: failed to connect htt (-110) [ 439.706905] ath10k_pci :06:00.0: could not init core (-110) [ 439.706929] ath10k_pci :06:00.0: could not probe fw (-110) [ 515.965549] ath10k_pci :06:00.0: limiting irq mode to: 1 [ 515.965557] ath10k_pci :06:00.0: pci irq legacy interrupts 0 irq_mode 1 reset_mode 0 [ 516.202334] ath10k_pci :06:00.0: Direct firmware load for ath10k/cal-pci-:06:00.0.bin failed with error -2 [ 516.202335] ath10k_pci :06:00.0: Falling back to user helper [ 576.296201] ath10k_pci :06:00.0: Direct firmware load for ath10k/QCA6174/hw2.1/board-pci-168c:003e:1a56:1525.bin failed with error -2 [ 576.296210] ath10k_pci :06:00.0: Falling back to user helper [ 636.391328] ath10k_pci :06:00.0: failed to load spec board file, falling back to generic: -11 [ 636.391402] ath10k_pci :06:00.0: Direct firmware load for ath10k/QCA6174/hw2.1/firmware-5.bin failed with error -2 [ 636.391405] ath10k_pci :06:00.0: Falling back to user helper Best Regards On 07/23/2015 10:36 AM, Michal Kazior wrote: > On 23 July 2015 at 11:33, Alexandre Maloteaux wrote: >> Hi >> >>> What is the head commit id (kvalo/master) that you've used? You might >>> be missing a patches[1][2] that fixed a recent breakage in the dev >>> tree. >> I m getting this issue only with kvalo-qca branch. >> >> With kvalo master i m getting this issue below >> >> Do you still want me to do the tracing part on kvalo-qca branch ? > No need to test kvalo-qca. Just stick with kvalo-master, please. > > >> kvalo-master : >> >> 0.00] Linux version 4.2.0-rc3-wl-ath-KVALO-ATH-MASTER+ >> (root@z1kadev) (gcc version 5.1.0 (GCC) ) #2 SMP PREEMPT Tue Jul 21 >> 15:07:02 WAT 2015 >> [ 12.381604] systemd[1]: cups.path: Cannot add dependency job, >> ignoring: Unit cups.path failed to load: No such file or directory. >> [ 12.595610] ath3k: probe of 3-7:1.0 failed with error -22 >> [ 12.595637] usbcore: registered new interface driver ath3k >> [ 12.627163] ath10k_pci :06:00.0: enabling device ( -> 0002) >> [ 12.627915] ath10k_pci :06:00.0: pci irq msi-x interrupts 8 >> irq_mode 0 reset_mode 0 > You didn't use the irq_mode=1 parameter. Can you re-test, please? > > > Michał > ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: QCA6174 hw2.1 on Clevo P750ZM
Hi > What is the head commit id (kvalo/master) that you've used? You might > be missing a patches[1][2] that fixed a recent breakage in the dev > tree. I m getting this issue only with kvalo-qca branch. With kvalo master i m getting this issue below Do you still want me to do the tracing part on kvalo-qca branch ? kvalo-master : 0.00] Linux version 4.2.0-rc3-wl-ath-KVALO-ATH-MASTER+ (root@z1kadev) (gcc version 5.1.0 (GCC) ) #2 SMP PREEMPT Tue Jul 21 15:07:02 WAT 2015 [ 12.381604] systemd[1]: cups.path: Cannot add dependency job, ignoring: Unit cups.path failed to load: No such file or directory. [ 12.595610] ath3k: probe of 3-7:1.0 failed with error -22 [ 12.595637] usbcore: registered new interface driver ath3k [ 12.627163] ath10k_pci :06:00.0: enabling device ( -> 0002) [ 12.627915] ath10k_pci :06:00.0: pci irq msi-x interrupts 8 irq_mode 0 reset_mode 0 [ 12.822155] ath10k_pci :06:00.0: Direct firmware load for ath10k/cal-pci-:06:00.0.bin failed with error -2 [ 12.822158] ath10k_pci :06:00.0: Falling back to user helper [ 72.915990] ath10k_pci :06:00.0: Direct firmware load for ath10k/QCA6174/hw2.1/board-pci-168c:003e:1a56:1525.bin failed with error -2 [ 72.915993] ath10k_pci :06:00.0: Falling back to user helper [ 133.010331] ath10k_pci :06:00.0: failed to load spec board file, falling back to generic: -11 [ 133.010647] ath10k_pci :06:00.0: Direct firmware load for ath10k/QCA6174/hw2.1/firmware-5.bin failed with error -2 [ 133.010649] ath10k_pci :06:00.0: Falling back to user helper [ 193.105501] ath10k_pci :06:00.0: could not fetch firmware file 'ath10k/QCA6174/hw2.1/firmware-5.bin': -11 [ 194.276201] ath10k_pci :06:00.0: received unsolicited fw crash interrupt [ 194.276209] ath10k_pci :06:00.0: received unsolicited fw crash interrupt [ 195.275581] ath10k_pci :06:00.0: failed to receive control response completion, polling.. [ 195.275699] ath10k_pci :06:00.0: received unsolicited fw crash interrupt [ 196.277176] ath10k_pci :06:00.0: Service connect timeout [ 196.277179] ath10k_pci :06:00.0: failed to connect htt (-110) [ 196.347791] ath10k_pci :06:00.0: could not init core (-110) [ 196.347819] ath10k_pci :06:00.0: could not probe fw (-110) On 07/23/2015 10:28 AM, Michal Kazior wrote: > On 23 July 2015 at 10:47, Alexandre Maloteaux wrote: >> Hi Michal >> >>> There's an unofficial image that's lying in a pull request on >>> github[1] you could use. It probably needs skip_otp parameter to be >>> used. >> I think this is the sumdog firmwares; i tested them and i made all the >> test with the skip_otp parameter >> >>> This looks interesting. Can you please: >>> >>> rmmod ath10k_pci >>> modprobe ath10k_pci irq_mode=1 >>> >>> Msi range handling could be broken on this hw. If so we'll need to >>> blacklist it. >> Still the same issue : >> >> [ 213.889825] ath10k_pci :06:00.0: limiting irq mode to: 1 >> [ 213.889833] ath10k_pci :06:00.0: pci irq legacy interrupts 0 >> irq_mode 1 reset_mode 0 >> [ 216.907165] ath10k_pci :06:00.0: failed to receive initialized >> event from target: b8600448 > Whoa. This value cannot be possibly correct. The register shouldn't > ever take such values. > > What is the head commit id (kvalo/master) that you've used? You might > be missing a patches[1][2] that fixed a recent breakage in the dev > tree. > > Can you make sure you test df0cf3c1249bc0c3a5a2077d6901eb90c19b7fda, please? > > When you do, and it still crashes, can you get traces[3], please? > > >> [ 216.907166] ath10k_pci :06:00.0: failed to wait for target after >> cold reset: -110 >> [ 216.907167] ath10k_pci :06:00.0: failed to reset chip: -110 >> [ 216.907220] ath10k_pci: probe of :06:00.0 failed with error -110 >> >> >>> Don't just go about renaming firmware filenames like that, please. >>> It's used to prevent older ath10k using newer firmware images which it >>> wouldn't handle anyway. >> upon those instructions : >> https://github.com/kvalo/ath10k-firmware/pull/2 >> copying firmware-4.bin to firmware-5.bin seems to help for some users > It matters not. Driver tries to fallback until it finds any > firmware-X. If it doesn't find firmware-5.bin it'll try to load > firmware-4.bin, etc. This will be accompanied by a warning in kernel > log for each fallback attempt but it's harmless. Driver doesn't > distinguish firmware functionality by filename numbering. > > > [1]: > https://github.com/kvalo/ath/commit/a052158aa981ca470673f49c636b289ee16894ea > [2]: > https://github.com/kvalo/ath/commit/3c7e256a6de378e01098147527082abae05b146e > [3]: https://wireless.wiki.kernel.org/en/users/drivers/ath10k/debug#tracing > > > Michał > >> Best Regards >> >> >> On 07/23/2015 09:21 AM, Michal Kazior wrote: >>> On 23 July 2015 at 10:05, Alexandre Maloteaux wrote: Hi I just received a Clevo P750ZM (eurocom P5 pro) with a QCA6174 06:00.0 Network controller
Re: QCA6174 hw2.1 on Clevo P750ZM
On 23 July 2015 at 11:33, Alexandre Maloteaux wrote: > Hi > >> What is the head commit id (kvalo/master) that you've used? You might >> be missing a patches[1][2] that fixed a recent breakage in the dev >> tree. > > I m getting this issue only with kvalo-qca branch. > > With kvalo master i m getting this issue below > > Do you still want me to do the tracing part on kvalo-qca branch ? No need to test kvalo-qca. Just stick with kvalo-master, please. > kvalo-master : > > 0.00] Linux version 4.2.0-rc3-wl-ath-KVALO-ATH-MASTER+ > (root@z1kadev) (gcc version 5.1.0 (GCC) ) #2 SMP PREEMPT Tue Jul 21 > 15:07:02 WAT 2015 > [ 12.381604] systemd[1]: cups.path: Cannot add dependency job, > ignoring: Unit cups.path failed to load: No such file or directory. > [ 12.595610] ath3k: probe of 3-7:1.0 failed with error -22 > [ 12.595637] usbcore: registered new interface driver ath3k > [ 12.627163] ath10k_pci :06:00.0: enabling device ( -> 0002) > [ 12.627915] ath10k_pci :06:00.0: pci irq msi-x interrupts 8 > irq_mode 0 reset_mode 0 You didn't use the irq_mode=1 parameter. Can you re-test, please? Michał ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: QCA6174 hw2.1 on Clevo P750ZM
On 23 July 2015 at 10:47, Alexandre Maloteaux wrote: > Hi Michal > >> There's an unofficial image that's lying in a pull request on >> github[1] you could use. It probably needs skip_otp parameter to be >> used. > > I think this is the sumdog firmwares; i tested them and i made all the > test with the skip_otp parameter > >> This looks interesting. Can you please: >> >> rmmod ath10k_pci >> modprobe ath10k_pci irq_mode=1 >> >> Msi range handling could be broken on this hw. If so we'll need to blacklist >> it. > > Still the same issue : > > [ 213.889825] ath10k_pci :06:00.0: limiting irq mode to: 1 > [ 213.889833] ath10k_pci :06:00.0: pci irq legacy interrupts 0 > irq_mode 1 reset_mode 0 > [ 216.907165] ath10k_pci :06:00.0: failed to receive initialized > event from target: b8600448 Whoa. This value cannot be possibly correct. The register shouldn't ever take such values. What is the head commit id (kvalo/master) that you've used? You might be missing a patches[1][2] that fixed a recent breakage in the dev tree. Can you make sure you test df0cf3c1249bc0c3a5a2077d6901eb90c19b7fda, please? When you do, and it still crashes, can you get traces[3], please? > [ 216.907166] ath10k_pci :06:00.0: failed to wait for target after > cold reset: -110 > [ 216.907167] ath10k_pci :06:00.0: failed to reset chip: -110 > [ 216.907220] ath10k_pci: probe of :06:00.0 failed with error -110 > > >> Don't just go about renaming firmware filenames like that, please. >> It's used to prevent older ath10k using newer firmware images which it >> wouldn't handle anyway. > upon those instructions : > https://github.com/kvalo/ath10k-firmware/pull/2 > copying firmware-4.bin to firmware-5.bin seems to help for some users It matters not. Driver tries to fallback until it finds any firmware-X. If it doesn't find firmware-5.bin it'll try to load firmware-4.bin, etc. This will be accompanied by a warning in kernel log for each fallback attempt but it's harmless. Driver doesn't distinguish firmware functionality by filename numbering. [1]: https://github.com/kvalo/ath/commit/a052158aa981ca470673f49c636b289ee16894ea [2]: https://github.com/kvalo/ath/commit/3c7e256a6de378e01098147527082abae05b146e [3]: https://wireless.wiki.kernel.org/en/users/drivers/ath10k/debug#tracing Michał > > Best Regards > > > On 07/23/2015 09:21 AM, Michal Kazior wrote: >> On 23 July 2015 at 10:05, Alexandre Maloteaux wrote: >>> Hi >>> >>> I just received a Clevo P750ZM (eurocom P5 pro) with a QCA6174 >>> >>> 06:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless >>> Network Adapter (rev 20) >>> >>> Hi have tested the dissect/assemble procedure described here : >>> >>> https://www.mail-archive.com/ath10k@lists.infradead.org/msg02283.html >>> https://askubuntu.com/questions/546813/killer-n1525-with-ubuntu-14-10 >> There's an unofficial image that's lying in a pull request on >> github[1] you could use. It probably needs skip_otp parameter to be >> used. >> >> >>> Im on Arch and i have tested with the Eurocom Drivers >>> (http://downloads.eurocom.com/support/drivers/zip/260/260_KillerWLAN_W864.zip) >>> and the sumdog blobs (https://github.com/sumdog/ath10k-firmware.git) >>> directly on those 3 firmwares >>> Arch official : 4.1.2-2-ARCH >>> kvalo master : 4.2.0-rc3 >>> kvalo qca branch : 4.1.0-rc6 >>> >>> I have a different issue for each kernel and i have tested with all >>> board.bin available but none worked : >>> >>> ARCH official issue : >> [snip] >> >> This won't work. 4.1 doesn't contain the necessary patch[2]. >> >> >>> kvalo master : >>> >>> [0.00] Linux version 4.2.0-rc3-wl-ath-KVALO-ATH-MASTER+ >>> (root@z1kadev) (gcc version 5.1.0 (GCC) ) #2 SMP PREEMPT Tue Jul 21 >>> 15:07:02 WAT 2015 >>> [ 12.381604] systemd[1]: cups.path: Cannot add dependency job, >>> ignoring: Unit cups.path failed to load: No such file or directory. >>> [ 12.595610] ath3k: probe of 3-7:1.0 failed with error -22 >>> [ 12.595637] usbcore: registered new interface driver ath3k >>> [ 12.627163] ath10k_pci :06:00.0: enabling device ( -> 0002) >>> [ 12.627915] ath10k_pci :06:00.0: pci irq msi-x interrupts 8 >>> irq_mode 0 reset_mode 0 >>> [ 12.822155] ath10k_pci :06:00.0: Direct firmware load for >>> ath10k/cal-pci-:06:00.0.bin failed with error -2 >>> [ 12.822158] ath10k_pci :06:00.0: Falling back to user helper >>> [ 72.915990] ath10k_pci :06:00.0: Direct firmware load for >>> ath10k/QCA6174/hw2.1/board-pci-168c:003e:1a56:1525.bin failed with error -2 >>> [ 72.915993] ath10k_pci :06:00.0: Falling back to user helper >>> [ 133.010331] ath10k_pci :06:00.0: failed to load spec board file, >>> falling back to generic: -11 >>> [ 133.010647] ath10k_pci :06:00.0: Direct firmware load for >>> ath10k/QCA6174/hw2.1/firmware-5.bin failed with error -2 >>> [ 133.010649] ath10k_pci :06:00.0: Falling back to user helper >>> [ 193.105501] ath10k_pci :06:00.0: could no
Re: QCA6174 hw2.1 on Clevo P750ZM
Hi Michal > There's an unofficial image that's lying in a pull request on > github[1] you could use. It probably needs skip_otp parameter to be > used. I think this is the sumdog firmwares; i tested them and i made all the test with the skip_otp parameter > This looks interesting. Can you please: > > rmmod ath10k_pci > modprobe ath10k_pci irq_mode=1 > > Msi range handling could be broken on this hw. If so we'll need to blacklist > it. Still the same issue : [ 213.889825] ath10k_pci :06:00.0: limiting irq mode to: 1 [ 213.889833] ath10k_pci :06:00.0: pci irq legacy interrupts 0 irq_mode 1 reset_mode 0 [ 216.907165] ath10k_pci :06:00.0: failed to receive initialized event from target: b8600448 [ 216.907166] ath10k_pci :06:00.0: failed to wait for target after cold reset: -110 [ 216.907167] ath10k_pci :06:00.0: failed to reset chip: -110 [ 216.907220] ath10k_pci: probe of :06:00.0 failed with error -110 > Don't just go about renaming firmware filenames like that, please. > It's used to prevent older ath10k using newer firmware images which it > wouldn't handle anyway. upon those instructions : https://github.com/kvalo/ath10k-firmware/pull/2 copying firmware-4.bin to firmware-5.bin seems to help for some users Best Regards On 07/23/2015 09:21 AM, Michal Kazior wrote: > On 23 July 2015 at 10:05, Alexandre Maloteaux wrote: >> Hi >> >> I just received a Clevo P750ZM (eurocom P5 pro) with a QCA6174 >> >> 06:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless >> Network Adapter (rev 20) >> >> Hi have tested the dissect/assemble procedure described here : >> >> https://www.mail-archive.com/ath10k@lists.infradead.org/msg02283.html >> https://askubuntu.com/questions/546813/killer-n1525-with-ubuntu-14-10 > There's an unofficial image that's lying in a pull request on > github[1] you could use. It probably needs skip_otp parameter to be > used. > > >> Im on Arch and i have tested with the Eurocom Drivers >> (http://downloads.eurocom.com/support/drivers/zip/260/260_KillerWLAN_W864.zip) >> and the sumdog blobs (https://github.com/sumdog/ath10k-firmware.git) >> directly on those 3 firmwares >> Arch official : 4.1.2-2-ARCH >> kvalo master : 4.2.0-rc3 >> kvalo qca branch : 4.1.0-rc6 >> >> I have a different issue for each kernel and i have tested with all >> board.bin available but none worked : >> >> ARCH official issue : > [snip] > > This won't work. 4.1 doesn't contain the necessary patch[2]. > > >> kvalo master : >> >> [0.00] Linux version 4.2.0-rc3-wl-ath-KVALO-ATH-MASTER+ >> (root@z1kadev) (gcc version 5.1.0 (GCC) ) #2 SMP PREEMPT Tue Jul 21 >> 15:07:02 WAT 2015 >> [ 12.381604] systemd[1]: cups.path: Cannot add dependency job, >> ignoring: Unit cups.path failed to load: No such file or directory. >> [ 12.595610] ath3k: probe of 3-7:1.0 failed with error -22 >> [ 12.595637] usbcore: registered new interface driver ath3k >> [ 12.627163] ath10k_pci :06:00.0: enabling device ( -> 0002) >> [ 12.627915] ath10k_pci :06:00.0: pci irq msi-x interrupts 8 >> irq_mode 0 reset_mode 0 >> [ 12.822155] ath10k_pci :06:00.0: Direct firmware load for >> ath10k/cal-pci-:06:00.0.bin failed with error -2 >> [ 12.822158] ath10k_pci :06:00.0: Falling back to user helper >> [ 72.915990] ath10k_pci :06:00.0: Direct firmware load for >> ath10k/QCA6174/hw2.1/board-pci-168c:003e:1a56:1525.bin failed with error -2 >> [ 72.915993] ath10k_pci :06:00.0: Falling back to user helper >> [ 133.010331] ath10k_pci :06:00.0: failed to load spec board file, >> falling back to generic: -11 >> [ 133.010647] ath10k_pci :06:00.0: Direct firmware load for >> ath10k/QCA6174/hw2.1/firmware-5.bin failed with error -2 >> [ 133.010649] ath10k_pci :06:00.0: Falling back to user helper >> [ 193.105501] ath10k_pci :06:00.0: could not fetch firmware file >> 'ath10k/QCA6174/hw2.1/firmware-5.bin': -11 >> [ 194.276201] ath10k_pci :06:00.0: received unsolicited fw crash >> interrupt >> [ 194.276209] ath10k_pci :06:00.0: received unsolicited fw crash >> interrupt >> [ 195.275581] ath10k_pci :06:00.0: failed to receive control >> response completion, polling.. >> [ 195.275699] ath10k_pci :06:00.0: received unsolicited fw crash >> interrupt > This looks interesting. Can you please: > > rmmod ath10k_pci > modprobe ath10k_pci irq_mode=1 > > Msi range handling could be broken on this hw. If so we'll need to blacklist > it. > > >> [ 196.277176] ath10k_pci :06:00.0: Service connect timeout >> [ 196.277179] ath10k_pci :06:00.0: failed to connect htt (-110) >> [ 196.347791] ath10k_pci :06:00.0: could not init core (-110) >> [ 196.347819] ath10k_pci :06:00.0: could not probe fw (-110) >> >> kvalo qca branch : >> >> [ 386.639108] ath10k_pci :06:00.0: failed to receive initialized >> event from target: b8600448 >> [ 386.639110] ath10k_pci :06:00.0: failed to wait for target after >> cold reset: -110
Re: QCA6174 hw2.1 on Clevo P750ZM
On 23 July 2015 at 10:05, Alexandre Maloteaux wrote: > Hi > > I just received a Clevo P750ZM (eurocom P5 pro) with a QCA6174 > > 06:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless > Network Adapter (rev 20) > > Hi have tested the dissect/assemble procedure described here : > > https://www.mail-archive.com/ath10k@lists.infradead.org/msg02283.html > https://askubuntu.com/questions/546813/killer-n1525-with-ubuntu-14-10 There's an unofficial image that's lying in a pull request on github[1] you could use. It probably needs skip_otp parameter to be used. > > Im on Arch and i have tested with the Eurocom Drivers > (http://downloads.eurocom.com/support/drivers/zip/260/260_KillerWLAN_W864.zip) > and the sumdog blobs (https://github.com/sumdog/ath10k-firmware.git) > directly on those 3 firmwares > Arch official : 4.1.2-2-ARCH > kvalo master : 4.2.0-rc3 > kvalo qca branch : 4.1.0-rc6 > > I have a different issue for each kernel and i have tested with all > board.bin available but none worked : > > ARCH official issue : [snip] This won't work. 4.1 doesn't contain the necessary patch[2]. > kvalo master : > > [0.00] Linux version 4.2.0-rc3-wl-ath-KVALO-ATH-MASTER+ > (root@z1kadev) (gcc version 5.1.0 (GCC) ) #2 SMP PREEMPT Tue Jul 21 > 15:07:02 WAT 2015 > [ 12.381604] systemd[1]: cups.path: Cannot add dependency job, > ignoring: Unit cups.path failed to load: No such file or directory. > [ 12.595610] ath3k: probe of 3-7:1.0 failed with error -22 > [ 12.595637] usbcore: registered new interface driver ath3k > [ 12.627163] ath10k_pci :06:00.0: enabling device ( -> 0002) > [ 12.627915] ath10k_pci :06:00.0: pci irq msi-x interrupts 8 > irq_mode 0 reset_mode 0 > [ 12.822155] ath10k_pci :06:00.0: Direct firmware load for > ath10k/cal-pci-:06:00.0.bin failed with error -2 > [ 12.822158] ath10k_pci :06:00.0: Falling back to user helper > [ 72.915990] ath10k_pci :06:00.0: Direct firmware load for > ath10k/QCA6174/hw2.1/board-pci-168c:003e:1a56:1525.bin failed with error -2 > [ 72.915993] ath10k_pci :06:00.0: Falling back to user helper > [ 133.010331] ath10k_pci :06:00.0: failed to load spec board file, > falling back to generic: -11 > [ 133.010647] ath10k_pci :06:00.0: Direct firmware load for > ath10k/QCA6174/hw2.1/firmware-5.bin failed with error -2 > [ 133.010649] ath10k_pci :06:00.0: Falling back to user helper > [ 193.105501] ath10k_pci :06:00.0: could not fetch firmware file > 'ath10k/QCA6174/hw2.1/firmware-5.bin': -11 > [ 194.276201] ath10k_pci :06:00.0: received unsolicited fw crash > interrupt > [ 194.276209] ath10k_pci :06:00.0: received unsolicited fw crash > interrupt > [ 195.275581] ath10k_pci :06:00.0: failed to receive control > response completion, polling.. > [ 195.275699] ath10k_pci :06:00.0: received unsolicited fw crash > interrupt This looks interesting. Can you please: rmmod ath10k_pci modprobe ath10k_pci irq_mode=1 Msi range handling could be broken on this hw. If so we'll need to blacklist it. > [ 196.277176] ath10k_pci :06:00.0: Service connect timeout > [ 196.277179] ath10k_pci :06:00.0: failed to connect htt (-110) > [ 196.347791] ath10k_pci :06:00.0: could not init core (-110) > [ 196.347819] ath10k_pci :06:00.0: could not probe fw (-110) > > kvalo qca branch : > > [ 386.639108] ath10k_pci :06:00.0: failed to receive initialized > event from target: b8600448 > [ 386.639110] ath10k_pci :06:00.0: failed to wait for target after > cold reset: -110 > [ 386.639110] ath10k_pci :06:00.0: failed to reset chip: -110 > [ 386.639203] ath10k_pci: probe of :06:00.0 failed with error -110 > [ 419.547152] ath10k_pci :06:00.0: pci irq msi-x interrupts 8 > irq_mode 0 reset_mode 0 > [ 422.565998] ath10k_pci :06:00.0: failed to receive initialized > event from target: b8600448 > [ 422.566000] ath10k_pci :06:00.0: failed to wait for target after > cold reset: -110 > [ 422.566001] ath10k_pci :06:00.0: failed to reset chip: -110 > [ 422.566096] ath10k_pci: probe of :06:00.0 failed with error -110 > > im getting only the cal issue on the kvalo master if i copy > firmware-4.bin to firmware-5.bin. Don't just go about renaming firmware filenames like that, please. It's used to prevent older ath10k using newer firmware images which it wouldn't handle anyway. > If i copy fw-1.bin from dissect.py to > cal-pci-:06:00.0.bin . I m getting the issue with the official arch... Uhm, that's wrong. Don't use cal-pci-xxx unless you know what you're doing. fw-1 and fw-2 from dissect are otp and main program binaries. cal-pci-xxx is just calibration data blob. This is something entirely else. If you see OTP failure you need to either set up adequate fw_feature flag in the firmware-X.bin or pass skip_otp=y parameter while probing ath10k_core module. [1]: https://github.com/kvalo/ath10k-firmware/pull/2 [2]: https://git.kernel.org/cgi
Re: qca6174 hw2.1 firmware crash with kernel 4.1.2
Hi Kalle, thank you very much. Hope to also see the firmware out soon :). Best regards On 21 July 2015 at 11:23, Kalle Valo wrote: > Enrico Tagliavini writes: > >> Mhm seems like I assumed the backport missing from 4.0 was merged for >> 4.1 but it is not, it's in 4.2 only. Any chance you'll ask for a >> backport of this 4 lines patch? >> >> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/net/wireless/ath/ath10k?id=11a002efbaa7fbd9f6e616695ab42aa9f1caf060 >> >> Would be much appreciated > > Thanks for the suggestion, I'll send the patch to 4.1 stable releases. > > -- > Kalle Valo ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: qca6174 hw2.1 firmware crash with kernel 4.1.2
Enrico Tagliavini writes: > Mhm seems like I assumed the backport missing from 4.0 was merged for > 4.1 but it is not, it's in 4.2 only. Any chance you'll ask for a > backport of this 4 lines patch? > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/net/wireless/ath/ath10k?id=11a002efbaa7fbd9f6e616695ab42aa9f1caf060 > > Would be much appreciated Thanks for the suggestion, I'll send the patch to 4.1 stable releases. -- Kalle Valo ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: qca6174 hw2.1 firmware crash with kernel 4.1.2
Confirmed, backporting the previous linked commit make the wireless work again. Official backport to the 4.1 series would be much appreciated being the latest stable and supported released kernel. The reason why I assumed it was backported already was that the commit date is quite old, like 3 months ago. Still I have quite a flood in my dmesg: [ 41.778147] ath10k_pci :03:00.0: Unknown eventid: 16389 [ 41.807350] ath10k_pci :03:00.0: Unknown eventid: 16389 [ 51.083753] ath10k_pci :03:00.0: Unknown eventid: 16389 [ 51.142931] ath10k_pci :03:00.0: Unknown eventid: 16389 [ 51.190855] ath10k_pci :03:00.0: Unknown eventid: 16389 [ 51.250871] ath10k_pci :03:00.0: Unknown eventid: 16389 [ 51.399526] ath10k_pci :03:00.0: Unknown eventid: 16389 [ 51.460780] ath10k_pci :03:00.0: Unknown eventid: 16389 [ 51.508290] ath10k_pci :03:00.0: Unknown eventid: 16389 [ 51.568318] ath10k_pci :03:00.0: Unknown eventid: 16389 [ 51.616520] ath10k_pci :03:00.0: Unknown eventid: 16389 [ 51.676759] ath10k_pci :03:00.0: Unknown eventid: 16389 [ 56.163756] ath10k_warn: 47 callbacks suppressed [ 56.163766] ath10k_pci :03:00.0: Unknown eventid: 16389 [ 56.211631] ath10k_pci :03:00.0: Unknown eventid: 16389 [ 56.367889] ath10k_pci :03:00.0: Unknown eventid: 16389 [ 56.415761] ath10k_pci :03:00.0: Unknown eventid: 16389 [ 56.572301] ath10k_pci :03:00.0: Unknown eventid: 16389 never ending. Other than this commit I saw some work in 4.2-rc logs, is the situation to be any better for this WNIC? May be bluetooth support? Fedora rawhide is already providing 4.2 RC kernel builds and since I have to recompile the kernel anyway (unless the named patch gets backport) I might temporary switch to 4.2 from rawhide if this gets me better support. Any advise? Thanks On 19 July 2015 at 11:51, Enrico Tagliavini wrote: > Mhm seems like I assumed the backport missing from 4.0 was merged for > 4.1 but it is not, it's in 4.2 only. Any chance you'll ask for a > backport of this 4 lines patch? > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/net/wireless/ath/ath10k?id=11a002efbaa7fbd9f6e616695ab42aa9f1caf060 > > Would be much appreciated > > On 19 July 2015 at 11:42, Enrico Tagliavini > wrote: >> Hi, >> >> just tried mainline 4.1.2 (from fedora-updates testing) in the hope to >> have a kernel working out of the box (4.0.x series misses a backport), >> but unfortunately it doesn't work: >> >> [ 25.311642] ath10k_pci :03:00.0: enabling device ( -> 0002) >> [ 25.312904] ath10k_pci :03:00.0: pci irq msi-x interrupts 8 >> irq_mode 0 reset_mode 0 >> [ 25.463029] ath10k_pci :03:00.0: Direct firmware load for >> ath10k/cal-pci-:03:00.0.bin failed with error -2 >> [ 26.637234] ath10k_pci :03:00.0: firmware crashed! (uuid >> 34a02c41-e7e5-459e-9d9b-5a10bf9da011) >> [ 26.637241] ath10k_pci :03:00.0: qca6174 hw2.1 (0x0501, >> 0x003405ff) fw killer-n1525-fw api 4 htt 0.0 wmi 4 cal otp max_sta 32 >> [ 26.637243] ath10k_pci :03:00.0: debug 0 debugfs 1 tracing 0 >> dfs 0 testmode 0 >> [ 26.638152] ath10k_pci :03:00.0: firmware register dump: >> [ 26.638152] ath10k_pci :03:00.0: [00]: 0x0501 0x15B3 >> 0x0095186B 0x00955B31 >> [ 26.638152] ath10k_pci :03:00.0: [04]: 0x0095186B 0x00060130 >> 0x0010 0x0040AF04 >> [ 26.638152] ath10k_pci :03:00.0: [08]: 0x0018 0x0001 >> 0x0001 0x00412250 >> [ 26.638152] ath10k_pci :03:00.0: [12]: 0x0009 0x >> 0x0096C09C 0x0096C0A7 >> [ 26.638152] ath10k_pci :03:00.0: [16]: 0x0096BDBC 0x009286B6 >> 0x 0x >> [ 26.638152] ath10k_pci :03:00.0: [20]: 0x4095186B 0x0040E160 >> 0x0041F82C 0x0001 >> [ 26.638152] ath10k_pci :03:00.0: [24]: 0x80936238 0x0040E1C0 >> 0x 0xC095186B >> [ 26.638152] ath10k_pci :03:00.0: [28]: 0x80936361 0x0040E1E0 >> 0x 0x0041C8DC >> [ 26.638152] ath10k_pci :03:00.0: [32]: 0x80934A67 0x0040E200 >> 0x00436DF0 0x0040E250 >> [ 26.638152] ath10k_pci :03:00.0: [36]: 0x809A5C92 0x0040E250 >> 0x004275B0 0x0001 >> [ 26.638152] ath10k_pci :03:00.0: [40]: 0x809A5CEA 0x0040E290 >> 0x00426F40 0x0004 >> [ 26.638152] ath10k_pci :03:00.0: [44]: 0x809A5DCA 0x0040E2B0 >> 0x00426F40 0x0041C8DC >> [ 26.638152] ath10k_pci :03:00.0: [48]: 0x800A0909 0x0040E2D0 >> 0x00426F40 0x004275A0 >> [ 26.638152] ath10k_pci :03:00.0: [52]: 0x800A024A 0x0040E2F0 >> 0x0041ABB0 0x00420440 >> [ 26.638152] ath10k_pci :03:00.0: [56]: 0x809287D9 0x0040E310 >> 0x 0x0040 >> [ 27.630142] ath10k_pci :03:00.0: failed to receive control >> response completion, polling.. >> [ 28.630050] ath10k_pci :03:00.0: ctl_resp never came in (-110) >> [ 28.630054] ath10k_pci :03:00.0: failed to connect to HTC: -110 >> [ 28.693606] ath10k_pci :03:00.0: could not init core (-110) >> [ 28
Re: qca6174 hw2.1 firmware crash with kernel 4.1.2
Mhm seems like I assumed the backport missing from 4.0 was merged for 4.1 but it is not, it's in 4.2 only. Any chance you'll ask for a backport of this 4 lines patch? https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/net/wireless/ath/ath10k?id=11a002efbaa7fbd9f6e616695ab42aa9f1caf060 Would be much appreciated On 19 July 2015 at 11:42, Enrico Tagliavini wrote: > Hi, > > just tried mainline 4.1.2 (from fedora-updates testing) in the hope to > have a kernel working out of the box (4.0.x series misses a backport), > but unfortunately it doesn't work: > > [ 25.311642] ath10k_pci :03:00.0: enabling device ( -> 0002) > [ 25.312904] ath10k_pci :03:00.0: pci irq msi-x interrupts 8 > irq_mode 0 reset_mode 0 > [ 25.463029] ath10k_pci :03:00.0: Direct firmware load for > ath10k/cal-pci-:03:00.0.bin failed with error -2 > [ 26.637234] ath10k_pci :03:00.0: firmware crashed! (uuid > 34a02c41-e7e5-459e-9d9b-5a10bf9da011) > [ 26.637241] ath10k_pci :03:00.0: qca6174 hw2.1 (0x0501, > 0x003405ff) fw killer-n1525-fw api 4 htt 0.0 wmi 4 cal otp max_sta 32 > [ 26.637243] ath10k_pci :03:00.0: debug 0 debugfs 1 tracing 0 > dfs 0 testmode 0 > [ 26.638152] ath10k_pci :03:00.0: firmware register dump: > [ 26.638152] ath10k_pci :03:00.0: [00]: 0x0501 0x15B3 > 0x0095186B 0x00955B31 > [ 26.638152] ath10k_pci :03:00.0: [04]: 0x0095186B 0x00060130 > 0x0010 0x0040AF04 > [ 26.638152] ath10k_pci :03:00.0: [08]: 0x0018 0x0001 > 0x0001 0x00412250 > [ 26.638152] ath10k_pci :03:00.0: [12]: 0x0009 0x > 0x0096C09C 0x0096C0A7 > [ 26.638152] ath10k_pci :03:00.0: [16]: 0x0096BDBC 0x009286B6 > 0x 0x > [ 26.638152] ath10k_pci :03:00.0: [20]: 0x4095186B 0x0040E160 > 0x0041F82C 0x0001 > [ 26.638152] ath10k_pci :03:00.0: [24]: 0x80936238 0x0040E1C0 > 0x 0xC095186B > [ 26.638152] ath10k_pci :03:00.0: [28]: 0x80936361 0x0040E1E0 > 0x 0x0041C8DC > [ 26.638152] ath10k_pci :03:00.0: [32]: 0x80934A67 0x0040E200 > 0x00436DF0 0x0040E250 > [ 26.638152] ath10k_pci :03:00.0: [36]: 0x809A5C92 0x0040E250 > 0x004275B0 0x0001 > [ 26.638152] ath10k_pci :03:00.0: [40]: 0x809A5CEA 0x0040E290 > 0x00426F40 0x0004 > [ 26.638152] ath10k_pci :03:00.0: [44]: 0x809A5DCA 0x0040E2B0 > 0x00426F40 0x0041C8DC > [ 26.638152] ath10k_pci :03:00.0: [48]: 0x800A0909 0x0040E2D0 > 0x00426F40 0x004275A0 > [ 26.638152] ath10k_pci :03:00.0: [52]: 0x800A024A 0x0040E2F0 > 0x0041ABB0 0x00420440 > [ 26.638152] ath10k_pci :03:00.0: [56]: 0x809287D9 0x0040E310 > 0x 0x0040 > [ 27.630142] ath10k_pci :03:00.0: failed to receive control > response completion, polling.. > [ 28.630050] ath10k_pci :03:00.0: ctl_resp never came in (-110) > [ 28.630054] ath10k_pci :03:00.0: failed to connect to HTC: -110 > [ 28.693606] ath10k_pci :03:00.0: could not init core (-110) > [ 28.693635] ath10k_pci :03:00.0: could not probe fw (-110) > [ 28.714076] ath10k_pci :03:00.0: cannot restart a device that > hasn't been started > > > anything I can do to have wireless working again? > > Thank you for the help. > > Enrico ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: QCA6174 hw2.1 firmware, take two?
Hi Gregor, yes it works, but bluetooth is broken (for me at least, does it work for you?). Also this is just a place holder solution, this needs to get into mainline linux kernel and firmware must be available linux-firmware package. I'm ok to patch my own kernel for a very short time, but in the long run I'd rather switch to another wireless adapter (for how much this can upset me). Don't get me wrong, no hard feelings, but I'll be on the road in a month or two and I need to have no potential problems since the time for fixing them will be short if any. Best regards. On 7 June 2015 at 19:08, Gregor Plata wrote: > Hi all, > > the solution described in the bug report > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1383184 (comment #150) > works perfectly for me. Wi-fi is stable without any drops and the 4.1.0-rc6- > wl-ath kernel doesn't cause any issues but the wi-fi performance comes only > to about 35%-40% of the performance on windows on the same machine downloading > the same file from the same server . > > best regards > Gregor > > Am Donnerstag, 4. Juni 2015, 19:03:55 schrieb Enrico Tagliavini: >> Hi there, >> >> Just got the following device >> >> enrico@alientux ~ $ lspci -nn | grep QCA >> 03:00.0 Network controller [0280]: Qualcomm Atheros QCA6174 802.11ac >> Wireless Network Adapter [168c:003e] (rev 20) >> >> And discovered there is no firmware available for it. I looked already >> at the April thread about it, but didn't managed to get it working. >> This is on Fedora 22, kernel 4.0.4. >> >> I used dissect.py from here >> https://gist.github.com/kazikcz/8e5845ad84ca251aa295 to generate the >> firmware image from my Windows installation: >> $ cat >> /windows/Windows/System32/DriverStore/FileRepository/netathrx.inf_amd64_481 >> f6e2b133b287d/qca61x420.bin >> | ./dissect.py >> >> but I have no clue if that is actually the correct file. For sure it's >> the only one containing "qca" end ending in ".bin" alongside >> eeprom_qca9377_1p0_NFA435_olpc.bin which I used as board.bin. >> >> Unfortunately when trying those I get >> root@alientux ~ # dmesg | grep ath >> [ 18.518677] ath10k_pci :03:00.0: enabling device ( -> 0002) >> [ 18.519124] ath10k_pci :03:00.0: pci irq msi-x interrupts 8 >> irq_mode 0 reset_mode 0 >> [ 18.667191] ath10k_pci :03:00.0: Direct firmware load for >> ath10k/cal-pci-:03:00.0.bin failed with error -2 >> [ 18.668652] ath10k_pci :03:00.0: invalid firmware magic >> [ 18.668791] ath10k_pci :03:00.0: invalid firmware magic >> [ 18.670086] ath10k_pci :03:00.0: invalid firmware magic >> [ 18.670265] ath10k_pci :03:00.0: Direct firmware load for >> ath10k/QCA6174/hw2.1/firmware.bin failed with error -2 >> [ 18.670267] ath10k_pci :03:00.0: could not fetch firmware (-2) >> [ 18.670269] ath10k_pci :03:00.0: could not fetch firmware files (-2) >> [ 18.670271] ath10k_pci :03:00.0: could not probe fw (-2) >> >> No idea where to go from here. I'm currently not sure if I want to try >> kvalo sources. Don't get me wrong but if I have to apply a patch to >> the official Linux source tree that's ok, but switching to the >> development tree is not what I was looking forward for this machine. >> Can 4.1 help instead? I'm afraid it might now since I can see the fix >> for the firmware crash is still not included. >> >> Thank you for the help. >> Best regards. >> >> Enrico >> >> ___ >> 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 ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: QCA6174 hw2.1 firmware, take two?
Hi all, the solution described in the bug report https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1383184 (comment #150) works perfectly for me. Wi-fi is stable without any drops and the 4.1.0-rc6- wl-ath kernel doesn't cause any issues but the wi-fi performance comes only to about 35%-40% of the performance on windows on the same machine downloading the same file from the same server . best regards Gregor Am Donnerstag, 4. Juni 2015, 19:03:55 schrieb Enrico Tagliavini: > Hi there, > > Just got the following device > > enrico@alientux ~ $ lspci -nn | grep QCA > 03:00.0 Network controller [0280]: Qualcomm Atheros QCA6174 802.11ac > Wireless Network Adapter [168c:003e] (rev 20) > > And discovered there is no firmware available for it. I looked already > at the April thread about it, but didn't managed to get it working. > This is on Fedora 22, kernel 4.0.4. > > I used dissect.py from here > https://gist.github.com/kazikcz/8e5845ad84ca251aa295 to generate the > firmware image from my Windows installation: > $ cat > /windows/Windows/System32/DriverStore/FileRepository/netathrx.inf_amd64_481 > f6e2b133b287d/qca61x420.bin > | ./dissect.py > > but I have no clue if that is actually the correct file. For sure it's > the only one containing "qca" end ending in ".bin" alongside > eeprom_qca9377_1p0_NFA435_olpc.bin which I used as board.bin. > > Unfortunately when trying those I get > root@alientux ~ # dmesg | grep ath > [ 18.518677] ath10k_pci :03:00.0: enabling device ( -> 0002) > [ 18.519124] ath10k_pci :03:00.0: pci irq msi-x interrupts 8 > irq_mode 0 reset_mode 0 > [ 18.667191] ath10k_pci :03:00.0: Direct firmware load for > ath10k/cal-pci-:03:00.0.bin failed with error -2 > [ 18.668652] ath10k_pci :03:00.0: invalid firmware magic > [ 18.668791] ath10k_pci :03:00.0: invalid firmware magic > [ 18.670086] ath10k_pci :03:00.0: invalid firmware magic > [ 18.670265] ath10k_pci :03:00.0: Direct firmware load for > ath10k/QCA6174/hw2.1/firmware.bin failed with error -2 > [ 18.670267] ath10k_pci :03:00.0: could not fetch firmware (-2) > [ 18.670269] ath10k_pci :03:00.0: could not fetch firmware files (-2) > [ 18.670271] ath10k_pci :03:00.0: could not probe fw (-2) > > No idea where to go from here. I'm currently not sure if I want to try > kvalo sources. Don't get me wrong but if I have to apply a patch to > the official Linux source tree that's ok, but switching to the > development tree is not what I was looking forward for this machine. > Can 4.1 help instead? I'm afraid it might now since I can see the fix > for the firmware crash is still not included. > > Thank you for the help. > Best regards. > > Enrico > > ___ > 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 hw2.1 firmware, take two?
Moreover the integrated bluetooth adapter is 100% non working for me. It's not the end of the world but that's a bummer. On 5 June 2015 at 11:13, Dario Pellegrini wrote: > Just to let you know that I am also willing to see this firmware pushed in > the mainstream. > > And there are much more people out there without the technical competences > to follow the ath10 development that are just willing to have this "problem" > solved in their favorite distribution! > > 2015-06-04 23:12 GMT+02:00 Jason H : >> >> Glad to see I'm not the only one with this card! >> >> What are the blockages to getting this properly supported? I figure he >> kernel patch has to work it's way though the maintainers, but are there any >> restrictions with publishing the firmware for the linux driver? >> >> >> > Sent: Thursday, June 04, 2015 at 1:22 PM >> > From: "Enrico Tagliavini" >> > To: ath10k@lists.infradead.org >> > Subject: Re: QCA6174 hw2.1 firmware, take two? >> > >> > Hi again, >> > >> > ok this was dumb I forgot to assemble back the firmware and I >> > realized it just after sending out the previous email (that's why the >> > driver was complaining about the invalid magic). >> > >> > Sorry for the noise, I apologize. >> > >> > Hope to see this fixed in upstream Linux kernel soon. >> > >> > Best regards. >> > >> > Enrico. >> > >> > >> > P.S.: this is another Alienware 15 like Gabriele's. I think they all >> > ship with such a WiFi. Just pointing it out since Dell now is even >> > shyly suggesting to try out Linux >> > https://twitter.com/DellCaresPRO/status/603780236531081216 (not on >> > Alienware, but still...) >> > >> > On 4 June 2015 at 19:03, Enrico Tagliavini >> > wrote: >> > > Hi there, >> > > >> > > Just got the following device >> > > >> > > enrico@alientux ~ $ lspci -nn | grep QCA >> > > 03:00.0 Network controller [0280]: Qualcomm Atheros QCA6174 802.11ac >> > > Wireless Network Adapter [168c:003e] (rev 20) >> > > >> > > And discovered there is no firmware available for it. I looked already >> > > at the April thread about it, but didn't managed to get it working. >> > > This is on Fedora 22, kernel 4.0.4. >> > > >> > > I used dissect.py from here >> > > https://gist.github.com/kazikcz/8e5845ad84ca251aa295 to generate the >> > > firmware image from my Windows installation: >> > > $ cat >> > > /windows/Windows/System32/DriverStore/FileRepository/netathrx.inf_amd64_481f6e2b133b287d/qca61x420.bin >> > > | ./dissect.py >> > > >> > > but I have no clue if that is actually the correct file. For sure it's >> > > the only one containing "qca" end ending in ".bin" alongside >> > > eeprom_qca9377_1p0_NFA435_olpc.bin which I used as board.bin. >> > > >> > > Unfortunately when trying those I get >> > > root@alientux ~ # dmesg | grep ath >> > > [ 18.518677] ath10k_pci :03:00.0: enabling device ( -> 0002) >> > > [ 18.519124] ath10k_pci :03:00.0: pci irq msi-x interrupts 8 >> > > irq_mode 0 reset_mode 0 >> > > [ 18.667191] ath10k_pci :03:00.0: Direct firmware load for >> > > ath10k/cal-pci-:03:00.0.bin failed with error -2 >> > > [ 18.668652] ath10k_pci :03:00.0: invalid firmware magic >> > > [ 18.668791] ath10k_pci :03:00.0: invalid firmware magic >> > > [ 18.670086] ath10k_pci :03:00.0: invalid firmware magic >> > > [ 18.670265] ath10k_pci :03:00.0: Direct firmware load for >> > > ath10k/QCA6174/hw2.1/firmware.bin failed with error -2 >> > > [ 18.670267] ath10k_pci :03:00.0: could not fetch firmware (-2) >> > > [ 18.670269] ath10k_pci :03:00.0: could not fetch firmware files >> > > (-2) >> > > [ 18.670271] ath10k_pci :03:00.0: could not probe fw (-2) >> > > >> > > No idea where to go from here. I'm currently not sure if I want to try >> > > kvalo sources. Don't get me wrong but if I have to apply a patch to >> > > the official Linux source tree that's ok, but switching to the >> > > development tree is not what I was looking forward for this machine. >> > > Can 4.1 help instead? I'm afraid it might now since I can see the fix >> > > for the firmware crash is still not included. >> > > >> > > Thank you for the help. >> > > Best regards. >> > > >> > > Enrico >> > >> > ___ >> > 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 > > ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: QCA6174 hw2.1 firmware, take two?
Glad to see I'm not the only one with this card! What are the blockages to getting this properly supported? I figure he kernel patch has to work it's way though the maintainers, but are there any restrictions with publishing the firmware for the linux driver? > Sent: Thursday, June 04, 2015 at 1:22 PM > From: "Enrico Tagliavini" > To: ath10k@lists.infradead.org > Subject: Re: QCA6174 hw2.1 firmware, take two? > > Hi again, > > ok this was dumb I forgot to assemble back the firmware and I > realized it just after sending out the previous email (that's why the > driver was complaining about the invalid magic). > > Sorry for the noise, I apologize. > > Hope to see this fixed in upstream Linux kernel soon. > > Best regards. > > Enrico. > > > P.S.: this is another Alienware 15 like Gabriele's. I think they all > ship with such a WiFi. Just pointing it out since Dell now is even > shyly suggesting to try out Linux > https://twitter.com/DellCaresPRO/status/603780236531081216 (not on > Alienware, but still...) > > On 4 June 2015 at 19:03, Enrico Tagliavini > wrote: > > Hi there, > > > > Just got the following device > > > > enrico@alientux ~ $ lspci -nn | grep QCA > > 03:00.0 Network controller [0280]: Qualcomm Atheros QCA6174 802.11ac > > Wireless Network Adapter [168c:003e] (rev 20) > > > > And discovered there is no firmware available for it. I looked already > > at the April thread about it, but didn't managed to get it working. > > This is on Fedora 22, kernel 4.0.4. > > > > I used dissect.py from here > > https://gist.github.com/kazikcz/8e5845ad84ca251aa295 to generate the > > firmware image from my Windows installation: > > $ cat > > /windows/Windows/System32/DriverStore/FileRepository/netathrx.inf_amd64_481f6e2b133b287d/qca61x420.bin > > | ./dissect.py > > > > but I have no clue if that is actually the correct file. For sure it's > > the only one containing "qca" end ending in ".bin" alongside > > eeprom_qca9377_1p0_NFA435_olpc.bin which I used as board.bin. > > > > Unfortunately when trying those I get > > root@alientux ~ # dmesg | grep ath > > [ 18.518677] ath10k_pci :03:00.0: enabling device ( -> 0002) > > [ 18.519124] ath10k_pci :03:00.0: pci irq msi-x interrupts 8 > > irq_mode 0 reset_mode 0 > > [ 18.667191] ath10k_pci :03:00.0: Direct firmware load for > > ath10k/cal-pci-:03:00.0.bin failed with error -2 > > [ 18.668652] ath10k_pci :03:00.0: invalid firmware magic > > [ 18.668791] ath10k_pci :03:00.0: invalid firmware magic > > [ 18.670086] ath10k_pci :03:00.0: invalid firmware magic > > [ 18.670265] ath10k_pci :03:00.0: Direct firmware load for > > ath10k/QCA6174/hw2.1/firmware.bin failed with error -2 > > [ 18.670267] ath10k_pci :03:00.0: could not fetch firmware (-2) > > [ 18.670269] ath10k_pci :03:00.0: could not fetch firmware files (-2) > > [ 18.670271] ath10k_pci :03:00.0: could not probe fw (-2) > > > > No idea where to go from here. I'm currently not sure if I want to try > > kvalo sources. Don't get me wrong but if I have to apply a patch to > > the official Linux source tree that's ok, but switching to the > > development tree is not what I was looking forward for this machine. > > Can 4.1 help instead? I'm afraid it might now since I can see the fix > > for the firmware crash is still not included. > > > > Thank you for the help. > > Best regards. > > > > Enrico > > ___ > 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 hw2.1 firmware, take two?
Hi again, ok this was dumb I forgot to assemble back the firmware and I realized it just after sending out the previous email (that's why the driver was complaining about the invalid magic). Sorry for the noise, I apologize. Hope to see this fixed in upstream Linux kernel soon. Best regards. Enrico. P.S.: this is another Alienware 15 like Gabriele's. I think they all ship with such a WiFi. Just pointing it out since Dell now is even shyly suggesting to try out Linux https://twitter.com/DellCaresPRO/status/603780236531081216 (not on Alienware, but still...) On 4 June 2015 at 19:03, Enrico Tagliavini wrote: > Hi there, > > Just got the following device > > enrico@alientux ~ $ lspci -nn | grep QCA > 03:00.0 Network controller [0280]: Qualcomm Atheros QCA6174 802.11ac > Wireless Network Adapter [168c:003e] (rev 20) > > And discovered there is no firmware available for it. I looked already > at the April thread about it, but didn't managed to get it working. > This is on Fedora 22, kernel 4.0.4. > > I used dissect.py from here > https://gist.github.com/kazikcz/8e5845ad84ca251aa295 to generate the > firmware image from my Windows installation: > $ cat > /windows/Windows/System32/DriverStore/FileRepository/netathrx.inf_amd64_481f6e2b133b287d/qca61x420.bin > | ./dissect.py > > but I have no clue if that is actually the correct file. For sure it's > the only one containing "qca" end ending in ".bin" alongside > eeprom_qca9377_1p0_NFA435_olpc.bin which I used as board.bin. > > Unfortunately when trying those I get > root@alientux ~ # dmesg | grep ath > [ 18.518677] ath10k_pci :03:00.0: enabling device ( -> 0002) > [ 18.519124] ath10k_pci :03:00.0: pci irq msi-x interrupts 8 > irq_mode 0 reset_mode 0 > [ 18.667191] ath10k_pci :03:00.0: Direct firmware load for > ath10k/cal-pci-:03:00.0.bin failed with error -2 > [ 18.668652] ath10k_pci :03:00.0: invalid firmware magic > [ 18.668791] ath10k_pci :03:00.0: invalid firmware magic > [ 18.670086] ath10k_pci :03:00.0: invalid firmware magic > [ 18.670265] ath10k_pci :03:00.0: Direct firmware load for > ath10k/QCA6174/hw2.1/firmware.bin failed with error -2 > [ 18.670267] ath10k_pci :03:00.0: could not fetch firmware (-2) > [ 18.670269] ath10k_pci :03:00.0: could not fetch firmware files (-2) > [ 18.670271] ath10k_pci :03:00.0: could not probe fw (-2) > > No idea where to go from here. I'm currently not sure if I want to try > kvalo sources. Don't get me wrong but if I have to apply a patch to > the official Linux source tree that's ok, but switching to the > development tree is not what I was looking forward for this machine. > Can 4.1 help instead? I'm afraid it might now since I can see the fix > for the firmware crash is still not included. > > Thank you for the help. > Best regards. > > Enrico ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: QCA6174 hw2.1 firmware, take two?
hi, It's beeliner - they went and .. "changed" how they're doing firmware releases and the firmware API. It's hopefully going to be more structured and backwards-compatible. this time. I don't know if/when there are plans for beeliner ath10k support. I'm still trying to get the QCA988x firmware building for me so I can jump back into development there. Does anyone know more about plans for supporting beeliner and the updated firmware APIs? -adrian On 4 June 2015 at 10:03, Enrico Tagliavini wrote: > Hi there, > > Just got the following device > > enrico@alientux ~ $ lspci -nn | grep QCA > 03:00.0 Network controller [0280]: Qualcomm Atheros QCA6174 802.11ac > Wireless Network Adapter [168c:003e] (rev 20) > > And discovered there is no firmware available for it. I looked already > at the April thread about it, but didn't managed to get it working. > This is on Fedora 22, kernel 4.0.4. > > I used dissect.py from here > https://gist.github.com/kazikcz/8e5845ad84ca251aa295 to generate the > firmware image from my Windows installation: > $ cat > /windows/Windows/System32/DriverStore/FileRepository/netathrx.inf_amd64_481f6e2b133b287d/qca61x420.bin > | ./dissect.py > > but I have no clue if that is actually the correct file. For sure it's > the only one containing "qca" end ending in ".bin" alongside > eeprom_qca9377_1p0_NFA435_olpc.bin which I used as board.bin. > > Unfortunately when trying those I get > root@alientux ~ # dmesg | grep ath > [ 18.518677] ath10k_pci :03:00.0: enabling device ( -> 0002) > [ 18.519124] ath10k_pci :03:00.0: pci irq msi-x interrupts 8 > irq_mode 0 reset_mode 0 > [ 18.667191] ath10k_pci :03:00.0: Direct firmware load for > ath10k/cal-pci-:03:00.0.bin failed with error -2 > [ 18.668652] ath10k_pci :03:00.0: invalid firmware magic > [ 18.668791] ath10k_pci :03:00.0: invalid firmware magic > [ 18.670086] ath10k_pci :03:00.0: invalid firmware magic > [ 18.670265] ath10k_pci :03:00.0: Direct firmware load for > ath10k/QCA6174/hw2.1/firmware.bin failed with error -2 > [ 18.670267] ath10k_pci :03:00.0: could not fetch firmware (-2) > [ 18.670269] ath10k_pci :03:00.0: could not fetch firmware files (-2) > [ 18.670271] ath10k_pci :03:00.0: could not probe fw (-2) > > No idea where to go from here. I'm currently not sure if I want to try > kvalo sources. Don't get me wrong but if I have to apply a patch to > the official Linux source tree that's ok, but switching to the > development tree is not what I was looking forward for this machine. > Can 4.1 help instead? I'm afraid it might now since I can see the fix > for the firmware crash is still not included. > > Thank you for the help. > Best regards. > > Enrico > > ___ > 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 hw2.1?
I'm using the kvalo's kernel (4.1-rc3) without the patch, sometimes the adapter loses connection but it's bearable. I'll try that patch later. Killer N1525 on Alienware 15. OT: Anton, does the headphone jack work correctly on your Alienware 15? I sent a patch to the ALSA team about that. On 21/05/2015 07:29, Anton Romanov wrote: > Works fine for me with this patch > https://patchwork.kernel.org/patch/6387631/ at least > I am currently using self-extracted firmware but the one in the pr for > ath10k-firmware worked fine as well iirc. > I'm using that on Alienware 15 laptop with "Killer N1525" > > On Wed, May 20, 2015 at 8:17 AM, Jason H wrote: >> I just wanted to check in and see what the status of support was for this >> hardware. I saw a few messages since I last posted. >> I also need Linux 4 kernel for other issues with the hardware. >> >> Thanks! ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: QCA6174 hw2.1?
Works fine for me with this patch https://patchwork.kernel.org/patch/6387631/ at least I am currently using self-extracted firmware but the one in the pr for ath10k-firmware worked fine as well iirc. I'm using that on Alienware 15 laptop with "Killer N1525" On Wed, May 20, 2015 at 8:17 AM, Jason H wrote: > I just wanted to check in and see what the status of support was for this > hardware. I saw a few messages since I last posted. > I also need Linux 4 kernel for other issues with the hardware. > > Thanks! > > >> Sent: Thursday, April 30, 2015 at 9:03 AM >> From: "Moritz Morawietz" >> To: ath10k@lists.infradead.org >> Subject: Re: QCA6174 hw2.1? >> >> I used 4.0.0-2. Also i had one kernel build where it worked, but, >> because I didn't knew that you have to install nvidia drivers again, I >> deletet it. I am not sure how i did it, so I'm currently trying again. >> Maybe I need to understand the patching mechanisms, guess that would >> help :D I did something with git… >> >> Thank you a lot for your help so far! >> >> 2015-04-30 2:07 GMT+02:00 Gabriele Martino : >> > On 28/04/2015 13:55, Moritz Morawietz wrote: >> >> Many thanks for your fast help! >> >> >> >> I've made some progress, but ran into other problems. >> >> If i compile ath10_pci, ath10k_core and ath from kvalo's tree and load >> >> them, i get following dmesg output: >> >> >> >> [2.980448] ath10k_pci :06:00.0: enabling device ( -> 0002) >> >> [2.980750] ath10k_pci :06:00.0: pci irq msi-x interrupts 8 >> >> irq_mode 0 reset_mode 0 >> >> [3.158860] ath10k_pci :06:00.0: Direct firmware load for >> >> ath10k/cal-pci-:06:00.0.bin failed with error -2 >> >> [3.159611] ath10k_pci :06:00.0: Direct firmware load for >> >> ath10k/QCA6174/hw2.1/board-pci-168c:003e:1a56:1525.bin failed with >> >> error -2 >> >> [3.159613] ath10k_pci :06:00.0: failed to load spec board >> >> file, falling back to generic: -2 >> >> [3.159922] ath10k_pci :06:00.0: Direct firmware load for >> >> ath10k/QCA6174/hw2.1/firmware-5.bin failed with error -2 >> >> [3.159924] ath10k_pci :06:00.0: could not fetch firmware file >> >> 'ath10k/QCA6174/hw2.1/firmware-5.bin': -2 >> >> [4.360946] ath10k_pci :06:00.0: qca6174 hw2.1 (0x0501, >> >> 0x003405ff, 168c:003e:1a56:1525 fallback) fw killer-n1525-fw api 4 htt >> >> 3.1 wmi 4 cal otp max_sta 32 >> >> [4.360950] ath10k_pci :06:00.0: debug 1 debugfs 1 tracing 1 >> >> dfs 0 testmode 0 >> >> [4.430068] ath: EEPROM regdomain: 0x6c >> >> [4.430070] ath: EEPROM indicates we should expect a direct regpair map >> >> [4.430072] ath: Country alpha2 being used: 00 >> >> [4.430072] ath: Regpair used: 0x6c >> >> [4.430078] ath10k_pci :06:00.0: failed to register ieee80211: -22 >> >> [4.430097] ath10k_pci :06:00.0: could not register to mac80211 >> >> (-22) >> >> >> >> So I compiled mac80211, and tried to load it. What i get is a load of >> >> that messages: >> >> >> >> [ 226.812494] mac80211: Unknown symbol cfg80211_cqm_rssi_notify (err -22) >> >> [ 226.812497] mac80211: disagrees about version of symbol >> >> cfg80211_auth_timeout >> >> [ 226.812497] mac80211: Unknown symbol cfg80211_auth_timeout (err -22) >> >> [ 226.812498] mac80211: disagrees about version of symbol >> >> cfg80211_rx_unprot_mlme_mgmt >> >> [ 226.812499] mac80211: Unknown symbol cfg80211_rx_unprot_mlme_mgmt (err >> >> -22) >> >> >> >> Because mac80211 depends on cfg80211, i compilied and tested it. The >> >> error messages reduced to >> >> >> >> [ 632.208849] mac80211: Unknown symbol rhashtable_insert_rehash (err 0) >> >> [ 632.208881] mac80211: Unknown symbol rhashtable_insert_slow (err 0) >> >> >> >> Know I'm stuck. I'll try to compile and use the whole kernel (it's >> >> compiling right now), but would prefer to just change the modules. >> > I could find some references to "rhashtable_insert_rehash" with grep: >> > /usr/src/linux/lib/rhashtable.c:int rhashtable_insert_rehash(struct >> > rhashtable *ht) >> > /usr/src/linux/lib/rhashtable.c:EXPORT_SYMBOL_GPL(rhashtable_insert_rehash); &
Re: QCA6174 hw2.1?
I just wanted to check in and see what the status of support was for this hardware. I saw a few messages since I last posted. I also need Linux 4 kernel for other issues with the hardware. Thanks! > Sent: Thursday, April 30, 2015 at 9:03 AM > From: "Moritz Morawietz" > To: ath10k@lists.infradead.org > Subject: Re: QCA6174 hw2.1? > > I used 4.0.0-2. Also i had one kernel build where it worked, but, > because I didn't knew that you have to install nvidia drivers again, I > deletet it. I am not sure how i did it, so I'm currently trying again. > Maybe I need to understand the patching mechanisms, guess that would > help :D I did something with git… > > Thank you a lot for your help so far! > > 2015-04-30 2:07 GMT+02:00 Gabriele Martino : > > On 28/04/2015 13:55, Moritz Morawietz wrote: > >> Many thanks for your fast help! > >> > >> I've made some progress, but ran into other problems. > >> If i compile ath10_pci, ath10k_core and ath from kvalo's tree and load > >> them, i get following dmesg output: > >> > >> [2.980448] ath10k_pci :06:00.0: enabling device ( -> 0002) > >> [2.980750] ath10k_pci :06:00.0: pci irq msi-x interrupts 8 > >> irq_mode 0 reset_mode 0 > >> [3.158860] ath10k_pci :06:00.0: Direct firmware load for > >> ath10k/cal-pci-:06:00.0.bin failed with error -2 > >> [3.159611] ath10k_pci :06:00.0: Direct firmware load for > >> ath10k/QCA6174/hw2.1/board-pci-168c:003e:1a56:1525.bin failed with > >> error -2 > >> [3.159613] ath10k_pci :06:00.0: failed to load spec board > >> file, falling back to generic: -2 > >> [3.159922] ath10k_pci :06:00.0: Direct firmware load for > >> ath10k/QCA6174/hw2.1/firmware-5.bin failed with error -2 > >> [3.159924] ath10k_pci :06:00.0: could not fetch firmware file > >> 'ath10k/QCA6174/hw2.1/firmware-5.bin': -2 > >> [4.360946] ath10k_pci :06:00.0: qca6174 hw2.1 (0x0501, > >> 0x003405ff, 168c:003e:1a56:1525 fallback) fw killer-n1525-fw api 4 htt > >> 3.1 wmi 4 cal otp max_sta 32 > >> [4.360950] ath10k_pci :06:00.0: debug 1 debugfs 1 tracing 1 > >> dfs 0 testmode 0 > >> [4.430068] ath: EEPROM regdomain: 0x6c > >> [4.430070] ath: EEPROM indicates we should expect a direct regpair map > >> [4.430072] ath: Country alpha2 being used: 00 > >> [4.430072] ath: Regpair used: 0x6c > >> [4.430078] ath10k_pci :06:00.0: failed to register ieee80211: -22 > >> [4.430097] ath10k_pci :06:00.0: could not register to mac80211 > >> (-22) > >> > >> So I compiled mac80211, and tried to load it. What i get is a load of > >> that messages: > >> > >> [ 226.812494] mac80211: Unknown symbol cfg80211_cqm_rssi_notify (err -22) > >> [ 226.812497] mac80211: disagrees about version of symbol > >> cfg80211_auth_timeout > >> [ 226.812497] mac80211: Unknown symbol cfg80211_auth_timeout (err -22) > >> [ 226.812498] mac80211: disagrees about version of symbol > >> cfg80211_rx_unprot_mlme_mgmt > >> [ 226.812499] mac80211: Unknown symbol cfg80211_rx_unprot_mlme_mgmt (err > >> -22) > >> > >> Because mac80211 depends on cfg80211, i compilied and tested it. The > >> error messages reduced to > >> > >> [ 632.208849] mac80211: Unknown symbol rhashtable_insert_rehash (err 0) > >> [ 632.208881] mac80211: Unknown symbol rhashtable_insert_slow (err 0) > >> > >> Know I'm stuck. I'll try to compile and use the whole kernel (it's > >> compiling right now), but would prefer to just change the modules. > > I could find some references to "rhashtable_insert_rehash" with grep: > > /usr/src/linux/lib/rhashtable.c:int rhashtable_insert_rehash(struct > > rhashtable *ht) > > /usr/src/linux/lib/rhashtable.c:EXPORT_SYMBOL_GPL(rhashtable_insert_rehash); > > > > This file is present in 3.18.11 kernel (I don't have older sources on > > this laptop). > > Which distribution and kernel are you using? > > You are compiling 4.0 (-> 3.20) modules, so you're likely to get strange > > issues if your kernel is too old. > > > > Regards, > > Gabriele > > > > > > ___ > > 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 > ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: QCA6174 hw2.1?
I used 4.0.0-2. Also i had one kernel build where it worked, but, because I didn't knew that you have to install nvidia drivers again, I deletet it. I am not sure how i did it, so I'm currently trying again. Maybe I need to understand the patching mechanisms, guess that would help :D I did something with git… Thank you a lot for your help so far! 2015-04-30 2:07 GMT+02:00 Gabriele Martino : > On 28/04/2015 13:55, Moritz Morawietz wrote: >> Many thanks for your fast help! >> >> I've made some progress, but ran into other problems. >> If i compile ath10_pci, ath10k_core and ath from kvalo's tree and load >> them, i get following dmesg output: >> >> [2.980448] ath10k_pci :06:00.0: enabling device ( -> 0002) >> [2.980750] ath10k_pci :06:00.0: pci irq msi-x interrupts 8 >> irq_mode 0 reset_mode 0 >> [3.158860] ath10k_pci :06:00.0: Direct firmware load for >> ath10k/cal-pci-:06:00.0.bin failed with error -2 >> [3.159611] ath10k_pci :06:00.0: Direct firmware load for >> ath10k/QCA6174/hw2.1/board-pci-168c:003e:1a56:1525.bin failed with >> error -2 >> [3.159613] ath10k_pci :06:00.0: failed to load spec board >> file, falling back to generic: -2 >> [3.159922] ath10k_pci :06:00.0: Direct firmware load for >> ath10k/QCA6174/hw2.1/firmware-5.bin failed with error -2 >> [3.159924] ath10k_pci :06:00.0: could not fetch firmware file >> 'ath10k/QCA6174/hw2.1/firmware-5.bin': -2 >> [4.360946] ath10k_pci :06:00.0: qca6174 hw2.1 (0x0501, >> 0x003405ff, 168c:003e:1a56:1525 fallback) fw killer-n1525-fw api 4 htt >> 3.1 wmi 4 cal otp max_sta 32 >> [4.360950] ath10k_pci :06:00.0: debug 1 debugfs 1 tracing 1 >> dfs 0 testmode 0 >> [4.430068] ath: EEPROM regdomain: 0x6c >> [4.430070] ath: EEPROM indicates we should expect a direct regpair map >> [4.430072] ath: Country alpha2 being used: 00 >> [4.430072] ath: Regpair used: 0x6c >> [4.430078] ath10k_pci :06:00.0: failed to register ieee80211: -22 >> [4.430097] ath10k_pci :06:00.0: could not register to mac80211 (-22) >> >> So I compiled mac80211, and tried to load it. What i get is a load of >> that messages: >> >> [ 226.812494] mac80211: Unknown symbol cfg80211_cqm_rssi_notify (err -22) >> [ 226.812497] mac80211: disagrees about version of symbol >> cfg80211_auth_timeout >> [ 226.812497] mac80211: Unknown symbol cfg80211_auth_timeout (err -22) >> [ 226.812498] mac80211: disagrees about version of symbol >> cfg80211_rx_unprot_mlme_mgmt >> [ 226.812499] mac80211: Unknown symbol cfg80211_rx_unprot_mlme_mgmt (err >> -22) >> >> Because mac80211 depends on cfg80211, i compilied and tested it. The >> error messages reduced to >> >> [ 632.208849] mac80211: Unknown symbol rhashtable_insert_rehash (err 0) >> [ 632.208881] mac80211: Unknown symbol rhashtable_insert_slow (err 0) >> >> Know I'm stuck. I'll try to compile and use the whole kernel (it's >> compiling right now), but would prefer to just change the modules. > I could find some references to "rhashtable_insert_rehash" with grep: > /usr/src/linux/lib/rhashtable.c:int rhashtable_insert_rehash(struct > rhashtable *ht) > /usr/src/linux/lib/rhashtable.c:EXPORT_SYMBOL_GPL(rhashtable_insert_rehash); > > This file is present in 3.18.11 kernel (I don't have older sources on > this laptop). > Which distribution and kernel are you using? > You are compiling 4.0 (-> 3.20) modules, so you're likely to get strange > issues if your kernel is too old. > > Regards, > Gabriele > > > ___ > 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 hw2.1?
On 28/04/2015 13:55, Moritz Morawietz wrote: > Many thanks for your fast help! > > I've made some progress, but ran into other problems. > If i compile ath10_pci, ath10k_core and ath from kvalo's tree and load > them, i get following dmesg output: > > [2.980448] ath10k_pci :06:00.0: enabling device ( -> 0002) > [2.980750] ath10k_pci :06:00.0: pci irq msi-x interrupts 8 > irq_mode 0 reset_mode 0 > [3.158860] ath10k_pci :06:00.0: Direct firmware load for > ath10k/cal-pci-:06:00.0.bin failed with error -2 > [3.159611] ath10k_pci :06:00.0: Direct firmware load for > ath10k/QCA6174/hw2.1/board-pci-168c:003e:1a56:1525.bin failed with > error -2 > [3.159613] ath10k_pci :06:00.0: failed to load spec board > file, falling back to generic: -2 > [3.159922] ath10k_pci :06:00.0: Direct firmware load for > ath10k/QCA6174/hw2.1/firmware-5.bin failed with error -2 > [3.159924] ath10k_pci :06:00.0: could not fetch firmware file > 'ath10k/QCA6174/hw2.1/firmware-5.bin': -2 > [4.360946] ath10k_pci :06:00.0: qca6174 hw2.1 (0x0501, > 0x003405ff, 168c:003e:1a56:1525 fallback) fw killer-n1525-fw api 4 htt > 3.1 wmi 4 cal otp max_sta 32 > [4.360950] ath10k_pci :06:00.0: debug 1 debugfs 1 tracing 1 > dfs 0 testmode 0 > [4.430068] ath: EEPROM regdomain: 0x6c > [4.430070] ath: EEPROM indicates we should expect a direct regpair map > [4.430072] ath: Country alpha2 being used: 00 > [4.430072] ath: Regpair used: 0x6c > [4.430078] ath10k_pci :06:00.0: failed to register ieee80211: -22 > [4.430097] ath10k_pci :06:00.0: could not register to mac80211 (-22) > > So I compiled mac80211, and tried to load it. What i get is a load of > that messages: > > [ 226.812494] mac80211: Unknown symbol cfg80211_cqm_rssi_notify (err -22) > [ 226.812497] mac80211: disagrees about version of symbol > cfg80211_auth_timeout > [ 226.812497] mac80211: Unknown symbol cfg80211_auth_timeout (err -22) > [ 226.812498] mac80211: disagrees about version of symbol > cfg80211_rx_unprot_mlme_mgmt > [ 226.812499] mac80211: Unknown symbol cfg80211_rx_unprot_mlme_mgmt (err -22) > > Because mac80211 depends on cfg80211, i compilied and tested it. The > error messages reduced to > > [ 632.208849] mac80211: Unknown symbol rhashtable_insert_rehash (err 0) > [ 632.208881] mac80211: Unknown symbol rhashtable_insert_slow (err 0) > > Know I'm stuck. I'll try to compile and use the whole kernel (it's > compiling right now), but would prefer to just change the modules. I could find some references to "rhashtable_insert_rehash" with grep: /usr/src/linux/lib/rhashtable.c:int rhashtable_insert_rehash(struct rhashtable *ht) /usr/src/linux/lib/rhashtable.c:EXPORT_SYMBOL_GPL(rhashtable_insert_rehash); This file is present in 3.18.11 kernel (I don't have older sources on this laptop). Which distribution and kernel are you using? You are compiling 4.0 (-> 3.20) modules, so you're likely to get strange issues if your kernel is too old. Regards, Gabriele ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: QCA6174 hw2.1?
Many thanks for your fast help! I've made some progress, but ran into other problems. If i compile ath10_pci, ath10k_core and ath from kvalo's tree and load them, i get following dmesg output: [2.980448] ath10k_pci :06:00.0: enabling device ( -> 0002) [2.980750] ath10k_pci :06:00.0: pci irq msi-x interrupts 8 irq_mode 0 reset_mode 0 [3.158860] ath10k_pci :06:00.0: Direct firmware load for ath10k/cal-pci-:06:00.0.bin failed with error -2 [3.159611] ath10k_pci :06:00.0: Direct firmware load for ath10k/QCA6174/hw2.1/board-pci-168c:003e:1a56:1525.bin failed with error -2 [3.159613] ath10k_pci :06:00.0: failed to load spec board file, falling back to generic: -2 [3.159922] ath10k_pci :06:00.0: Direct firmware load for ath10k/QCA6174/hw2.1/firmware-5.bin failed with error -2 [3.159924] ath10k_pci :06:00.0: could not fetch firmware file 'ath10k/QCA6174/hw2.1/firmware-5.bin': -2 [4.360946] ath10k_pci :06:00.0: qca6174 hw2.1 (0x0501, 0x003405ff, 168c:003e:1a56:1525 fallback) fw killer-n1525-fw api 4 htt 3.1 wmi 4 cal otp max_sta 32 [4.360950] ath10k_pci :06:00.0: debug 1 debugfs 1 tracing 1 dfs 0 testmode 0 [4.430068] ath: EEPROM regdomain: 0x6c [4.430070] ath: EEPROM indicates we should expect a direct regpair map [4.430072] ath: Country alpha2 being used: 00 [4.430072] ath: Regpair used: 0x6c [4.430078] ath10k_pci :06:00.0: failed to register ieee80211: -22 [4.430097] ath10k_pci :06:00.0: could not register to mac80211 (-22) So I compiled mac80211, and tried to load it. What i get is a load of that messages: [ 226.812494] mac80211: Unknown symbol cfg80211_cqm_rssi_notify (err -22) [ 226.812497] mac80211: disagrees about version of symbol cfg80211_auth_timeout [ 226.812497] mac80211: Unknown symbol cfg80211_auth_timeout (err -22) [ 226.812498] mac80211: disagrees about version of symbol cfg80211_rx_unprot_mlme_mgmt [ 226.812499] mac80211: Unknown symbol cfg80211_rx_unprot_mlme_mgmt (err -22) Because mac80211 depends on cfg80211, i compilied and tested it. The error messages reduced to [ 632.208849] mac80211: Unknown symbol rhashtable_insert_rehash (err 0) [ 632.208881] mac80211: Unknown symbol rhashtable_insert_slow (err 0) Know I'm stuck. I'll try to compile and use the whole kernel (it's compiling right now), but would prefer to just change the modules. The firmware-4.bin is assembled like described in this thread, as board.bin i used eeprom_qca9377_1p0_NFA435_olpc.bin. Any Ideas? :) Happy greetings Moritz 2015-04-27 23:56 GMT+02:00 Corin Lawson : > Gabriele is right it is only the modules that need to be built kvalo's > kernel > > On 28 Apr 2015 1:05 am, "Gabriele Martino" wrote: >> >> On 27/04/2015 16:00, Moritz Morawietz wrote: >> > Hi! >> > >> > I have the same problems with my card (also a Killer N1525). It seems >> > you've done it, but i can't figure out how. >> > >> > Do i need to build and use kvalo's kernel, or is it enough to build >> > the modules ath10k_core & ath10k_pci? >> > I'm a bit afraid of compiling the whole kernel ^^ >> > output of uname -a: >> > Linux companion 4.0.0-2-ARCH #1 SMP PREEMPT Tue Apr 14 07:14:46 CEST >> > 2015 x86_64 GNU/Linux >> The modules should be enough. Tell us if it works. >> Compiling a whole kernel isn't too hard if you already have a working >> configuration. >> >> > I have the disassembly.py, but cannot find the dissect.py, can you >> > provide the link? Or, even better, the assembled files? >> I won't upload the assembled files now, I don't know if I can get >> licensing issues. >> You can find the dissect.py script here: >> http://lists.infradead.org/pipermail/ath10k/2015-April/005074.html >> >> Good luck! >> >> Regards, >> Gabriele >> >> >> ___ >> 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 hw2.1?
On 27/04/2015 16:00, Moritz Morawietz wrote: > Hi! > > I have the same problems with my card (also a Killer N1525). It seems > you've done it, but i can't figure out how. > > Do i need to build and use kvalo's kernel, or is it enough to build > the modules ath10k_core & ath10k_pci? > I'm a bit afraid of compiling the whole kernel ^^ > output of uname -a: > Linux companion 4.0.0-2-ARCH #1 SMP PREEMPT Tue Apr 14 07:14:46 CEST > 2015 x86_64 GNU/Linux The modules should be enough. Tell us if it works. Compiling a whole kernel isn't too hard if you already have a working configuration. > I have the disassembly.py, but cannot find the dissect.py, can you > provide the link? Or, even better, the assembled files? I won't upload the assembled files now, I don't know if I can get licensing issues. You can find the dissect.py script here: http://lists.infradead.org/pipermail/ath10k/2015-April/005074.html Good luck! Regards, Gabriele ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: QCA6174 hw2.1?
Hi! I have the same problems with my card (also a Killer N1525). It seems you've done it, but i can't figure out how. Do i need to build and use kvalo's kernel, or is it enough to build the modules ath10k_core & ath10k_pci? I'm a bit afraid of compiling the whole kernel ^^ output of uname -a: Linux companion 4.0.0-2-ARCH #1 SMP PREEMPT Tue Apr 14 07:14:46 CEST 2015 x86_64 GNU/Linux I have the disassembly.py, but cannot find the dissect.py, can you provide the link? Or, even better, the assembled files? Many thanks for help! Moritz 2015-04-27 2:21 GMT+02:00 Gabriele Martino : > Just tried the kvalo's kernel. > NetworkManager connected flawlessly at boot to my WPA2 home network on > 2.4GHz. Will try 5GHz later. > iwconfig reports a fixed 1Mb/s bitrate, but I can copy files to my nas > (smb share) at about 3.3MB/s. > That's a reasonable speed for b/g wireless. > > iwconfig: > wlp3s0IEEE 802.11abgn ESSID:"W-I-SEE-YOU-N" > Mode:Managed Frequency:2.412 GHz Access Point: > 40:16:7E:2C:79:90 > Bit Rate=1 Mb/s Tx-Power=20 dBm > Retry short limit:7 RTS thr:off Fragment thr:off > Encryption key:off > Power Management:on > Link Quality=59/70 Signal level=-51 dBm > Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 > Tx excessive retries:0 Invalid misc:42 Missed beacon:0 > > iwlist scan (part of): > wlp3s0Scan completed : > Cell 01 - Address: 40:16:7E:2C:79:90 > Channel:1 > Frequency:2.412 GHz (Channel 1) > Quality=60/70 Signal level=-50 dBm > Encryption key:on > ESSID:"W-I-SEE-YOU-N" > Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 18 Mb/s > 24 Mb/s; 36 Mb/s; 54 Mb/s > Bit Rates:6 Mb/s; 9 Mb/s; 12 Mb/s; 48 Mb/s > Mode:Master > Extra:tsf=0005244f5a5d > Extra: Last beacon: 33ms ago > IE: Unknown: 000D572D492D5345452D594F552D4E > IE: Unknown: 010882848B962430486C > IE: Unknown: 030101 > IE: Unknown: 2A0104 > IE: Unknown: 2F0104 > IE: IEEE 802.11i/WPA2 Version 1 > Group Cipher : CCMP > Pairwise Ciphers (1) : CCMP > Authentication Suites (1) : PSK > > dmesg output: > [2.212106] ath10k_pci :03:00.0: enabling device ( -> 0002) > [2.212558] ath10k_pci :03:00.0: pci irq msi-x interrupts 8 > irq_mode 0 reset_mode 0 > [2.368318] ath10k_pci :03:00.0: Direct firmware load for > ath10k/cal-pci-:03:00.0.bin failed with error -2 > [2.368971] ath10k_pci :03:00.0: Direct firmware load for > ath10k/QCA6174/hw2.1/board-pci-168c:003e:1a56:1525.bin failed with error -2 > [2.368974] ath10k_pci :03:00.0: failed to load spec board file, > falling back to generic: -2 > [2.369252] ath10k_pci :03:00.0: Direct firmware load for > ath10k/QCA6174/hw2.1/firmware-5.bin failed with error -2 > [2.369270] ath10k_pci :03:00.0: could not fetch firmware file > 'ath10k/QCA6174/hw2.1/firmware-5.bin': -2 > [3.559021] ath10k_pci :03:00.0: qca6174 hw2.1 (0x0501, > 0x003405ff, 168c:003e:1a56:1525 fallback) fw killer-n1525-fw api 4 htt > 3.0 wmi 4 cal otp max_sta 32 > [3.559024] ath10k_pci :03:00.0: debug 1 debugfs 0 tracing 0 dfs > 0 testmode 0 > [3.623733] ath: EEPROM regdomain: 0x6c > [3.623735] ath: EEPROM indicates we should expect a direct regpair map > [3.623736] ath: Country alpha2 being used: 00 > [3.623737] ath: Regpair used: 0x6c > [3.638102] ath10k_pci :03:00.0 wlp3s0: renamed from wlan0 > [7.523617] ath10k_pci :03:00.0: no channel configured; ignoring > frame(s)! > [7.627173] ath10k_pci :03:00.0: no channel configured; ignoring > frame(s)! > [ 12.149947] wlp3s0: authenticate with 40:16:7e:2c:79:90 > [ 12.183915] wlp3s0: send auth to 40:16:7e:2c:79:90 (try 1/3) > [ 12.185559] wlp3s0: authenticated > [ 12.186043] wlp3s0: associate with 40:16:7e:2c:79:90 (try 1/3) > [ 12.189402] wlp3s0: RX AssocResp from 40:16:7e:2c:79:90 (capab=0x411 > status=0 aid=3) > [ 12.192174] wlp3s0: associated > [ 313.912952] wlp3s0: AP 40:16:7e:2c:79:90 changed bandwidth, new > config is 2412 MHz, width 1 (2412/0 MHz) > [ 313.912955] wlp3s0: AP 40:16:7e:2c:79:90 changed bandwidth in a way > we can't support - disconnect > [ 318.709453] wlp3s0: authenticate with 40:16:7e:2c:79:90 > [ 318.750807] wlp3s0: send auth to 40:16:7e:2c:79:90 (try 1/3) > [ 318.752541] wlp3s0: authenticated > [ 318.753030] wlp3s0: associate with 40:16:7e:2c:79:90 (try 1/3) > [ 318.756524] wlp3s0: RX AssocResp from 40:16:7e:2c:79:90 (capab=0x411 > status=0 aid=1) > [ 318.759082] wlp3s0: associated > > I'm using the board file
Re: QCA6174 hw2.1?
Just tried the kvalo's kernel. NetworkManager connected flawlessly at boot to my WPA2 home network on 2.4GHz. Will try 5GHz later. iwconfig reports a fixed 1Mb/s bitrate, but I can copy files to my nas (smb share) at about 3.3MB/s. That's a reasonable speed for b/g wireless. iwconfig: wlp3s0IEEE 802.11abgn ESSID:"W-I-SEE-YOU-N" Mode:Managed Frequency:2.412 GHz Access Point: 40:16:7E:2C:79:90 Bit Rate=1 Mb/s Tx-Power=20 dBm Retry short limit:7 RTS thr:off Fragment thr:off Encryption key:off Power Management:on Link Quality=59/70 Signal level=-51 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:42 Missed beacon:0 iwlist scan (part of): wlp3s0Scan completed : Cell 01 - Address: 40:16:7E:2C:79:90 Channel:1 Frequency:2.412 GHz (Channel 1) Quality=60/70 Signal level=-50 dBm Encryption key:on ESSID:"W-I-SEE-YOU-N" Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 18 Mb/s 24 Mb/s; 36 Mb/s; 54 Mb/s Bit Rates:6 Mb/s; 9 Mb/s; 12 Mb/s; 48 Mb/s Mode:Master Extra:tsf=0005244f5a5d Extra: Last beacon: 33ms ago IE: Unknown: 000D572D492D5345452D594F552D4E IE: Unknown: 010882848B962430486C IE: Unknown: 030101 IE: Unknown: 2A0104 IE: Unknown: 2F0104 IE: IEEE 802.11i/WPA2 Version 1 Group Cipher : CCMP Pairwise Ciphers (1) : CCMP Authentication Suites (1) : PSK dmesg output: [2.212106] ath10k_pci :03:00.0: enabling device ( -> 0002) [2.212558] ath10k_pci :03:00.0: pci irq msi-x interrupts 8 irq_mode 0 reset_mode 0 [2.368318] ath10k_pci :03:00.0: Direct firmware load for ath10k/cal-pci-:03:00.0.bin failed with error -2 [2.368971] ath10k_pci :03:00.0: Direct firmware load for ath10k/QCA6174/hw2.1/board-pci-168c:003e:1a56:1525.bin failed with error -2 [2.368974] ath10k_pci :03:00.0: failed to load spec board file, falling back to generic: -2 [2.369252] ath10k_pci :03:00.0: Direct firmware load for ath10k/QCA6174/hw2.1/firmware-5.bin failed with error -2 [2.369270] ath10k_pci :03:00.0: could not fetch firmware file 'ath10k/QCA6174/hw2.1/firmware-5.bin': -2 [3.559021] ath10k_pci :03:00.0: qca6174 hw2.1 (0x0501, 0x003405ff, 168c:003e:1a56:1525 fallback) fw killer-n1525-fw api 4 htt 3.0 wmi 4 cal otp max_sta 32 [3.559024] ath10k_pci :03:00.0: debug 1 debugfs 0 tracing 0 dfs 0 testmode 0 [3.623733] ath: EEPROM regdomain: 0x6c [3.623735] ath: EEPROM indicates we should expect a direct regpair map [3.623736] ath: Country alpha2 being used: 00 [3.623737] ath: Regpair used: 0x6c [3.638102] ath10k_pci :03:00.0 wlp3s0: renamed from wlan0 [7.523617] ath10k_pci :03:00.0: no channel configured; ignoring frame(s)! [7.627173] ath10k_pci :03:00.0: no channel configured; ignoring frame(s)! [ 12.149947] wlp3s0: authenticate with 40:16:7e:2c:79:90 [ 12.183915] wlp3s0: send auth to 40:16:7e:2c:79:90 (try 1/3) [ 12.185559] wlp3s0: authenticated [ 12.186043] wlp3s0: associate with 40:16:7e:2c:79:90 (try 1/3) [ 12.189402] wlp3s0: RX AssocResp from 40:16:7e:2c:79:90 (capab=0x411 status=0 aid=3) [ 12.192174] wlp3s0: associated [ 313.912952] wlp3s0: AP 40:16:7e:2c:79:90 changed bandwidth, new config is 2412 MHz, width 1 (2412/0 MHz) [ 313.912955] wlp3s0: AP 40:16:7e:2c:79:90 changed bandwidth in a way we can't support - disconnect [ 318.709453] wlp3s0: authenticate with 40:16:7e:2c:79:90 [ 318.750807] wlp3s0: send auth to 40:16:7e:2c:79:90 (try 1/3) [ 318.752541] wlp3s0: authenticated [ 318.753030] wlp3s0: associate with 40:16:7e:2c:79:90 (try 1/3) [ 318.756524] wlp3s0: RX AssocResp from 40:16:7e:2c:79:90 (capab=0x411 status=0 aid=1) [ 318.759082] wlp3s0: associated I'm using the board file "eeprom_qca9377_1p0_NFA435_olpc.bin". Regards, Gabriele On 26/04/2015 16:10, Gabriele Martino wrote: > Hi Corin, > the "dissect.py" script seems to work better than the "disassemble.py": > > [ 6483.455435] ath10k_pci :03:00.0: pci irq msi-x interrupts 8 > irq_mode 0 reset_mode 0 > [ 6483.600747] ath10k_pci :03:00.0: Direct firmware load for > ath10k/cal-pci-:03:00.0.bin failed with error -2 > [ 6484.772417] ath10k_pci :03:00.0: firmware crashed! (uuid n/a) > [ 6484.772433] ath10k_pci :03:00.0: qca6174 hw2.1 (0x0501, > 0x003405ff) fw killer-n1525-fw api 4 htt 0.0 wmi 4 cal otp max_sta 32 > [ 6484.772435] ath10k_pci :03:00.0: debug 1 debugfs 0 tracing 0 dfs > 0 testmode 0 > [ 6484.77] ath10k_pci :03:00.0: firmwar
Re: QCA6174 hw2.1?
Hi Corin, the "dissect.py" script seems to work better than the "disassemble.py": [ 6483.455435] ath10k_pci :03:00.0: pci irq msi-x interrupts 8 irq_mode 0 reset_mode 0 [ 6483.600747] ath10k_pci :03:00.0: Direct firmware load for ath10k/cal-pci-:03:00.0.bin failed with error -2 [ 6484.772417] ath10k_pci :03:00.0: firmware crashed! (uuid n/a) [ 6484.772433] ath10k_pci :03:00.0: qca6174 hw2.1 (0x0501, 0x003405ff) fw killer-n1525-fw api 4 htt 0.0 wmi 4 cal otp max_sta 32 [ 6484.772435] ath10k_pci :03:00.0: debug 1 debugfs 0 tracing 0 dfs 0 testmode 0 [ 6484.77] ath10k_pci :03:00.0: firmware register dump: [ 6484.77] ath10k_pci :03:00.0: [00]: 0x0501 0x15B3 0x0095186B 0x00955B31 [ 6484.77] ath10k_pci :03:00.0: [04]: 0x0095186B 0x00060130 0x0010 0x0040AF04 [ 6484.77] ath10k_pci :03:00.0: [08]: 0x0018 0x0001 0x0001 0x00412250 [ 6484.77] ath10k_pci :03:00.0: [12]: 0x0009 0x 0x0096C09C 0x0096C0A7 [ 6484.77] ath10k_pci :03:00.0: [16]: 0x0096BDBC 0x009286B6 0x 0x [ 6484.77] ath10k_pci :03:00.0: [20]: 0x4095186B 0x0040E160 0x0041F82C 0x0001 [ 6484.77] ath10k_pci :03:00.0: [24]: 0x80936238 0x0040E1C0 0x 0xC095186B [ 6484.77] ath10k_pci :03:00.0: [28]: 0x80936361 0x0040E1E0 0x 0x0041C8DC [ 6484.77] ath10k_pci :03:00.0: [32]: 0x80934A67 0x0040E200 0x00436DF0 0x0040E250 [ 6484.77] ath10k_pci :03:00.0: [36]: 0x809A5C92 0x0040E250 0x004275B0 0x0001 [ 6484.77] ath10k_pci :03:00.0: [40]: 0x809A5CEA 0x0040E290 0x00426F40 0x0004 [ 6484.77] ath10k_pci :03:00.0: [44]: 0x809A5DCA 0x0040E2B0 0x00426F40 0x0041C8DC [ 6484.77] ath10k_pci :03:00.0: [48]: 0x800A0909 0x0040E2D0 0x00426F40 0x004275A0 [ 6484.77] ath10k_pci :03:00.0: [52]: 0x800A024A 0x0040E2F0 0x0041ABB0 0x00420440 [ 6484.77] ath10k_pci :03:00.0: [56]: 0x809287D9 0x0040E310 0x 0x0040 [ 6485.765040] ath10k_pci :03:00.0: failed to receive control response completion, polling.. [ 6486.765027] ath10k_pci :03:00.0: ctl_resp never came in (-110) [ 6486.765032] ath10k_pci :03:00.0: failed to connect to HTC: -110 [ 6486.828658] ath10k_pci :03:00.0: could not init core (-110) [ 6486.828689] ath10k_pci :03:00.0: could not probe fw (-110) [ 6486.831175] ath10k_pci :03:00.0: cannot restart a device that hasn't been started Well, at least it loads correctly. This should be the firmware crash fixed in the patches, it's time to test kvalo's kernel sources. On 26/04/2015 05:51, Corin Lawson wrote: > Hi Gabriele, > > I think we have the same card (the vendor and device ids are the > determining factor): > > $ lspci -n -s 05:00.0 > 05:00.0 0280: 168c:003e (rev 20) > > Without the skip_otp option I get this in dmesg: > > [18396.622576] ath10k_pci :05:00.0: pci irq msi interrupts 1 > irq_mode 0 reset_mode 0 > [18396.768593] ath10k_pci :05:00.0: Direct firmware load for > ath10k/cal-pci-:05:00.0.bin failed with error -2 > [18396.847975] ath10k_pci :05:00.0: otp calibration failed: 3 > [18396.847977] ath10k_pci :05:00.0: failed to run otp: -22 > [18396.847978] ath10k_pci :05:00.0: could not init core (-22) > [18396.847995] ath10k_pci :05:00.0: could not probe fw (-22) > > Which is different to your messages. I'm taking a guess here, but > those DMAR messages seem to indicate that the firmware is attempting > to write to the wrong part of memory (i.e. wrong firmware). > > Using kvalo's kernel fork is probably a good step (it contains those > necessary patches). If you still don't get it working, then my only > other idea is to try that dissect.py gist I mentioned previously. Here > are the commands that worked for me: > > # python dissect.py < > drivers/Production/Windows8.1-x64/k1525w81/qca61x420.bin > # python assemble.py killer-n1525-fw 0 fw-2.bin fw-1.bin 4 > > /lib/firmware/ath10k/QCA6174/hw2.1/firmware-4.bin > > The dissect.py script produced fw-1.bin which is the otp file and > fw-2.bin which is the correct firmware (don't quote me on that, but it > worked for me). As for your board.bin file, you need to check the .inf > file that comes with your drivers. I'm not sure what the structure of > that file is... for all I know I could be using the wrong board > file... > > I hope this helps, otherwise you've reached the limits of my > experience :) Maybe someone else on the list has a better idea? > > Cheers, > Corin > > > On Sat, Apr 25, 2015 at 10:58 PM, Gabriele Martino wrote: >> On 25/04/2015 05:47, Corin Lawson wrote: >>> I also had problems with calibration, I had to pass skip_otp=y to the >>> module: >>> >>> $ cat /etc/modprobe.d/ath10k.conf >>> options ath10k_core skip_otp=y >> Hi Corin, >> I removed ath10k_pci, ath10k_core and ath before loading ath10k_core >> with skip_otp=1, but nothing happened: >> >> [ 1808.473874] ath10k_pci :0
Re: QCA6174 hw2.1?
Hi Gabriele, I think we have the same card (the vendor and device ids are the determining factor): $ lspci -n -s 05:00.0 05:00.0 0280: 168c:003e (rev 20) Without the skip_otp option I get this in dmesg: [18396.622576] ath10k_pci :05:00.0: pci irq msi interrupts 1 irq_mode 0 reset_mode 0 [18396.768593] ath10k_pci :05:00.0: Direct firmware load for ath10k/cal-pci-:05:00.0.bin failed with error -2 [18396.847975] ath10k_pci :05:00.0: otp calibration failed: 3 [18396.847977] ath10k_pci :05:00.0: failed to run otp: -22 [18396.847978] ath10k_pci :05:00.0: could not init core (-22) [18396.847995] ath10k_pci :05:00.0: could not probe fw (-22) Which is different to your messages. I'm taking a guess here, but those DMAR messages seem to indicate that the firmware is attempting to write to the wrong part of memory (i.e. wrong firmware). Using kvalo's kernel fork is probably a good step (it contains those necessary patches). If you still don't get it working, then my only other idea is to try that dissect.py gist I mentioned previously. Here are the commands that worked for me: # python dissect.py < drivers/Production/Windows8.1-x64/k1525w81/qca61x420.bin # python assemble.py killer-n1525-fw 0 fw-2.bin fw-1.bin 4 > /lib/firmware/ath10k/QCA6174/hw2.1/firmware-4.bin The dissect.py script produced fw-1.bin which is the otp file and fw-2.bin which is the correct firmware (don't quote me on that, but it worked for me). As for your board.bin file, you need to check the .inf file that comes with your drivers. I'm not sure what the structure of that file is... for all I know I could be using the wrong board file... I hope this helps, otherwise you've reached the limits of my experience :) Maybe someone else on the list has a better idea? Cheers, Corin On Sat, Apr 25, 2015 at 10:58 PM, Gabriele Martino wrote: > On 25/04/2015 05:47, Corin Lawson wrote: >> I also had problems with calibration, I had to pass skip_otp=y to the module: >> >> $ cat /etc/modprobe.d/ath10k.conf >> options ath10k_core skip_otp=y > Hi Corin, > I removed ath10k_pci, ath10k_core and ath before loading ath10k_core > with skip_otp=1, but nothing happened: > > [ 1808.473874] ath10k_pci :03:00.0: pci irq msi-x interrupts 8 > irq_mode 0 reset_mode 0 > [ 1808.618770] ath10k_pci :03:00.0: Direct firmware load for > ath10k/cal-pci-:03:00.0.bin failed with error -2 > [ 1808.687492] dmar: DRHD: handling fault status reg 2 > [ 1808.687506] dmar: DMAR:[DMA Write] Request device [03:00.0] fault > addr 7ee0 >DMAR:[fault reason 05] PTE Write access is not set > [ 1809.688015] ath10k_pci :03:00.0: unable to write to the device > [ 1809.688018] ath10k_pci :03:00.0: failed to download normal > firmware: -110 > [ 1809.688020] ath10k_pci :03:00.0: could not init core (-110) > [ 1809.688054] ath10k_pci :03:00.0: could not probe fw (-110) > > I assembled the otp.bin with fw.bin to get the blob, so I'm not sure > skip_otp will fix this... > Now I'm cloning the kvalo's kernel tree, this should be faster than > picking the single patches. > >> FWIW: >> >> $ lspci -vs 05:00.0 >> 05:00.0 Network controller: Qualcomm Atheros Device 003e (rev 20) >> Subsystem: Bigfoot Networks, Inc. Device 1525 >> Flags: bus master, fast devsel, latency 0, IRQ 31 >> Memory at f780 (64-bit, non-prefetchable) [size=2M] >> Capabilities: >> Kernel driver in use: ath10k_pci >> Kernel modules: ath10k_pci > Well, mine seems a bit different: > > 03:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless > Network Adapter (rev 20) > Subsystem: Bigfoot Networks, Inc. Killer N1525 Wireless-AC > Flags: bus master, fast devsel, latency 0, IRQ 32 > Memory at f680 (64-bit, non-prefetchable) [size=2M] > Capabilities: [40] Power Management version 3 > Capabilities: [50] MSI: Enable+ Count=8/8 Maskable+ 64bit- > Capabilities: [70] Express Endpoint, MSI 00 > Capabilities: [100] Advanced Error Reporting > Capabilities: [148] Virtual Channel > Capabilities: [168] Device Serial Number 00-00-00-00-00-00-00-00 > Capabilities: [178] Latency Tolerance Reporting > Capabilities: [180] L1 PM Substates > Kernel driver in use: ath10k_pci > Kernel modules: ath10k_pci > >> I would interested in knowing from where you got your drivers/board >> files. I had to download mine from my laptop manufacturer's (MSI) >> website. > I mounted the preinstalled Windows 8 partition on /mnt and run: > find /mnt -iname '*.bin' > > The same files can be found inside the driver installer on the Alienware > (Dell) website. > > Regards, > Gabriele > ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: QCA6174 hw2.1?
Hi Gabriele, I have had success with eeprom_ar6320_2p1_NFA344i.bin. I am also using Gentoo (but v3.19.3) but I have also applied these patches/commits: - http://permalink.gmane.org/gmane.linux.kernel.wireless.general/137030 - https://github.com/kvalo/ath/commit/d63955b33b3bee45d784ffdfafeb93076c765660 Also, I didn't use that disassemble.py script, I used: - https://gist.github.com/kazikcz/8e5845ad84ca251aa295 I also had problems with calibration, I had to pass skip_otp=y to the module: $ cat /etc/modprobe.d/ath10k.conf options ath10k_core skip_otp=y FWIW: $ lspci -vs 05:00.0 05:00.0 Network controller: Qualcomm Atheros Device 003e (rev 20) Subsystem: Bigfoot Networks, Inc. Device 1525 Flags: bus master, fast devsel, latency 0, IRQ 31 Memory at f780 (64-bit, non-prefetchable) [size=2M] Capabilities: Kernel driver in use: ath10k_pci Kernel modules: ath10k_pci I give a huge thanks to the individuals on this mailing list for helping me; I'm just happy to give back where I can :) I would interested in knowing from where you got your drivers/board files. I had to download mine from my laptop manufacturer's (MSI) website. Note: I understand that ath10k doesn't support encryption yet. But I haven't successfully been able to connect to my open AP as yet... Cheers, Corin On Sat, Apr 25, 2015 at 11:15 AM, Gabriele Martino wrote: > > Michal Kazior tieto.com> writes: > > > > > https://gist.github.com/kazikcz/c970cbf3a863ebbc4495 > > https://gist.github.com/kazikcz/64313b9e2470660faae1 > > > > Here are two simple and crude tools I have to deal with ath10k FW API > > blobs. Use with care. > > > > You can use the disassemble.py to extract the otp.bin from hw3 ath10k > > FW API blob: > > > > python disassemble.py < /lib/firmware/ath10k/QCA6174/hw3.0/firmware-4.bin > > > > Then you can use the assemble.py to generate hw2.1 ath10k FW ABI blob: > > > > mkdir -p /lib/firmware/ath10k/QCA6174/hw2.1/ > > python assemble.py killer1252-testfw 0 path/to/qca61x420.bin > > path/to/otp.bin 4 > /lib/firmware/ath10k/QCA6174/hw2.1/firmware-4.bin > > cp path/to/eeprom_ar6320_2p1_NFA354xp.bin > > /lib/firmware/ath10k/QCA6174/hw2.1/board.bin > > > > (mind the email line wrapping) > > > > I'm trying to generate the blob, but I found two big issues. > The first: I have too many board files, which one should I use? > eeprom_ar6320_2p1_NFA324i_5.bin > eeprom_ar6320_2p1_NFA344i.bin > eeprom_ar6320_2p1_NFA344i_highTX.bin > eeprom_ar6320_2p1_NFA345i.bin > eeprom_ar6320_2p1_NFA345i_highTX.bin > eeprom_ar6320_2p1_NFA354xp.bin > eeprom_ar6320_2p1_NFA355i.bin > eeprom_qca9377_1p0_NFA435_olpc.bin > > The controller is a > "Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter (rev 20)" > declared as Killer N1525 on Alienware 15. > > Whatever, I can try them one by one later. > I picked up the first and built the firmware blob. > But here's the second issue: it wants the calibration data. > > [2.067447] ath10k_pci :03:00.0: enabling device ( -> 0002) > [2.068679] ath10k_pci :03:00.0: pci irq msi-x interrupts 8 irq_mode > 0 reset_mode 0 > [2.215280] ath10k_pci :03:00.0: Direct firmware load for > ath10k/cal-pci- > :03:00.0.bin failed with error -2 > [2.924276] ath3k: probe of 1-9:1.0 failed with error -22 > [2.924299] usbcore: registered new interface driver ath3k > [3.289023] ath10k_pci :03:00.0: unable to write to the device > [3.289026] ath10k_pci :03:00.0: failed to download normal firmware: > -110 > [3.289052] ath10k_pci :03:00.0: could not init core (-110) > [3.289099] ath10k_pci :03:00.0: could not probe fw (-110) > > How can I generate the cal-pci-:03:00.0.bin file? > I'm using the 4.0.0-gentoo kernel on x86_64. > > Regards, > Gabriele > > > ___ > 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 hw2.1?
Michal Kazior tieto.com> writes: > > https://gist.github.com/kazikcz/c970cbf3a863ebbc4495 > https://gist.github.com/kazikcz/64313b9e2470660faae1 > > Here are two simple and crude tools I have to deal with ath10k FW API > blobs. Use with care. > > You can use the disassemble.py to extract the otp.bin from hw3 ath10k > FW API blob: > > python disassemble.py < /lib/firmware/ath10k/QCA6174/hw3.0/firmware-4.bin > > Then you can use the assemble.py to generate hw2.1 ath10k FW ABI blob: > > mkdir -p /lib/firmware/ath10k/QCA6174/hw2.1/ > python assemble.py killer1252-testfw 0 path/to/qca61x420.bin > path/to/otp.bin 4 > /lib/firmware/ath10k/QCA6174/hw2.1/firmware-4.bin > cp path/to/eeprom_ar6320_2p1_NFA354xp.bin > /lib/firmware/ath10k/QCA6174/hw2.1/board.bin > > (mind the email line wrapping) > I'm trying to generate the blob, but I found two big issues. The first: I have too many board files, which one should I use? eeprom_ar6320_2p1_NFA324i_5.bin eeprom_ar6320_2p1_NFA344i.bin eeprom_ar6320_2p1_NFA344i_highTX.bin eeprom_ar6320_2p1_NFA345i.bin eeprom_ar6320_2p1_NFA345i_highTX.bin eeprom_ar6320_2p1_NFA354xp.bin eeprom_ar6320_2p1_NFA355i.bin eeprom_qca9377_1p0_NFA435_olpc.bin The controller is a "Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter (rev 20)" declared as Killer N1525 on Alienware 15. Whatever, I can try them one by one later. I picked up the first and built the firmware blob. But here's the second issue: it wants the calibration data. [2.067447] ath10k_pci :03:00.0: enabling device ( -> 0002) [2.068679] ath10k_pci :03:00.0: pci irq msi-x interrupts 8 irq_mode 0 reset_mode 0 [2.215280] ath10k_pci :03:00.0: Direct firmware load for ath10k/cal-pci- :03:00.0.bin failed with error -2 [2.924276] ath3k: probe of 1-9:1.0 failed with error -22 [2.924299] usbcore: registered new interface driver ath3k [3.289023] ath10k_pci :03:00.0: unable to write to the device [3.289026] ath10k_pci :03:00.0: failed to download normal firmware: -110 [3.289052] ath10k_pci :03:00.0: could not init core (-110) [3.289099] ath10k_pci :03:00.0: could not probe fw (-110) How can I generate the cal-pci-:03:00.0.bin file? I'm using the 4.0.0-gentoo kernel on x86_64. Regards, Gabriele ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: Re: QCA6174 hw2.1?
Checking in again. Could I get the QCA6174 /2.1hw firmware made faster if I "sponsored" it? > Sent: Tuesday, April 07, 2015 at 10:44 AM > From: "Jason H" > To: "Jason H" > Cc: "Michal Kazior" , "ath10k@lists.infradead.org" > > Subject: Re: Re: QCA6174 hw2.1? > > Just checking in. Any updates for the QCA6174? > > > Sent: Monday, March 23, 2015 at 9:57 AM > > From: "Jason H" > > To: "Michal Kazior" > > Cc: "ath10k@lists.infradead.org" > > Subject: Re: Re: QCA6174 hw2.1? > > > > > > > > > Sent: Monday, March 23, 2015 at 4:23 AM > > > From: "Michal Kazior" > > > To: "Jason H" > > > Cc: "ath10k@lists.infradead.org" > > > Subject: Re: Re: QCA6174 hw2.1? > > > > > > On 21 March 2015 at 21:31, wrote: > > > > is there anyway you could process these files for me?. I would be > > > > willing to send you the files and go through some back and forth of > > > > feedback and whatnot. The issue is I just don't think I have the time > > > > or the expertise to devote to this. However I investigated exchanging > > > > the laptop to get a Linux compatible one, but its going to cost me > > > > money for the restocking fee. On top of that the next user of this > > > > laptop will be disgruntled when they find a non working copy of Linux > > > > on it. I investigated getting the restore cd but Lenovo's charging $70 > > > > for the media. So if you could help I would really appreciate it > > > > because this is the last thing that I need to get working but I really > > > > need it. > > > > > > > > and we could also get this chipset supported. I saw I wasn't the only > > > > one looking for Linux support for this driver. > > > > > > Thanks for willing to help. However I finally got my hands on the > > > Killer 1525 card. I tried playing with it but I couldn't get ath10k to > > > work with it yet. > > > > > > There's some firmware crash issue that needs investigating. Kalle's > > > doing his best to sort this out internally. > > > > > > Hopefully we'll get this working soon and we'll let everyone know on > > > the mailing list. I can understand your situation very well. I know it > > > sucks. > > > > > > > > > Thanks however in my investigation, this was not the same as the "Killer" > > card. > > > > > > ___ > > 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: Re: QCA6174 hw2.1?
Just checking in. Any updates for the QCA6174? > Sent: Monday, March 23, 2015 at 9:57 AM > From: "Jason H" > To: "Michal Kazior" > Cc: "ath10k@lists.infradead.org" > Subject: Re: Re: QCA6174 hw2.1? > > > > > Sent: Monday, March 23, 2015 at 4:23 AM > > From: "Michal Kazior" > > To: "Jason H" > > Cc: "ath10k@lists.infradead.org" > > Subject: Re: Re: QCA6174 hw2.1? > > > > On 21 March 2015 at 21:31, wrote: > > > is there anyway you could process these files for me?. I would be willing > > > to send you the files and go through some back and forth of feedback and > > > whatnot. The issue is I just don't think I have the time or the expertise > > > to devote to this. However I investigated exchanging the laptop to get a > > > Linux compatible one, but its going to cost me money for the restocking > > > fee. On top of that the next user of this laptop will be disgruntled when > > > they find a non working copy of Linux on it. I investigated getting the > > > restore cd but Lenovo's charging $70 for the media. So if you could help > > > I would really appreciate it because this is the last thing that I need > > > to get working but I really need it. > > > > > > and we could also get this chipset supported. I saw I wasn't the only one > > > looking for Linux support for this driver. > > > > Thanks for willing to help. However I finally got my hands on the > > Killer 1525 card. I tried playing with it but I couldn't get ath10k to > > work with it yet. > > > > There's some firmware crash issue that needs investigating. Kalle's > > doing his best to sort this out internally. > > > > Hopefully we'll get this working soon and we'll let everyone know on > > the mailing list. I can understand your situation very well. I know it > > sucks. > > > > > Thanks however in my investigation, this was not the same as the "Killer" > card. > > > ___ > 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: Re: QCA6174 hw2.1?
> Sent: Monday, March 23, 2015 at 9:57 AM > > Sent: Monday, March 23, 2015 at 4:23 AM > > > > On 21 March 2015 at 21:31, wrote: > > > is there anyway you could process these files for me?. I would be willing > > > to send you the files and go through some back and forth of feedback and > > > whatnot. The issue is I just don't think I have the time or the expertise > > > to devote to this. However I investigated exchanging the laptop to get a > > > Linux compatible one, but its going to cost me money for the restocking > > > fee. On top of that the next user of this laptop will be disgruntled when > > > they find a non working copy of Linux on it. I investigated getting the > > > restore cd but Lenovo's charging $70 for the media. So if you could help > > > I would really appreciate it because this is the last thing that I need > > > to get working but I really need it. > > > > > > and we could also get this chipset supported. I saw I wasn't the only one > > > looking for Linux support for this driver. > > > > Thanks for willing to help. However I finally got my hands on the > > Killer 1525 card. I tried playing with it but I couldn't get ath10k to > > work with it yet. > > > > There's some firmware crash issue that needs investigating. Kalle's > > doing his best to sort this out internally. > > > > Hopefully we'll get this working soon and we'll let everyone know on > > the mailing list. I can understand your situation very well. I know it > > sucks. > > > > > Thanks however in my investigation, this was not the same as the "Killer" > card. Any updates to QCA6174? ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: Re: QCA6174 hw2.1?
> Sent: Monday, March 23, 2015 at 4:23 AM > From: "Michal Kazior" > To: "Jason H" > Cc: "ath10k@lists.infradead.org" > Subject: Re: Re: QCA6174 hw2.1? > > On 21 March 2015 at 21:31, wrote: > > is there anyway you could process these files for me?. I would be willing > > to send you the files and go through some back and forth of feedback and > > whatnot. The issue is I just don't think I have the time or the expertise > > to devote to this. However I investigated exchanging the laptop to get a > > Linux compatible one, but its going to cost me money for the restocking > > fee. On top of that the next user of this laptop will be disgruntled when > > they find a non working copy of Linux on it. I investigated getting the > > restore cd but Lenovo's charging $70 for the media. So if you could help I > > would really appreciate it because this is the last thing that I need to > > get working but I really need it. > > > > and we could also get this chipset supported. I saw I wasn't the only one > > looking for Linux support for this driver. > > Thanks for willing to help. However I finally got my hands on the > Killer 1525 card. I tried playing with it but I couldn't get ath10k to > work with it yet. > > There's some firmware crash issue that needs investigating. Kalle's > doing his best to sort this out internally. > > Hopefully we'll get this working soon and we'll let everyone know on > the mailing list. I can understand your situation very well. I know it > sucks. > Thanks however in my investigation, this was not the same as the "Killer" card. ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: Re: QCA6174 hw2.1?
On 21 March 2015 at 21:31, wrote: > is there anyway you could process these files for me?. I would be willing to > send you the files and go through some back and forth of feedback and > whatnot. The issue is I just don't think I have the time or the expertise to > devote to this. However I investigated exchanging the laptop to get a Linux > compatible one, but its going to cost me money for the restocking fee. On top > of that the next user of this laptop will be disgruntled when they find a non > working copy of Linux on it. I investigated getting the restore cd but > Lenovo's charging $70 for the media. So if you could help I would really > appreciate it because this is the last thing that I need to get working but I > really need it. > > and we could also get this chipset supported. I saw I wasn't the only one > looking for Linux support for this driver. Thanks for willing to help. However I finally got my hands on the Killer 1525 card. I tried playing with it but I couldn't get ath10k to work with it yet. There's some firmware crash issue that needs investigating. Kalle's doing his best to sort this out internally. Hopefully we'll get this working soon and we'll let everyone know on the mailing list. I can understand your situation very well. I know it sucks. Michał ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: Re: QCA6174 hw2.1?
is there anyway you could process these files for me?. I would be willing to send you the files and go through some back and forth of feedback and whatnot. The issue is I just don't think I have the time or the expertise to devote to this. However I investigated exchanging the laptop to get a Linux compatible one, but its going to cost me money for the restocking fee. On top of that the next user of this laptop will be disgruntled when they find a non working copy of Linux on it. I investigated getting the restore cd but Lenovo's charging $70 for the media. So if you could help I would really appreciate it because this is the last thing that I need to get working but I really need it. and we could also get this chipset supported. I saw I wasn't the only one looking for Linux support for this driver. Thank you. -Original message- Sent: Monday, 16 March 2015 at 10:05:20 From: "Michal Kazior" To: "Jason H" Subject: Re: QCA6174 hw2.1? On 13 March 2015 at 16:28, Jason H wrote: > >> On 13 March 2015 at 04:39, wrote: >> > I went through the archives, and the wiki but I still wasn't sure... >> > I have a shiny new Lenovo z70, kernel 4.0-rc1/3. Dmesg reports failures >> > for loading firmware in /lib/firmware/ath10k/QCA6174/hw2.1/... >> > So I found the firmware Git repo, but it seems to be missing hw2.1. I >> > even symlinked 2.1 to 3.0, no dice. >> >> You can't use hw3 firmware for hw2 hardware. >> >> The problem is there's no publicly available ath10k firmware for hw2 >> hardware.. >> >> >> > I don't dual boot and this is a laptop so I'm looking to get my WiFi >> > working. Any pointers are appreciated. Thanks. >> >> You could try building hw2 firmware ath10k binary yourself. You need >> to fetch athwlan.bin from Windows driver, extract otp image from hw3 >> firmware ath10k binary and then re-assemble both into hw3 firmware for >> ath10k. The ath10k binary blob is a tag-length-value format and can be >> understood by looking at ath10k_core_fetch_firmware_api_n(). >> >> Nobody seems to have tried this yet though. > > > I installed WINE and attempted to install the driver from lenono on my > non-lenovo with working wifi. The install failed (expected) but not before it > extracted the actual driver installer images (expected). Parsing through an > .inf file, and navigating my way through the sections, I end up at a section > specifying eeprom_ar6320_2p1_NFA354xp.bin and qca61x420.bin as the firmware > files. I have these files. Awesome. eeprom_ar6320_2p1_NFA354xp.bin looks like a board.bin. qca61x420.bin looks like main program binary. > However I am now diverging from your instructions considerably. Also I don't > know why I would want to reassemble into 3.0 when my system is looking for > 2.1? Typo/mind derp :-) I obviously meant 2.1. > I don't know what an 'otp image' is? I think I understand the part about the > ath10k format though. OTP is a calibration related program which is run on device before running main program. It's embedded inside ath10k FW API blob. > Could you update your instructions to suit the new information at hand? https://gist.github.com/kazikcz/c970cbf3a863ebbc4495 https://gist.github.com/kazikcz/64313b9e2470660faae1 Here are two simple and crude tools I have to deal with ath10k FW API blobs. Use with care. You can use the disassemble.py to extract the otp.bin from hw3 ath10k FW API blob: python disassemble.py < /lib/firmware/ath10k/QCA6174/hw3.0/firmware-4.bin Then you can use the assemble.py to generate hw2.1 ath10k FW ABI blob: mkdir -p /lib/firmware/ath10k/QCA6174/hw2.1/ python assemble.py killer1252-testfw 0 path/to/qca61x420.bin path/to/otp.bin 4 > /lib/firmware/ath10k/QCA6174/hw2.1/firmware-4.bin cp path/to/eeprom_ar6320_2p1_NFA354xp.bin /lib/firmware/ath10k/QCA6174/hw2.1/board.bin (mind the email line wrapping) Michał ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: QCA6174 hw2.1?
On 13 March 2015 at 16:28, Jason H wrote: > >> On 13 March 2015 at 04:39, wrote: >> > I went through the archives, and the wiki but I still wasn't sure... >> > I have a shiny new Lenovo z70, kernel 4.0-rc1/3. Dmesg reports failures >> > for loading firmware in /lib/firmware/ath10k/QCA6174/hw2.1/... >> > So I found the firmware Git repo, but it seems to be missing hw2.1. I >> > even symlinked 2.1 to 3.0, no dice. >> >> You can't use hw3 firmware for hw2 hardware. >> >> The problem is there's no publicly available ath10k firmware for hw2 >> hardware.. >> >> >> > I don't dual boot and this is a laptop so I'm looking to get my WiFi >> > working. Any pointers are appreciated. Thanks. >> >> You could try building hw2 firmware ath10k binary yourself. You need >> to fetch athwlan.bin from Windows driver, extract otp image from hw3 >> firmware ath10k binary and then re-assemble both into hw3 firmware for >> ath10k. The ath10k binary blob is a tag-length-value format and can be >> understood by looking at ath10k_core_fetch_firmware_api_n(). >> >> Nobody seems to have tried this yet though. > > > I installed WINE and attempted to install the driver from lenono on my > non-lenovo with working wifi. The install failed (expected) but not before it > extracted the actual driver installer images (expected). Parsing through an > .inf file, and navigating my way through the sections, I end up at a section > specifying eeprom_ar6320_2p1_NFA354xp.bin and qca61x420.bin as the firmware > files. I have these files. Awesome. eeprom_ar6320_2p1_NFA354xp.bin looks like a board.bin. qca61x420.bin looks like main program binary. > However I am now diverging from your instructions considerably. Also I don't > know why I would want to reassemble into 3.0 when my system is looking for > 2.1? Typo/mind derp :-) I obviously meant 2.1. > I don't know what an 'otp image' is? I think I understand the part about the > ath10k format though. OTP is a calibration related program which is run on device before running main program. It's embedded inside ath10k FW API blob. > Could you update your instructions to suit the new information at hand? https://gist.github.com/kazikcz/c970cbf3a863ebbc4495 https://gist.github.com/kazikcz/64313b9e2470660faae1 Here are two simple and crude tools I have to deal with ath10k FW API blobs. Use with care. You can use the disassemble.py to extract the otp.bin from hw3 ath10k FW API blob: python disassemble.py < /lib/firmware/ath10k/QCA6174/hw3.0/firmware-4.bin Then you can use the assemble.py to generate hw2.1 ath10k FW ABI blob: mkdir -p /lib/firmware/ath10k/QCA6174/hw2.1/ python assemble.py killer1252-testfw 0 path/to/qca61x420.bin path/to/otp.bin 4 > /lib/firmware/ath10k/QCA6174/hw2.1/firmware-4.bin cp path/to/eeprom_ar6320_2p1_NFA354xp.bin /lib/firmware/ath10k/QCA6174/hw2.1/board.bin (mind the email line wrapping) Michał ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: QCA6174 hw2.1?
> On 13 March 2015 at 04:39, wrote: > > I went through the archives, and the wiki but I still wasn't sure... > > I have a shiny new Lenovo z70, kernel 4.0-rc1/3. Dmesg reports failures > > for loading firmware in /lib/firmware/ath10k/QCA6174/hw2.1/... > > So I found the firmware Git repo, but it seems to be missing hw2.1. I even > > symlinked 2.1 to 3.0, no dice. > > You can't use hw3 firmware for hw2 hardware. > > The problem is there's no publicly available ath10k firmware for hw2 > hardware.. > > > > I don't dual boot and this is a laptop so I'm looking to get my WiFi > > working. Any pointers are appreciated. Thanks. > > You could try building hw2 firmware ath10k binary yourself. You need > to fetch athwlan.bin from Windows driver, extract otp image from hw3 > firmware ath10k binary and then re-assemble both into hw3 firmware for > ath10k. The ath10k binary blob is a tag-length-value format and can be > understood by looking at ath10k_core_fetch_firmware_api_n(). > > Nobody seems to have tried this yet though. I installed WINE and attempted to install the driver from lenono on my non-lenovo with working wifi. The install failed (expected) but not before it extracted the actual driver installer images (expected). Parsing through an .inf file, and navigating my way through the sections, I end up at a section specifying eeprom_ar6320_2p1_NFA354xp.bin and qca61x420.bin as the firmware files. I have these files. However I am now diverging from your instructions considerably. Also I don't know why I would want to reassemble into 3.0 when my system is looking for 2.1? I don't know what an 'otp image' is? I think I understand the part about the ath10k format though. Could you update your instructions to suit the new information at hand? Thanks again ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: QCA6174 hw2.1?
On 13 March 2015 at 04:39, wrote: > I went through the archives, and the wiki but I still wasn't sure... > I have a shiny new Lenovo z70, kernel 4.0-rc1/3. Dmesg reports failures for > loading firmware in /lib/firmware/ath10k/QCA6174/hw2.1/... > So I found the firmware Git repo, but it seems to be missing hw2.1. I even > symlinked 2.1 to 3.0, no dice. You can't use hw3 firmware for hw2 hardware. The problem is there's no publicly available ath10k firmware for hw2 hardware.. > I don't dual boot and this is a laptop so I'm looking to get my WiFi > working. Any pointers are appreciated. Thanks. You could try building hw2 firmware ath10k binary yourself. You need to fetch athwlan.bin from Windows driver, extract otp image from hw3 firmware ath10k binary and then re-assemble both into hw3 firmware for ath10k. The ath10k binary blob is a tag-length-value format and can be understood by looking at ath10k_core_fetch_firmware_api_n(). Nobody seems to have tried this yet though. Michał ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
