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

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

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

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

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

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

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

[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