ath10k-regression in 4.14: Connections aborts with "failed to extract amsdu: -11"

ath10k-regression in 4.14: Connections aborts with "failed to extract amsdu: -11"

[Thorsten Leemhuis]

Lo! The wifi connection of my Dell XPS13 (9360) with its QCA6174
sometimes suddenly stops working since I switched to 4.14-rc2+. Every
time it happens, there is this error message in dmesg:

> ath10k_pci 0000:3a:00.0: failed to extract amsdu: -11

I have to switch wifi off and on with the hotkey to reconnect. I can
trigger the aborts by starting a big download and waiting a few minutes.
Sometimes the connections aborts during normal load. Installing the
latest firmware didn't help. The wifi works just fine with 4.13.3. While
investigating this I noticed a few messages in dmesg that only appear in
4.14-rc (I used 35dbba31be52):

> ath10k_pci 0000:3a:00.0: Direct firmware load for ath10k/pre-cal-pci-0000:3a:00.0.bin failed with error -2
> ath10k_pci 0000:3a:00.0: Direct firmware load for ath10k/cal-pci-0000:3a:00.0.bin failed with error -2

Do they have anything to do with this? Hardware is

> 3a:00.0 Network controller [0280]: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter [168c:003e] (rev 32)
Wifi Firmware:

> firmware ver WLAN.RM.4.4.1-00026-QCARMSWP-1 api 6 features wowlan,ignore-otp,raw-mode crc32 7b90c3fc
> board_file api 2 bmi_id N/A crc32 414716a3

Should I try to bisect this or is this issue already known? Side note
FYI: I also updated the BIOS of the XPS13 recently (but there is a newer
one available that I haven't installed yet) and switched to a newer
Fedora version, but that afaics hasn't anything to do with this, as 4.13
works just fine (famous last words...)

Ciao, Thorsten

P.S.: full dmesg output:
http://www.leemhuis.info/files/misc/dmesg-ath10k-problem-4.14-rc
Kernel config based on Fedora rawhide

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

Re: ath10k-regression in 4.14: Connections aborts with "failed to extract amsdu: -11"

[Ryan Hsu]

On 10/01/2017 01:59 AM, Thorsten Leemhuis wrote:

> Lo! The wifi connection of my Dell XPS13 (9360) with its QCA6174
> sometimes suddenly stops working since I switched to 4.14-rc2+. Every
> time it happens, there is this error message in dmesg:
>
>> ath10k_pci 0000:3a:00.0: failed to extract amsdu: -11
> I have to switch wifi off and on with the hotkey to reconnect. I can
> trigger the aborts by starting a big download and waiting a few minutes.
> Sometimes the connections aborts during normal load. Installing the
> latest firmware didn't help. The wifi works just fine with 4.13.3. While
> investigating this I noticed a few messages in dmesg that only appear in
> 4.14-rc (I used 35dbba31be52):

You do run the 4.13.3 v.s 4.14-rc with the same QCA6174 firmwrae, right?
Just want to understand the test setup here so that I could give it a try myself, and in 11ac or 11n mode you're testing?

>> ath10k_pci 0000:3a:00.0: Direct firmware load for ath10k/pre-cal-pci-0000:3a:00.0.bin failed with error -2
>> ath10k_pci 0000:3a:00.0: Direct firmware load for ath10k/cal-pci-0000:3a:00.0.bin failed with error -2
> Do they have anything to do with this? Hardware is

This error message is confusing since QCA6174 is not supporting pre-calibration feature, this reminds me that we need to clean this up.

>> 3a:00.0 Network controller [0280]: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter [168c:003e] (rev 32)
> Wifi Firmware:
>
>> firmware ver WLAN.RM.4.4.1-00026-QCARMSWP-1 api 6 features wowlan,ignore-otp,raw-mode crc32 7b90c3fc
>> board_file api 2 bmi_id N/A crc32 414716a3
> Should I try to bisect this or is this issue already known? Side note
> FYI: I also updated the BIOS of the XPS13 recently (but there is a newer
> one available that I haven't installed yet) and switched to a newer
> Fedora version, but that afaics hasn't anything to do with this, as 4.13
> works just fine (famous last words...)

I am not aware of this failure, so since you've setup that is easy to reproduce the case.
Would you mind do a bisect to locate the failure, please?

Also before you're trying to bisect the kernel change, can you also give it a try to roll back to older firmwares or move to the latest one *WLAN.RM.4.4.1-00051-QCARMSWP-1***to isolate if this is a firmware issue.

-- 
Ryan Hsu

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

ath10k-regression due to "ath10k: fix napi_poll budget overflow" c9353bf483d3 (Was: Re: ath10k-regression in 4.14: Connections aborts with "failed to extract amsdu: -11"

[Thorsten Leemhuis]

Lo! On 03.10.2017 01:40, Ryan Hsu wrote:
> On 10/01/2017 01:59 AM, Thorsten Leemhuis wrote:
>> Lo! The wifi connection of my Dell XPS13 (9360) with its QCA6174
>> sometimes suddenly stops working since I switched to 4.14-rc2+. Every
>> time it happens, there is this error message in dmesg:
>>> ath10k_pci 0000:3a:00.0: failed to extract amsdu: -11
>> I have to switch wifi off and on with the hotkey to reconnect. I can
>> trigger the aborts by starting a big download and waiting a few minutes.
>> Sometimes the connections aborts during normal load. Installing the
>> latest firmware didn't help. The wifi works just fine with 4.13.3. While
>> investigating this I noticed a few messages in dmesg that only appear in
>> 4.14-rc (I used 35dbba31be52):
> You do run the 4.13.3 v.s 4.14-rc with the same QCA6174 firmwrae, right?
> Just want to understand the test setup here so that I could give it a try myself, and in 11ac or 11n mode you're testing?

Yup, same firmware (reproduced it with
firmware-6.bin_WLAN.RM.4.4.1-00058-QCARMSWP-1 before bisecting). And the
problem showed up with 2g and 5g networks. But while investigating it I
noticed the problem does not show up with all wifi routers. It happens
with my Fritz!Box 6490 Cable and another Fritz!Box I tried, but not with
the wifi network at work (no idea what kind of routers are installed
there; I can try to find out if it matters).

>>> 3a:00.0 Network controller [0280]: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter [168c:003e] (rev 32)
> […] Would you mind do a bisect to locate the failure, please?

Did that yesterday and it turned out it's due to commit c9353bf483d3
(ath10k: fix napi_poll budget overflow). Reverting it on top of linux
master from yesterday made the wifi connection stable again for me.

Ciao, Thorsten

P.S.: For completeness: https://git.kernel.org/linus/c9353bf483d3

> commit c9353bf483d3724c116a9d502c0ead9cec54a61a (refs/bisect/bad)
> Author: Ryan Hsu <ryanhsu@qti.qualcomm.com>
> Date:   Tue Aug 22 14:44:02 2017 -0700
> 
>     ath10k: fix napi_poll budget overflow
>     
>     In napi_poll, the budget number is used to control the amount of packets
>     we should handle per poll to balance the resource in the system.
>     
>     In the list of the amsdu packets reception, we check if there is budget
>     count left and handle the complete list of the packets, that it will have
>     chances the very last list will over the budget leftover.
>     
>     So adding one more parameter - budget_left, this would help while
>     traversing the list to avoid handling more than the budget given.
>     
>     Reported-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
>     Fix-suggested-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
>     Link: https://lkml.kernel.org/r/26670dce-4dd2-f8e4-0e14-90d74257e739@virtuozzo.com
>     Signed-off-by: Ryan Hsu <ryanhsu@qti.qualcomm.com>
>     Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

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

Re: ath10k-regression due to "ath10k: fix napi_poll budget overflow" c9353bf483d3

[Rouven Czerwinski]

Hello,

here is my analysis of the problem:
Commit c9353bf483d3 plumps the budget down into the
ath10k_htt_rx_extract_amsdu function. Per extracted msdu frame the
budget is reduced by one until either we have no budget left or all
msdus are extracted from the amsdu. The function then checks whether all
frames were extracted, if not it returns -EAGAIN.

The error happens if we have to extract more frames then we have
budget_left, because not all frames are extracted and
ath10k_htt_rx_in_ord_ind enters this error path:

case -EAGAIN:
	/* fall through */
default:
	/* Should not happen. */
	ath10k_warn(ar, "failed to extract amsdu: %d\n", ret);
	htt->rx_confused = true;
	__skb_queue_purge(&list);
	return -EIO;

Which is not recoverable by the driver, only through hardware reset.

MfG
Rouven Czerwinski

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

Re: ath10k-regression due to "ath10k: fix napi_poll budget overflow" c9353bf483d3

[Kalle Valo]

+ linux-wireless

Thorsten Leemhuis <linux@leemhuis.info> writes:

> Lo! On 03.10.2017 01:40, Ryan Hsu wrote:
>> On 10/01/2017 01:59 AM, Thorsten Leemhuis wrote:
>>> Lo! The wifi connection of my Dell XPS13 (9360) with its QCA6174
>>> sometimes suddenly stops working since I switched to 4.14-rc2+. Every
>>> time it happens, there is this error message in dmesg:
>>>> ath10k_pci 0000:3a:00.0: failed to extract amsdu: -11
>>> I have to switch wifi off and on with the hotkey to reconnect. I can
>>> trigger the aborts by starting a big download and waiting a few minutes.
>>> Sometimes the connections aborts during normal load. Installing the
>>> latest firmware didn't help. The wifi works just fine with 4.13.3. While
>>> investigating this I noticed a few messages in dmesg that only appear in
>>> 4.14-rc (I used 35dbba31be52):
>> You do run the 4.13.3 v.s 4.14-rc with the same QCA6174 firmwrae, right?
>> Just want to understand the test setup here so that I could give it
>> a try myself, and in 11ac or 11n mode you're testing?
>
> Yup, same firmware (reproduced it with
> firmware-6.bin_WLAN.RM.4.4.1-00058-QCARMSWP-1 before bisecting). And the
> problem showed up with 2g and 5g networks. But while investigating it I
> noticed the problem does not show up with all wifi routers. It happens
> with my Fritz!Box 6490 Cable and another Fritz!Box I tried, but not with
> the wifi network at work (no idea what kind of routers are installed
> there; I can try to find out if it matters).
>
>>>> 3a:00.0 Network controller [0280]: Qualcomm Atheros QCA6174
>>>> 802.11ac Wireless Network Adapter [168c:003e] (rev 32)
>> […] Would you mind do a bisect to locate the failure, please?
>
> Did that yesterday and it turned out it's due to commit c9353bf483d3
> (ath10k: fix napi_poll budget overflow). Reverting it on top of linux
> master from yesterday made the wifi connection stable again for me.

Sorry, I have not been able to follow this discussion very closely but
was the conclusion? Should we should revert c9353bf483d3 for 4.14 or
what? I should still have time to do that, but not much.

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

Re: ath10k-regression due to "ath10k: fix napi_poll budget overflow" c9353bf483d3

[Kalle Valo]

KyBsaW51eC13aXJlbGVzcw0KDQpUaG9yc3RlbiBMZWVtaHVpcyA8bGludXhAbGVlbWh1aXMuaW5m
bz4gd3JpdGVzOg0KDQo+IExvISBPbiAwMy4xMC4yMDE3IDAxOjQwLCBSeWFuIEhzdSB3cm90ZToN
Cj4+IE9uIDEwLzAxLzIwMTcgMDE6NTkgQU0sIFRob3JzdGVuIExlZW1odWlzIHdyb3RlOg0KPj4+
IExvISBUaGUgd2lmaSBjb25uZWN0aW9uIG9mIG15IERlbGwgWFBTMTMgKDkzNjApIHdpdGggaXRz
IFFDQTYxNzQNCj4+PiBzb21ldGltZXMgc3VkZGVubHkgc3RvcHMgd29ya2luZyBzaW5jZSBJIHN3
aXRjaGVkIHRvIDQuMTQtcmMyKy4gRXZlcnkNCj4+PiB0aW1lIGl0IGhhcHBlbnMsIHRoZXJlIGlz
IHRoaXMgZXJyb3IgbWVzc2FnZSBpbiBkbWVzZzoNCj4+Pj4gYXRoMTBrX3BjaSAwMDAwOjNhOjAw
LjA6IGZhaWxlZCB0byBleHRyYWN0IGFtc2R1OiAtMTENCj4+PiBJIGhhdmUgdG8gc3dpdGNoIHdp
Zmkgb2ZmIGFuZCBvbiB3aXRoIHRoZSBob3RrZXkgdG8gcmVjb25uZWN0LiBJIGNhbg0KPj4+IHRy
aWdnZXIgdGhlIGFib3J0cyBieSBzdGFydGluZyBhIGJpZyBkb3dubG9hZCBhbmQgd2FpdGluZyBh
IGZldyBtaW51dGVzLg0KPj4+IFNvbWV0aW1lcyB0aGUgY29ubmVjdGlvbnMgYWJvcnRzIGR1cmlu
ZyBub3JtYWwgbG9hZC4gSW5zdGFsbGluZyB0aGUNCj4+PiBsYXRlc3QgZmlybXdhcmUgZGlkbid0
IGhlbHAuIFRoZSB3aWZpIHdvcmtzIGp1c3QgZmluZSB3aXRoIDQuMTMuMy4gV2hpbGUNCj4+PiBp
bnZlc3RpZ2F0aW5nIHRoaXMgSSBub3RpY2VkIGEgZmV3IG1lc3NhZ2VzIGluIGRtZXNnIHRoYXQg
b25seSBhcHBlYXIgaW4NCj4+PiA0LjE0LXJjIChJIHVzZWQgMzVkYmJhMzFiZTUyKToNCj4+IFlv
dSBkbyBydW4gdGhlIDQuMTMuMyB2LnMgNC4xNC1yYyB3aXRoIHRoZSBzYW1lIFFDQTYxNzQgZmly
bXdyYWUsIHJpZ2h0Pw0KPj4gSnVzdCB3YW50IHRvIHVuZGVyc3RhbmQgdGhlIHRlc3Qgc2V0dXAg
aGVyZSBzbyB0aGF0IEkgY291bGQgZ2l2ZSBpdA0KPj4gYSB0cnkgbXlzZWxmLCBhbmQgaW4gMTFh
YyBvciAxMW4gbW9kZSB5b3UncmUgdGVzdGluZz8NCj4NCj4gWXVwLCBzYW1lIGZpcm13YXJlIChy
ZXByb2R1Y2VkIGl0IHdpdGgNCj4gZmlybXdhcmUtNi5iaW5fV0xBTi5STS40LjQuMS0wMDA1OC1R
Q0FSTVNXUC0xIGJlZm9yZSBiaXNlY3RpbmcpLiBBbmQgdGhlDQo+IHByb2JsZW0gc2hvd2VkIHVw
IHdpdGggMmcgYW5kIDVnIG5ldHdvcmtzLiBCdXQgd2hpbGUgaW52ZXN0aWdhdGluZyBpdCBJDQo+
IG5vdGljZWQgdGhlIHByb2JsZW0gZG9lcyBub3Qgc2hvdyB1cCB3aXRoIGFsbCB3aWZpIHJvdXRl
cnMuIEl0IGhhcHBlbnMNCj4gd2l0aCBteSBGcml0eiFCb3ggNjQ5MCBDYWJsZSBhbmQgYW5vdGhl
ciBGcml0eiFCb3ggSSB0cmllZCwgYnV0IG5vdCB3aXRoDQo+IHRoZSB3aWZpIG5ldHdvcmsgYXQg
d29yayAobm8gaWRlYSB3aGF0IGtpbmQgb2Ygcm91dGVycyBhcmUgaW5zdGFsbGVkDQo+IHRoZXJl
OyBJIGNhbiB0cnkgdG8gZmluZCBvdXQgaWYgaXQgbWF0dGVycykuDQo+DQo+Pj4+IDNhOjAwLjAg
TmV0d29yayBjb250cm9sbGVyIFswMjgwXTogUXVhbGNvbW0gQXRoZXJvcyBRQ0E2MTc0DQo+Pj4+
IDgwMi4xMWFjIFdpcmVsZXNzIE5ldHdvcmsgQWRhcHRlciBbMTY4YzowMDNlXSAocmV2IDMyKQ0K
Pj4gW+KApl0gV291bGQgeW91IG1pbmQgZG8gYSBiaXNlY3QgdG8gbG9jYXRlIHRoZSBmYWlsdXJl
LCBwbGVhc2U/DQo+DQo+IERpZCB0aGF0IHllc3RlcmRheSBhbmQgaXQgdHVybmVkIG91dCBpdCdz
IGR1ZSB0byBjb21taXQgYzkzNTNiZjQ4M2QzDQo+IChhdGgxMGs6IGZpeCBuYXBpX3BvbGwgYnVk
Z2V0IG92ZXJmbG93KS4gUmV2ZXJ0aW5nIGl0IG9uIHRvcCBvZiBsaW51eA0KPiBtYXN0ZXIgZnJv
bSB5ZXN0ZXJkYXkgbWFkZSB0aGUgd2lmaSBjb25uZWN0aW9uIHN0YWJsZSBhZ2FpbiBmb3IgbWUu
DQoNClNvcnJ5LCBJIGhhdmUgbm90IGJlZW4gYWJsZSB0byBmb2xsb3cgdGhpcyBkaXNjdXNzaW9u
IHZlcnkgY2xvc2VseSBidXQNCndhcyB0aGUgY29uY2x1c2lvbj8gU2hvdWxkIHdlIHNob3VsZCBy
ZXZlcnQgYzkzNTNiZjQ4M2QzIGZvciA0LjE0IG9yDQp3aGF0PyBJIHNob3VsZCBzdGlsbCBoYXZl
IHRpbWUgdG8gZG8gdGhhdCwgYnV0IG5vdCBtdWNoLg0KDQotLSANCkthbGxlIFZhbG8=

Re: ath10k-regression due to "ath10k: fix napi_poll budget overflow" c9353bf483d3

[Ryan Hsu]

On 10/27/2017 02:40 AM, Kalle Valo wrote:

> + linux-wireless
>
> Sorry, I have not been able to follow this discussion very closely but
> was the conclusion? Should we should revert c9353bf483d3 for 4.14 or
> what? I should still have time to do that, but not much.

Kalle, I don't think I have enough time to look into the issue, since original change is to avoid the warning, but now is having regression.
Let's try to revert c9353bf483d3 for 4.14, and I'll look into this later.

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

Re: ath10k-regression due to "ath10k: fix napi_poll budget overflow" c9353bf483d3

[Ryan Hsu]

T24gMTAvMjcvMjAxNyAwMjo0MCBBTSwgS2FsbGUgVmFsbyB3cm90ZToNCg0KPiArIGxpbnV4LXdp
cmVsZXNzDQo+DQo+IFNvcnJ5LCBJIGhhdmUgbm90IGJlZW4gYWJsZSB0byBmb2xsb3cgdGhpcyBk
aXNjdXNzaW9uIHZlcnkgY2xvc2VseSBidXQNCj4gd2FzIHRoZSBjb25jbHVzaW9uPyBTaG91bGQg
d2Ugc2hvdWxkIHJldmVydCBjOTM1M2JmNDgzZDMgZm9yIDQuMTQgb3INCj4gd2hhdD8gSSBzaG91
bGQgc3RpbGwgaGF2ZSB0aW1lIHRvIGRvIHRoYXQsIGJ1dCBub3QgbXVjaC4NCg0KS2FsbGUsIEkg
ZG9uJ3QgdGhpbmsgSSBoYXZlIGVub3VnaCB0aW1lIHRvIGxvb2sgaW50byB0aGUgaXNzdWUsIHNp
bmNlIG9yaWdpbmFsIGNoYW5nZSBpcyB0byBhdm9pZCB0aGUgd2FybmluZywgYnV0IG5vdyBpcyBo
YXZpbmcgcmVncmVzc2lvbi4NCkxldCdzIHRyeSB0byByZXZlcnQgYzkzNTNiZjQ4M2QzIGZvciA0
LjE0LCBhbmQgSSdsbCBsb29rIGludG8gdGhpcyBsYXRlci4NCg0KLS0gDQpSeWFuIEhzdQ0K

Re: ath10k-regression due to "ath10k: fix napi_poll budget overflow" c9353bf483d3

[Kalle Valo]

Ryan Hsu <ryanhsu@qti.qualcomm.com> writes:

> On 10/27/2017 02:40 AM, Kalle Valo wrote:
>
>> + linux-wireless
>>
>> Sorry, I have not been able to follow this discussion very closely but
>> was the conclusion? Should we should revert c9353bf483d3 for 4.14 or
>> what? I should still have time to do that, but not much.
>
> Kalle, I don't think I have enough time to look into the issue, since
> original change is to avoid the warning, but now is having regression.
> Let's try to revert c9353bf483d3 for 4.14, and I'll look into this later.

Great, thanks Ryan.

I now submitted the revert and I'll try to get it to 4.14:

https://patchwork.kernel.org/patch/10031233/

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

Re: ath10k-regression due to "ath10k: fix napi_poll budget overflow" c9353bf483d3

[Kalle Valo]

Ryan Hsu <ryanhsu@qti.qualcomm.com> writes:

> On 10/27/2017 02:40 AM, Kalle Valo wrote:
>
>> + linux-wireless
>>
>> Sorry, I have not been able to follow this discussion very closely but
>> was the conclusion? Should we should revert c9353bf483d3 for 4.14 or
>> what? I should still have time to do that, but not much.
>
> Kalle, I don't think I have enough time to look into the issue, since
> original change is to avoid the warning, but now is having regression.
> Let's try to revert c9353bf483d3 for 4.14, and I'll look into this later.

Great, thanks Ryan.

I now submitted the revert and I'll try to get it to 4.14:

https://patchwork.kernel.org/patch/10031233/

--=20
Kalle Valo=

Re: ath10k-regression due to "ath10k: fix napi_poll budget overflow" c9353bf483d3

[Thorsten Leemhuis]

Lo! On 29.10.2017 08:44, Kalle Valo wrote:
> Ryan Hsu <ryanhsu@qti.qualcomm.com> writes:
>> On 10/27/2017 02:40 AM, Kalle Valo wrote:
>>
>>> + linux-wireless
>>> Sorry, I have not been able to follow this discussion very closely but
>>> was the conclusion? Should we should revert c9353bf483d3 for 4.14 or
>>> what? I should still have time to do that, but not much.
>> Kalle, I don't think I have enough time to look into the issue, since
>> original change is to avoid the warning, but now is having regression.
>> Let's try to revert c9353bf483d3 for 4.14, and I'll look into this later.
> 
> Great, thanks Ryan.
> I now submitted the revert and I'll try to get it to 4.14:
> https://patchwork.kernel.org/patch/10031233/

Sorry, I'm a bit behind with my mail after lot's of work@work and some
travelling right after that.

Ryan, Kalle: Thx for taking care of this. If you sooner or later want me
to test patches that try to solve the warning without causing this
regression simply drop me a line. Ciao, Thorsten



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

Re: ath10k-regression due to "ath10k: fix napi_poll budget overflow" c9353bf483d3

[Thorsten Leemhuis]

Lo! On 29.10.2017 08:44, Kalle Valo wrote:
> Ryan Hsu <ryanhsu@qti.qualcomm.com> writes:
>> On 10/27/2017 02:40 AM, Kalle Valo wrote:
>>
>>> + linux-wireless
>>> Sorry, I have not been able to follow this discussion very closely but
>>> was the conclusion? Should we should revert c9353bf483d3 for 4.14 or
>>> what? I should still have time to do that, but not much.
>> Kalle, I don't think I have enough time to look into the issue, since
>> original change is to avoid the warning, but now is having regression.
>> Let's try to revert c9353bf483d3 for 4.14, and I'll look into this later.
> 
> Great, thanks Ryan.
> I now submitted the revert and I'll try to get it to 4.14:
> https://patchwork.kernel.org/patch/10031233/

Sorry, I'm a bit behind with my mail after lot's of work@work and some
travelling right after that.

Ryan, Kalle: Thx for taking care of this. If you sooner or later want me
to test patches that try to solve the warning without causing this
regression simply drop me a line. Ciao, Thorsten

Wifi slow on the XPS13 (9360) (QCA6174) (Was Re: ath10k-regression in 4.14: Connections aborts with "failed to extract amsdu: -11")

[Thorsten Leemhuis]

Lo! Splitting this thread to focus on a issue that has nothing to do
with the regression in 4.14 I reported:

On 03.10.2017 01:40, Ryan Hsu wrote:
> On 10/01/2017 01:59 AM, Thorsten Leemhuis wrote:
>>> ath10k_pci 0000:3a:00.0: Direct firmware load for ath10k/pre-cal-pci-0000:3a:00.0.bin failed with error -2
>>> ath10k_pci 0000:3a:00.0: Direct firmware load for ath10k/cal-pci-0000:3a:00.0.bin failed with error -2
>> Do they have anything to do with this? Hardware is
> This error message is confusing since QCA6174 is not supporting
> pre-calibration feature, this reminds me that we need to clean this up.

I guess that would be good to avoid confusion. But while at it: If you
have a minute, could you please explain to me how to properly set up the
wifi firmware files for my Dell XPS13 (9360)? The reasons why I'm
asking: Sending data via wifi is really slow on my laptop (scp copies
only get 2 to 5 MByte/s on networks that are known to be a lot faster).
I wonder if the firmware files or the calibration data is part of the
reason wifi Tx is slow. The machine is normally shipped with a slightly
enhanced Ubuntu 16.04. That among others contains a package with the
machine specific files board.bin and board-2.bin that replace the files
normally installed in /lib/firmware/ath10k/QCA6174/hw3.0/ Are those
machine specific files crucial to have or are the one from the
linux-firmware repo good enoguh? I'm using Fedora and could copy the
ones from Ubuntu over, but obviously they will get overwritten every
time Fedora ships a new linux-firmware package – IOW: every few weeks :-/

Side note: You find a lot of reports about slow wifi is you search the
net with terms like "9360 wifi slow linux". Ubuntu fixed that a few
months ago with this patch:
http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/commit/?id=9690f19f07fee2acb2b04ea5eaa5db184ee175d5

Some bugs about this:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1692836
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1670041

But from what I gathered by searching the net and asking on #ath10k I
got the impression that patch is a massive ugly hack and no way
acceptable upstream.  Is that correct? If yes: is there maybe a proper
fix out there somewhere?

Ciao, Thorsten

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

ath10k: Wifi slow on the XPS13 (9360) (QCA6174)

[Kalle Valo]

+ linux-wireless and cleaning the subject

Hi Thorsten,

sorry for the late reply, I'm having problems keeping up with all the
email. I just do a quick reply now to point out that you are talking
about two different problems. To keep the discussion simple I recommend
keeping the two issues complete separate.

Thorsten Leemhuis <linux@leemhuis.info> writes:

> Lo! Splitting this thread to focus on a issue that has nothing to do
> with the regression in 4.14 I reported:
>
> On 03.10.2017 01:40, Ryan Hsu wrote:
>> On 10/01/2017 01:59 AM, Thorsten Leemhuis wrote:
>>>> ath10k_pci 0000:3a:00.0: Direct firmware load for
>>>> ath10k/pre-cal-pci-0000:3a:00.0.bin failed with error -2
>>>> ath10k_pci 0000:3a:00.0: Direct firmware load for
>>>> ath10k/cal-pci-0000:3a:00.0.bin failed with error -2
>>> Do they have anything to do with this? Hardware is
>> This error message is confusing since QCA6174 is not supporting
>> pre-calibration feature, this reminds me that we need to clean this up.
>
> I guess that would be good to avoid confusion. But while at it: If you
> have a minute, could you please explain to me how to properly set up the
> wifi firmware files for my Dell XPS13 (9360)? The reasons why I'm
> asking: Sending data via wifi is really slow on my laptop (scp copies
> only get 2 to 5 MByte/s on networks that are known to be a lot faster).
> I wonder if the firmware files or the calibration data is part of the
> reason wifi Tx is slow. The machine is normally shipped with a slightly
> enhanced Ubuntu 16.04. That among others contains a package with the
> machine specific files board.bin and board-2.bin that replace the files
> normally installed in /lib/firmware/ath10k/QCA6174/hw3.0/ Are those
> machine specific files crucial to have or are the one from the
> linux-firmware repo good enoguh? I'm using Fedora and could copy the
> ones from Ubuntu over, but obviously they will get overwritten every
> time Fedora ships a new linux-firmware package – IOW: every few weeks :-/

Yes, the board file can affect throughtput, _both_ TCP and UDP. I don't
know what board files Ubuntu is shipping but we should try to get those
into upstream.

> Side note: You find a lot of reports about slow wifi is you search the
> net with terms like "9360 wifi slow linux". Ubuntu fixed that a few
> months ago with this patch:
> http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/commit/?id=9690f19f07fee2acb2b04ea5eaa5db184ee175d5
>
> Some bugs about this:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1692836
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1670041

But this again about interraction between ath10k and TCP stack. And it
_only_ affects TCP, UDP should be unaffected. So whenever testing
throughput please always measure both TCP and UDP because then it's
easier to pinpoint the reason.

> But from what I gathered by searching the net and asking on #ath10k I
> got the impression that patch is a massive ugly hack and no way
> acceptable upstream.  Is that correct?

Yes, it's a horrible hack and I cannot apply that. And like you said
#1692836, also Eric Dumazet (one of TCP maintainers) agrees with that.

> If yes: is there maybe a proper fix out there somewhere?

Unfortunately there still is no good solution. In a week there's Netdev
2.2 and we have Linux Wireless summit there. We should bring up this
topic there.

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

ath10k: Wifi slow on the XPS13 (9360) (QCA6174)

[Kalle Valo]

KyBsaW51eC13aXJlbGVzcyBhbmQgY2xlYW5pbmcgdGhlIHN1YmplY3QNCg0KSGkgVGhvcnN0ZW4s
DQoNCnNvcnJ5IGZvciB0aGUgbGF0ZSByZXBseSwgSSdtIGhhdmluZyBwcm9ibGVtcyBrZWVwaW5n
IHVwIHdpdGggYWxsIHRoZQ0KZW1haWwuIEkganVzdCBkbyBhIHF1aWNrIHJlcGx5IG5vdyB0byBw
b2ludCBvdXQgdGhhdCB5b3UgYXJlIHRhbGtpbmcNCmFib3V0IHR3byBkaWZmZXJlbnQgcHJvYmxl
bXMuIFRvIGtlZXAgdGhlIGRpc2N1c3Npb24gc2ltcGxlIEkgcmVjb21tZW5kDQprZWVwaW5nIHRo
ZSB0d28gaXNzdWVzIGNvbXBsZXRlIHNlcGFyYXRlLg0KDQpUaG9yc3RlbiBMZWVtaHVpcyA8bGlu
dXhAbGVlbWh1aXMuaW5mbz4gd3JpdGVzOg0KDQo+IExvISBTcGxpdHRpbmcgdGhpcyB0aHJlYWQg
dG8gZm9jdXMgb24gYSBpc3N1ZSB0aGF0IGhhcyBub3RoaW5nIHRvIGRvDQo+IHdpdGggdGhlIHJl
Z3Jlc3Npb24gaW4gNC4xNCBJIHJlcG9ydGVkOg0KPg0KPiBPbiAwMy4xMC4yMDE3IDAxOjQwLCBS
eWFuIEhzdSB3cm90ZToNCj4+IE9uIDEwLzAxLzIwMTcgMDE6NTkgQU0sIFRob3JzdGVuIExlZW1o
dWlzIHdyb3RlOg0KPj4+PiBhdGgxMGtfcGNpIDAwMDA6M2E6MDAuMDogRGlyZWN0IGZpcm13YXJl
IGxvYWQgZm9yDQo+Pj4+IGF0aDEway9wcmUtY2FsLXBjaS0wMDAwOjNhOjAwLjAuYmluIGZhaWxl
ZCB3aXRoIGVycm9yIC0yDQo+Pj4+IGF0aDEwa19wY2kgMDAwMDozYTowMC4wOiBEaXJlY3QgZmly
bXdhcmUgbG9hZCBmb3INCj4+Pj4gYXRoMTBrL2NhbC1wY2ktMDAwMDozYTowMC4wLmJpbiBmYWls
ZWQgd2l0aCBlcnJvciAtMg0KPj4+IERvIHRoZXkgaGF2ZSBhbnl0aGluZyB0byBkbyB3aXRoIHRo
aXM/IEhhcmR3YXJlIGlzDQo+PiBUaGlzIGVycm9yIG1lc3NhZ2UgaXMgY29uZnVzaW5nIHNpbmNl
IFFDQTYxNzQgaXMgbm90IHN1cHBvcnRpbmcNCj4+IHByZS1jYWxpYnJhdGlvbiBmZWF0dXJlLCB0
aGlzIHJlbWluZHMgbWUgdGhhdCB3ZSBuZWVkIHRvIGNsZWFuIHRoaXMgdXAuDQo+DQo+IEkgZ3Vl
c3MgdGhhdCB3b3VsZCBiZSBnb29kIHRvIGF2b2lkIGNvbmZ1c2lvbi4gQnV0IHdoaWxlIGF0IGl0
OiBJZiB5b3UNCj4gaGF2ZSBhIG1pbnV0ZSwgY291bGQgeW91IHBsZWFzZSBleHBsYWluIHRvIG1l
IGhvdyB0byBwcm9wZXJseSBzZXQgdXAgdGhlDQo+IHdpZmkgZmlybXdhcmUgZmlsZXMgZm9yIG15
IERlbGwgWFBTMTMgKDkzNjApPyBUaGUgcmVhc29ucyB3aHkgSSdtDQo+IGFza2luZzogU2VuZGlu
ZyBkYXRhIHZpYSB3aWZpIGlzIHJlYWxseSBzbG93IG9uIG15IGxhcHRvcCAoc2NwIGNvcGllcw0K
PiBvbmx5IGdldCAyIHRvIDUgTUJ5dGUvcyBvbiBuZXR3b3JrcyB0aGF0IGFyZSBrbm93biB0byBi
ZSBhIGxvdCBmYXN0ZXIpLg0KPiBJIHdvbmRlciBpZiB0aGUgZmlybXdhcmUgZmlsZXMgb3IgdGhl
IGNhbGlicmF0aW9uIGRhdGEgaXMgcGFydCBvZiB0aGUNCj4gcmVhc29uIHdpZmkgVHggaXMgc2xv
dy4gVGhlIG1hY2hpbmUgaXMgbm9ybWFsbHkgc2hpcHBlZCB3aXRoIGEgc2xpZ2h0bHkNCj4gZW5o
YW5jZWQgVWJ1bnR1IDE2LjA0LiBUaGF0IGFtb25nIG90aGVycyBjb250YWlucyBhIHBhY2thZ2Ug
d2l0aCB0aGUNCj4gbWFjaGluZSBzcGVjaWZpYyBmaWxlcyBib2FyZC5iaW4gYW5kIGJvYXJkLTIu
YmluIHRoYXQgcmVwbGFjZSB0aGUgZmlsZXMNCj4gbm9ybWFsbHkgaW5zdGFsbGVkIGluIC9saWIv
ZmlybXdhcmUvYXRoMTBrL1FDQTYxNzQvaHczLjAvIEFyZSB0aG9zZQ0KPiBtYWNoaW5lIHNwZWNp
ZmljIGZpbGVzIGNydWNpYWwgdG8gaGF2ZSBvciBhcmUgdGhlIG9uZSBmcm9tIHRoZQ0KPiBsaW51
eC1maXJtd2FyZSByZXBvIGdvb2QgZW5vZ3VoPyBJJ20gdXNpbmcgRmVkb3JhIGFuZCBjb3VsZCBj
b3B5IHRoZQ0KPiBvbmVzIGZyb20gVWJ1bnR1IG92ZXIsIGJ1dCBvYnZpb3VzbHkgdGhleSB3aWxs
IGdldCBvdmVyd3JpdHRlbiBldmVyeQ0KPiB0aW1lIEZlZG9yYSBzaGlwcyBhIG5ldyBsaW51eC1m
aXJtd2FyZSBwYWNrYWdlIOKAkyBJT1c6IGV2ZXJ5IGZldyB3ZWVrcyA6LS8NCg0KWWVzLCB0aGUg
Ym9hcmQgZmlsZSBjYW4gYWZmZWN0IHRocm91Z2h0cHV0LCBfYm90aF8gVENQIGFuZCBVRFAuIEkg
ZG9uJ3QNCmtub3cgd2hhdCBib2FyZCBmaWxlcyBVYnVudHUgaXMgc2hpcHBpbmcgYnV0IHdlIHNo
b3VsZCB0cnkgdG8gZ2V0IHRob3NlDQppbnRvIHVwc3RyZWFtLg0KDQo+IFNpZGUgbm90ZTogWW91
IGZpbmQgYSBsb3Qgb2YgcmVwb3J0cyBhYm91dCBzbG93IHdpZmkgaXMgeW91IHNlYXJjaCB0aGUN
Cj4gbmV0IHdpdGggdGVybXMgbGlrZSAiOTM2MCB3aWZpIHNsb3cgbGludXgiLiBVYnVudHUgZml4
ZWQgdGhhdCBhIGZldw0KPiBtb250aHMgYWdvIHdpdGggdGhpcyBwYXRjaDoNCj4gaHR0cDovL2tl
cm5lbC51YnVudHUuY29tL2dpdC91YnVudHUvdWJ1bnR1LXhlbmlhbC5naXQvY29tbWl0Lz9pZD05
NjkwZjE5ZjA3ZmVlMmFjYjJiMDRlYTVlYWE1ZGIxODRlZTE3NWQ1DQo+DQo+IFNvbWUgYnVncyBh
Ym91dCB0aGlzOg0KPiBodHRwczovL2J1Z3MubGF1bmNocGFkLm5ldC91YnVudHUvK3NvdXJjZS9s
aW51eC8rYnVnLzE2OTI4MzYNCj4gaHR0cHM6Ly9idWdzLmxhdW5jaHBhZC5uZXQvdWJ1bnR1Lytz
b3VyY2UvbGludXgvK2J1Zy8xNjcwMDQxDQoNCkJ1dCB0aGlzIGFnYWluIGFib3V0IGludGVycmFj
dGlvbiBiZXR3ZWVuIGF0aDEwayBhbmQgVENQIHN0YWNrLiBBbmQgaXQNCl9vbmx5XyBhZmZlY3Rz
IFRDUCwgVURQIHNob3VsZCBiZSB1bmFmZmVjdGVkLiBTbyB3aGVuZXZlciB0ZXN0aW5nDQp0aHJv
dWdocHV0IHBsZWFzZSBhbHdheXMgbWVhc3VyZSBib3RoIFRDUCBhbmQgVURQIGJlY2F1c2UgdGhl
biBpdCdzDQplYXNpZXIgdG8gcGlucG9pbnQgdGhlIHJlYXNvbi4NCg0KPiBCdXQgZnJvbSB3aGF0
IEkgZ2F0aGVyZWQgYnkgc2VhcmNoaW5nIHRoZSBuZXQgYW5kIGFza2luZyBvbiAjYXRoMTBrIEkN
Cj4gZ290IHRoZSBpbXByZXNzaW9uIHRoYXQgcGF0Y2ggaXMgYSBtYXNzaXZlIHVnbHkgaGFjayBh
bmQgbm8gd2F5DQo+IGFjY2VwdGFibGUgdXBzdHJlYW0uICBJcyB0aGF0IGNvcnJlY3Q/DQoNClll
cywgaXQncyBhIGhvcnJpYmxlIGhhY2sgYW5kIEkgY2Fubm90IGFwcGx5IHRoYXQuIEFuZCBsaWtl
IHlvdSBzYWlkDQojMTY5MjgzNiwgYWxzbyBFcmljIER1bWF6ZXQgKG9uZSBvZiBUQ1AgbWFpbnRh
aW5lcnMpIGFncmVlcyB3aXRoIHRoYXQuDQoNCj4gSWYgeWVzOiBpcyB0aGVyZSBtYXliZSBhIHBy
b3BlciBmaXggb3V0IHRoZXJlIHNvbWV3aGVyZT8NCg0KVW5mb3J0dW5hdGVseSB0aGVyZSBzdGls
bCBpcyBubyBnb29kIHNvbHV0aW9uLiBJbiBhIHdlZWsgdGhlcmUncyBOZXRkZXYNCjIuMiBhbmQg
d2UgaGF2ZSBMaW51eCBXaXJlbGVzcyBzdW1taXQgdGhlcmUuIFdlIHNob3VsZCBicmluZyB1cCB0
aGlzDQp0b3BpYyB0aGVyZS4NCg0KLS0gDQpLYWxsZSBWYWxv

Re: ath10k: Wifi slow on the XPS13 (9360) (QCA6174)

[Thorsten Leemhuis]

Lo! On 29.10.2017 08:27, Kalle Valo wrote:
> [..]
> sorry for the late reply, I'm having problems keeping up with all the
> email. 

No worries, this problem is nothing new, I just thought it might be good
to finally bring this to ath10k, as I got the impressions it had not
gotten proper attention there yet.

> Thorsten Leemhuis <linux@leemhuis.info> writes:
>> On 03.10.2017 01:40, Ryan Hsu wrote:
>>> On 10/01/2017 01:59 AM, Thorsten Leemhuis wrote:
>>>>> ath10k_pci 0000:3a:00.0: Direct firmware load for
>>>>> ath10k/pre-cal-pci-0000:3a:00.0.bin failed with error -2
>>>>> ath10k_pci 0000:3a:00.0: Direct firmware load for
>>>>> ath10k/cal-pci-0000:3a:00.0.bin failed with error -2
>>>> Do they have anything to do with this? Hardware is
>>> This error message is confusing since QCA6174 is not supporting
>>> pre-calibration feature, this reminds me that we need to clean this up.
>> I guess that would be good to avoid confusion. But while at it: If you
>> have a minute, could you please explain to me how to properly set up the
>> wifi firmware files for my Dell XPS13 (9360)? The reasons why I'm
>> asking: Sending data via wifi is really slow on my laptop (scp copies
>> only get 2 to 5 MByte/s on networks that are known to be a lot faster).
>> I wonder if the firmware files or the calibration data is part of the
>> reason wifi Tx is slow. The machine is normally shipped with a slightly
>> enhanced Ubuntu 16.04. That among others contains a package with the
>> machine specific files board.bin and board-2.bin that replace the files
>> normally installed in /lib/firmware/ath10k/QCA6174/hw3.0/ Are those
>> machine specific files crucial to have or are the one from the
>> linux-firmware repo good enoguh? I'm using Fedora and could copy the
>> ones from Ubuntu over, but obviously they will get overwritten every
>> time Fedora ships a new linux-firmware package – IOW: every few weeks :-/
> Yes, the board file can affect throughtput, _both_ TCP and UDP. I don't
> know what board files Ubuntu is shipping but we should try to get those
> into upstream.

Out of curiosity (don't spend time answering this is you are busy): Is
there even a mechanism for this? Kind of "take
firmwaredir/board-Dell_Inc.-XPS_13_9360.bin if it exists and
firmwaredir/board.bin otherwise? Or can one file serve all machines?

>> Side note: You find a lot of reports about slow wifi is you search the
>> net with terms like "9360 wifi slow linux". Ubuntu fixed that a few
>> months ago with this patch:
>> http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/commit/?id=9690f19f07fee2acb2b04ea5eaa5db184ee175d5
>> Some bugs about this:
>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1692836
>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1670041
> But this again about interraction between ath10k and TCP stack. And it
> _only_ affects TCP, UDP should be unaffected.

Ahh, sorry, missed that. Seems I didn't properly read the second
launchpad link above. Sorry.

> So whenever testing
> throughput please always measure both TCP and UDP because then it's
> easier to pinpoint the reason.

Is there any data I could provide that might help getting this soled
once and for all?

>> But from what I gathered by searching the net and asking on #ath10k I
>> got the impression that patch is a massive ugly hack and no way
>> acceptable upstream.  Is that correct?
> Yes, it's a horrible hack and I cannot apply that. And like you said
> #1692836, also Eric Dumazet (one of TCP maintainers) agrees with that
Ahh, had missed that, sorry.

>> If yes: is there maybe a proper fix out there somewhere?
> Unfortunately there still is no good solution. In a week there's Netdev
> 2.2 and we have Linux Wireless summit there. We should bring up this
> topic there.

Thx for picking this up, much appreciated! Ciao, Thorsten

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

Re: ath10k: Wifi slow on the XPS13 (9360) (QCA6174)

[Thorsten Leemhuis]

Lo! On 29.10.2017 08:27, Kalle Valo wrote:
> [..]
> sorry for the late reply, I'm having problems keeping up with all the
> email. 

No worries, this problem is nothing new, I just thought it might be good
to finally bring this to ath10k, as I got the impressions it had not
gotten proper attention there yet.

> Thorsten Leemhuis <linux@leemhuis.info> writes:
>> On 03.10.2017 01:40, Ryan Hsu wrote:
>>> On 10/01/2017 01:59 AM, Thorsten Leemhuis wrote:
>>>>> ath10k_pci 0000:3a:00.0: Direct firmware load for
>>>>> ath10k/pre-cal-pci-0000:3a:00.0.bin failed with error -2
>>>>> ath10k_pci 0000:3a:00.0: Direct firmware load for
>>>>> ath10k/cal-pci-0000:3a:00.0.bin failed with error -2
>>>> Do they have anything to do with this? Hardware is
>>> This error message is confusing since QCA6174 is not supporting
>>> pre-calibration feature, this reminds me that we need to clean this up.
>> I guess that would be good to avoid confusion. But while at it: If you
>> have a minute, could you please explain to me how to properly set up the
>> wifi firmware files for my Dell XPS13 (9360)? The reasons why I'm
>> asking: Sending data via wifi is really slow on my laptop (scp copies
>> only get 2 to 5 MByte/s on networks that are known to be a lot faster).
>> I wonder if the firmware files or the calibration data is part of the
>> reason wifi Tx is slow. The machine is normally shipped with a slightly
>> enhanced Ubuntu 16.04. That among others contains a package with the
>> machine specific files board.bin and board-2.bin that replace the files
>> normally installed in /lib/firmware/ath10k/QCA6174/hw3.0/ Are those
>> machine specific files crucial to have or are the one from the
>> linux-firmware repo good enoguh? I'm using Fedora and could copy the
>> ones from Ubuntu over, but obviously they will get overwritten every
>> time Fedora ships a new linux-firmware package – IOW: every few weeks :-/
> Yes, the board file can affect throughtput, _both_ TCP and UDP. I don't
> know what board files Ubuntu is shipping but we should try to get those
> into upstream.

Out of curiosity (don't spend time answering this is you are busy): Is
there even a mechanism for this? Kind of "take
firmwaredir/board-Dell_Inc.-XPS_13_9360.bin if it exists and
firmwaredir/board.bin otherwise? Or can one file serve all machines?

>> Side note: You find a lot of reports about slow wifi is you search the
>> net with terms like "9360 wifi slow linux". Ubuntu fixed that a few
>> months ago with this patch:
>> http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/commit/?id=9690f19f07fee2acb2b04ea5eaa5db184ee175d5
>> Some bugs about this:
>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1692836
>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1670041
> But this again about interraction between ath10k and TCP stack. And it
> _only_ affects TCP, UDP should be unaffected.

Ahh, sorry, missed that. Seems I didn't properly read the second
launchpad link above. Sorry.

> So whenever testing
> throughput please always measure both TCP and UDP because then it's
> easier to pinpoint the reason.

Is there any data I could provide that might help getting this soled
once and for all?

>> But from what I gathered by searching the net and asking on #ath10k I
>> got the impression that patch is a massive ugly hack and no way
>> acceptable upstream.  Is that correct?
> Yes, it's a horrible hack and I cannot apply that. And like you said
> #1692836, also Eric Dumazet (one of TCP maintainers) agrees with that
Ahh, had missed that, sorry.

>> If yes: is there maybe a proper fix out there somewhere?
> Unfortunately there still is no good solution. In a week there's Netdev
> 2.2 and we have Linux Wireless summit there. We should bring up this
> topic there.

Thx for picking this up, much appreciated! Ciao, Thorsten

Re: ath10k: Wifi slow on the XPS13 (9360) (QCA6174)

[Kalle Valo]

Thorsten Leemhuis <linux@leemhuis.info> writes:

> Lo! On 29.10.2017 08:27, Kalle Valo wrote:
>> Thorsten Leemhuis <linux@leemhuis.info> writes:
>>> On 03.10.2017 01:40, Ryan Hsu wrote:
>>>> On 10/01/2017 01:59 AM, Thorsten Leemhuis wrote:
>>>>>> ath10k_pci 0000:3a:00.0: Direct firmware load for
>>>>>> ath10k/pre-cal-pci-0000:3a:00.0.bin failed with error -2
>>>>>> ath10k_pci 0000:3a:00.0: Direct firmware load for
>>>>>> ath10k/cal-pci-0000:3a:00.0.bin failed with error -2
>>>>> Do they have anything to do with this? Hardware is
>>>> This error message is confusing since QCA6174 is not supporting
>>>> pre-calibration feature, this reminds me that we need to clean this up.
>>> I guess that would be good to avoid confusion. But while at it: If you
>>> have a minute, could you please explain to me how to properly set up the
>>> wifi firmware files for my Dell XPS13 (9360)? The reasons why I'm
>>> asking: Sending data via wifi is really slow on my laptop (scp copies
>>> only get 2 to 5 MByte/s on networks that are known to be a lot faster).
>>> I wonder if the firmware files or the calibration data is part of the
>>> reason wifi Tx is slow. The machine is normally shipped with a slightly
>>> enhanced Ubuntu 16.04. That among others contains a package with the
>>> machine specific files board.bin and board-2.bin that replace the files
>>> normally installed in /lib/firmware/ath10k/QCA6174/hw3.0/ Are those
>>> machine specific files crucial to have or are the one from the
>>> linux-firmware repo good enoguh? I'm using Fedora and could copy the
>>> ones from Ubuntu over, but obviously they will get overwritten every
>>> time Fedora ships a new linux-firmware package – IOW: every few weeks :-/
>> Yes, the board file can affect throughtput, _both_ TCP and UDP. I don't
>> know what board files Ubuntu is shipping but we should try to get those
>> into upstream.
>
> Out of curiosity (don't spend time answering this is you are busy): Is
> there even a mechanism for this? Kind of "take
> firmwaredir/board-Dell_Inc.-XPS_13_9360.bin if it exists and
> firmwaredir/board.bin otherwise? Or can one file serve all machines?

Just to a quick short answer:

board.bin contains just one board file but board-2.bin is in practise a
container format which has multiple board files (or "images"). Each
image has a name associated to it which ath10k uses to find the correct
image. Example:

bus=pci,vendor=168c,device=003e,subsystem-vendor=144d,subsystem-device=c14f,variant=K

So yes, we have infrastructure ready to provide multiple board files.
But usually the challenge is how to make ath10k correctly detect what
board file a particular system needs.

>>> Side note: You find a lot of reports about slow wifi is you search the
>>> net with terms like "9360 wifi slow linux". Ubuntu fixed that a few
>>> months ago with this patch:
>>> http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/commit/?id=9690f19f07fee2acb2b04ea5eaa5db184ee175d5
>>> Some bugs about this:
>>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1692836
>>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1670041
>> But this again about interraction between ath10k and TCP stack. And it
>> _only_ affects TCP, UDP should be unaffected.
>
> Ahh, sorry, missed that. Seems I didn't properly read the second
> launchpad link above. Sorry.
>
>> So whenever testing
>> throughput please always measure both TCP and UDP because then it's
>> easier to pinpoint the reason.
>
> Is there any data I could provide that might help getting this soled
> once and for all?

With "this" you mean TCP transmit throughput problem with ath10k? I
don't think there's any easy solution, we just need to start a serious
discussion with the TCP maintainers how to solve this. IIRC ath10k
didn't have this problem until something changed in the TCP stack, so in
theory this could be classified as a regression in the TCP stack. But
I'm not sure about that and need to check the history.

But what would be helpful to have a detailed summary of the issue,
pointers to past discussions and identify the TCP commit which started
all this etc. I'll try to do that before the Netdev 2.2 but let's see if
I can make it. Help with that is really welcome.

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

Re: ath10k: Wifi slow on the XPS13 (9360) (QCA6174)

[Kalle Valo]

VGhvcnN0ZW4gTGVlbWh1aXMgPGxpbnV4QGxlZW1odWlzLmluZm8+IHdyaXRlczoNCg0KPiBMbyEg
T24gMjkuMTAuMjAxNyAwODoyNywgS2FsbGUgVmFsbyB3cm90ZToNCj4+IFRob3JzdGVuIExlZW1o
dWlzIDxsaW51eEBsZWVtaHVpcy5pbmZvPiB3cml0ZXM6DQo+Pj4gT24gMDMuMTAuMjAxNyAwMTo0
MCwgUnlhbiBIc3Ugd3JvdGU6DQo+Pj4+IE9uIDEwLzAxLzIwMTcgMDE6NTkgQU0sIFRob3JzdGVu
IExlZW1odWlzIHdyb3RlOg0KPj4+Pj4+IGF0aDEwa19wY2kgMDAwMDozYTowMC4wOiBEaXJlY3Qg
ZmlybXdhcmUgbG9hZCBmb3INCj4+Pj4+PiBhdGgxMGsvcHJlLWNhbC1wY2ktMDAwMDozYTowMC4w
LmJpbiBmYWlsZWQgd2l0aCBlcnJvciAtMg0KPj4+Pj4+IGF0aDEwa19wY2kgMDAwMDozYTowMC4w
OiBEaXJlY3QgZmlybXdhcmUgbG9hZCBmb3INCj4+Pj4+PiBhdGgxMGsvY2FsLXBjaS0wMDAwOjNh
OjAwLjAuYmluIGZhaWxlZCB3aXRoIGVycm9yIC0yDQo+Pj4+PiBEbyB0aGV5IGhhdmUgYW55dGhp
bmcgdG8gZG8gd2l0aCB0aGlzPyBIYXJkd2FyZSBpcw0KPj4+PiBUaGlzIGVycm9yIG1lc3NhZ2Ug
aXMgY29uZnVzaW5nIHNpbmNlIFFDQTYxNzQgaXMgbm90IHN1cHBvcnRpbmcNCj4+Pj4gcHJlLWNh
bGlicmF0aW9uIGZlYXR1cmUsIHRoaXMgcmVtaW5kcyBtZSB0aGF0IHdlIG5lZWQgdG8gY2xlYW4g
dGhpcyB1cC4NCj4+PiBJIGd1ZXNzIHRoYXQgd291bGQgYmUgZ29vZCB0byBhdm9pZCBjb25mdXNp
b24uIEJ1dCB3aGlsZSBhdCBpdDogSWYgeW91DQo+Pj4gaGF2ZSBhIG1pbnV0ZSwgY291bGQgeW91
IHBsZWFzZSBleHBsYWluIHRvIG1lIGhvdyB0byBwcm9wZXJseSBzZXQgdXAgdGhlDQo+Pj4gd2lm
aSBmaXJtd2FyZSBmaWxlcyBmb3IgbXkgRGVsbCBYUFMxMyAoOTM2MCk/IFRoZSByZWFzb25zIHdo
eSBJJ20NCj4+PiBhc2tpbmc6IFNlbmRpbmcgZGF0YSB2aWEgd2lmaSBpcyByZWFsbHkgc2xvdyBv
biBteSBsYXB0b3AgKHNjcCBjb3BpZXMNCj4+PiBvbmx5IGdldCAyIHRvIDUgTUJ5dGUvcyBvbiBu
ZXR3b3JrcyB0aGF0IGFyZSBrbm93biB0byBiZSBhIGxvdCBmYXN0ZXIpLg0KPj4+IEkgd29uZGVy
IGlmIHRoZSBmaXJtd2FyZSBmaWxlcyBvciB0aGUgY2FsaWJyYXRpb24gZGF0YSBpcyBwYXJ0IG9m
IHRoZQ0KPj4+IHJlYXNvbiB3aWZpIFR4IGlzIHNsb3cuIFRoZSBtYWNoaW5lIGlzIG5vcm1hbGx5
IHNoaXBwZWQgd2l0aCBhIHNsaWdodGx5DQo+Pj4gZW5oYW5jZWQgVWJ1bnR1IDE2LjA0LiBUaGF0
IGFtb25nIG90aGVycyBjb250YWlucyBhIHBhY2thZ2Ugd2l0aCB0aGUNCj4+PiBtYWNoaW5lIHNw
ZWNpZmljIGZpbGVzIGJvYXJkLmJpbiBhbmQgYm9hcmQtMi5iaW4gdGhhdCByZXBsYWNlIHRoZSBm
aWxlcw0KPj4+IG5vcm1hbGx5IGluc3RhbGxlZCBpbiAvbGliL2Zpcm13YXJlL2F0aDEway9RQ0E2
MTc0L2h3My4wLyBBcmUgdGhvc2UNCj4+PiBtYWNoaW5lIHNwZWNpZmljIGZpbGVzIGNydWNpYWwg
dG8gaGF2ZSBvciBhcmUgdGhlIG9uZSBmcm9tIHRoZQ0KPj4+IGxpbnV4LWZpcm13YXJlIHJlcG8g
Z29vZCBlbm9ndWg/IEknbSB1c2luZyBGZWRvcmEgYW5kIGNvdWxkIGNvcHkgdGhlDQo+Pj4gb25l
cyBmcm9tIFVidW50dSBvdmVyLCBidXQgb2J2aW91c2x5IHRoZXkgd2lsbCBnZXQgb3ZlcndyaXR0
ZW4gZXZlcnkNCj4+PiB0aW1lIEZlZG9yYSBzaGlwcyBhIG5ldyBsaW51eC1maXJtd2FyZSBwYWNr
YWdlIOKAkyBJT1c6IGV2ZXJ5IGZldyB3ZWVrcyA6LS8NCj4+IFllcywgdGhlIGJvYXJkIGZpbGUg
Y2FuIGFmZmVjdCB0aHJvdWdodHB1dCwgX2JvdGhfIFRDUCBhbmQgVURQLiBJIGRvbid0DQo+PiBr
bm93IHdoYXQgYm9hcmQgZmlsZXMgVWJ1bnR1IGlzIHNoaXBwaW5nIGJ1dCB3ZSBzaG91bGQgdHJ5
IHRvIGdldCB0aG9zZQ0KPj4gaW50byB1cHN0cmVhbS4NCj4NCj4gT3V0IG9mIGN1cmlvc2l0eSAo
ZG9uJ3Qgc3BlbmQgdGltZSBhbnN3ZXJpbmcgdGhpcyBpcyB5b3UgYXJlIGJ1c3kpOiBJcw0KPiB0
aGVyZSBldmVuIGEgbWVjaGFuaXNtIGZvciB0aGlzPyBLaW5kIG9mICJ0YWtlDQo+IGZpcm13YXJl
ZGlyL2JvYXJkLURlbGxfSW5jLi1YUFNfMTNfOTM2MC5iaW4gaWYgaXQgZXhpc3RzIGFuZA0KPiBm
aXJtd2FyZWRpci9ib2FyZC5iaW4gb3RoZXJ3aXNlPyBPciBjYW4gb25lIGZpbGUgc2VydmUgYWxs
IG1hY2hpbmVzPw0KDQpKdXN0IHRvIGEgcXVpY2sgc2hvcnQgYW5zd2VyOg0KDQpib2FyZC5iaW4g
Y29udGFpbnMganVzdCBvbmUgYm9hcmQgZmlsZSBidXQgYm9hcmQtMi5iaW4gaXMgaW4gcHJhY3Rp
c2UgYQ0KY29udGFpbmVyIGZvcm1hdCB3aGljaCBoYXMgbXVsdGlwbGUgYm9hcmQgZmlsZXMgKG9y
ICJpbWFnZXMiKS4gRWFjaA0KaW1hZ2UgaGFzIGEgbmFtZSBhc3NvY2lhdGVkIHRvIGl0IHdoaWNo
IGF0aDEwayB1c2VzIHRvIGZpbmQgdGhlIGNvcnJlY3QNCmltYWdlLiBFeGFtcGxlOg0KDQpidXM9
cGNpLHZlbmRvcj0xNjhjLGRldmljZT0wMDNlLHN1YnN5c3RlbS12ZW5kb3I9MTQ0ZCxzdWJzeXN0
ZW0tZGV2aWNlPWMxNGYsdmFyaWFudD1LDQoNClNvIHllcywgd2UgaGF2ZSBpbmZyYXN0cnVjdHVy
ZSByZWFkeSB0byBwcm92aWRlIG11bHRpcGxlIGJvYXJkIGZpbGVzLg0KQnV0IHVzdWFsbHkgdGhl
IGNoYWxsZW5nZSBpcyBob3cgdG8gbWFrZSBhdGgxMGsgY29ycmVjdGx5IGRldGVjdCB3aGF0DQpi
b2FyZCBmaWxlIGEgcGFydGljdWxhciBzeXN0ZW0gbmVlZHMuDQoNCj4+PiBTaWRlIG5vdGU6IFlv
dSBmaW5kIGEgbG90IG9mIHJlcG9ydHMgYWJvdXQgc2xvdyB3aWZpIGlzIHlvdSBzZWFyY2ggdGhl
DQo+Pj4gbmV0IHdpdGggdGVybXMgbGlrZSAiOTM2MCB3aWZpIHNsb3cgbGludXgiLiBVYnVudHUg
Zml4ZWQgdGhhdCBhIGZldw0KPj4+IG1vbnRocyBhZ28gd2l0aCB0aGlzIHBhdGNoOg0KPj4+IGh0
dHA6Ly9rZXJuZWwudWJ1bnR1LmNvbS9naXQvdWJ1bnR1L3VidW50dS14ZW5pYWwuZ2l0L2NvbW1p
dC8/aWQ9OTY5MGYxOWYwN2ZlZTJhY2IyYjA0ZWE1ZWFhNWRiMTg0ZWUxNzVkNQ0KPj4+IFNvbWUg
YnVncyBhYm91dCB0aGlzOg0KPj4+IGh0dHBzOi8vYnVncy5sYXVuY2hwYWQubmV0L3VidW50dS8r
c291cmNlL2xpbnV4LytidWcvMTY5MjgzNg0KPj4+IGh0dHBzOi8vYnVncy5sYXVuY2hwYWQubmV0
L3VidW50dS8rc291cmNlL2xpbnV4LytidWcvMTY3MDA0MQ0KPj4gQnV0IHRoaXMgYWdhaW4gYWJv
dXQgaW50ZXJyYWN0aW9uIGJldHdlZW4gYXRoMTBrIGFuZCBUQ1Agc3RhY2suIEFuZCBpdA0KPj4g
X29ubHlfIGFmZmVjdHMgVENQLCBVRFAgc2hvdWxkIGJlIHVuYWZmZWN0ZWQuDQo+DQo+IEFoaCwg
c29ycnksIG1pc3NlZCB0aGF0LiBTZWVtcyBJIGRpZG4ndCBwcm9wZXJseSByZWFkIHRoZSBzZWNv
bmQNCj4gbGF1bmNocGFkIGxpbmsgYWJvdmUuIFNvcnJ5Lg0KPg0KPj4gU28gd2hlbmV2ZXIgdGVz
dGluZw0KPj4gdGhyb3VnaHB1dCBwbGVhc2UgYWx3YXlzIG1lYXN1cmUgYm90aCBUQ1AgYW5kIFVE
UCBiZWNhdXNlIHRoZW4gaXQncw0KPj4gZWFzaWVyIHRvIHBpbnBvaW50IHRoZSByZWFzb24uDQo+
DQo+IElzIHRoZXJlIGFueSBkYXRhIEkgY291bGQgcHJvdmlkZSB0aGF0IG1pZ2h0IGhlbHAgZ2V0
dGluZyB0aGlzIHNvbGVkDQo+IG9uY2UgYW5kIGZvciBhbGw/DQoNCldpdGggInRoaXMiIHlvdSBt
ZWFuIFRDUCB0cmFuc21pdCB0aHJvdWdocHV0IHByb2JsZW0gd2l0aCBhdGgxMGs/IEkNCmRvbid0
IHRoaW5rIHRoZXJlJ3MgYW55IGVhc3kgc29sdXRpb24sIHdlIGp1c3QgbmVlZCB0byBzdGFydCBh
IHNlcmlvdXMNCmRpc2N1c3Npb24gd2l0aCB0aGUgVENQIG1haW50YWluZXJzIGhvdyB0byBzb2x2
ZSB0aGlzLiBJSVJDIGF0aDEwaw0KZGlkbid0IGhhdmUgdGhpcyBwcm9ibGVtIHVudGlsIHNvbWV0
aGluZyBjaGFuZ2VkIGluIHRoZSBUQ1Agc3RhY2ssIHNvIGluDQp0aGVvcnkgdGhpcyBjb3VsZCBi
ZSBjbGFzc2lmaWVkIGFzIGEgcmVncmVzc2lvbiBpbiB0aGUgVENQIHN0YWNrLiBCdXQNCkknbSBu
b3Qgc3VyZSBhYm91dCB0aGF0IGFuZCBuZWVkIHRvIGNoZWNrIHRoZSBoaXN0b3J5Lg0KDQpCdXQg
d2hhdCB3b3VsZCBiZSBoZWxwZnVsIHRvIGhhdmUgYSBkZXRhaWxlZCBzdW1tYXJ5IG9mIHRoZSBp
c3N1ZSwNCnBvaW50ZXJzIHRvIHBhc3QgZGlzY3Vzc2lvbnMgYW5kIGlkZW50aWZ5IHRoZSBUQ1Ag
Y29tbWl0IHdoaWNoIHN0YXJ0ZWQNCmFsbCB0aGlzIGV0Yy4gSSdsbCB0cnkgdG8gZG8gdGhhdCBi
ZWZvcmUgdGhlIE5ldGRldiAyLjIgYnV0IGxldCdzIHNlZSBpZg0KSSBjYW4gbWFrZSBpdC4gSGVs
cCB3aXRoIHRoYXQgaXMgcmVhbGx5IHdlbGNvbWUuDQoNCi0tIA0KS2FsbGUgVmFsbw==

Re: ath10k-regression in 4.14: Connections aborts with "failed to extract amsdu: -11"

[Kalle Valo]

+ linux-wireless

Ryan Hsu <ryanhsu@qti.qualcomm.com> writes:

>>> ath10k_pci 0000:3a:00.0: Direct firmware load for
>>> ath10k/pre-cal-pci-0000:3a:00.0.bin failed with error -2
>>> ath10k_pci 0000:3a:00.0: Direct firmware load for
>>> ath10k/cal-pci-0000:3a:00.0.bin failed with error -2
>> Do they have anything to do with this? Hardware is
>
> This error message is confusing since QCA6174 is not supporting
> pre-calibration feature, this reminds me that we need to clean this
> up.

These warnings come up again because of this commit:

c0cc00f250e1 ath10k: activate user space firmware loading again

https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?h=ath-next&id=c0cc00f250e19c717fc9cdbdb7f55aaa569c7498

We really need a function like request_firmware_nowarn() which would not
print a warning everytime a file is not found. It just confuses the
users and make them falsely believe that's the reason of their problems.

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

Re: ath10k-regression in 4.14: Connections aborts with "failed to extract amsdu: -11"

[Kalle Valo]

+ linux-wireless

Ryan Hsu <ryanhsu@qti.qualcomm.com> writes:

>>> ath10k_pci 0000:3a:00.0: Direct firmware load for
>>> ath10k/pre-cal-pci-0000:3a:00.0.bin failed with error -2
>>> ath10k_pci 0000:3a:00.0: Direct firmware load for
>>> ath10k/cal-pci-0000:3a:00.0.bin failed with error -2
>> Do they have anything to do with this? Hardware is
>
> This error message is confusing since QCA6174 is not supporting
> pre-calibration feature, this reminds me that we need to clean this
> up.

These warnings come up again because of this commit:

c0cc00f250e1 ath10k: activate user space firmware loading again

https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?h=3Da=
th-next&id=3Dc0cc00f250e19c717fc9cdbdb7f55aaa569c7498

We really need a function like request_firmware_nowarn() which would not
print a warning everytime a file is not found. It just confuses the
users and make them falsely believe that's the reason of their problems.

--=20
Kalle Valo=