Re: Support for QCA9377

[Jay Foster]

On 5/16/2018 11:27 AM, Kalle Valo wrote:

+ linux-wireless

Jay Foster  writes:


On 5/15/2018 9:56 PM, Kalle Valo wrote:

Jay Foster  writes:


I too have been, off and on, looking for an ath10k driver solution for
a SparkLAN WUBQ-159ACN USB Wi-Fi adapter, so I have been keeping an
eye on this mailing list.  I just tried the latest
ath10k-pending-sdio-usb branch (ath10k-pending-sdio-usb-201804210910
tag), since I could see that support for the SparkLAN USB 0CF3:9378
device was just added.  The driver refers to this as the SparkLAN
WPEQ-160ACN device, but it has the same USB vendor/product ID as my
WUBQ-159ACN.  They both use the QCA9377 chip.

I got a driver to build with the 4.9 kernel and when it boots, it
recognizes my Wi-Fi adapter.  Now, I am trying to sort out what to do
about firmware.  I downloaded the board-2.bin, board.bin,
firmware-5.bin files from
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/ath10k/QCA9377/hw1.0.
I used the ath10k-fwencoder application from the qca-swiss-army-knife
tools to also build a firmware file, but I am not clear on what files
I should be using.  SparkLAN provided, with the qcacld-2.0 wlan
driver, the following files:
athsetup.bin, athwlan.bin, cfg.dat, fakeboar.bin, otp.bin, and
qcom_cfg.ini.  I used the command:

qca-swiss-army-knife/tools/scripts/ath10k/ath10k-fwencoder --create
--otp ../../../otp.bin --firmware ../../../athwlan.bin
--set-wmi-op-version=tlv --set-htt-op-version=tlv --set-fw-api=6
--features=ignore-otp-result

to create my firmware-usb-6.bin and used the fakeboar.bin for my
board-usb.bin files.  However, when the driver loads, it is looking
for a file called ath10k/cal-usb-1-1.2.bin.  Where do I get that
file?

You can ignore that warning. cal-*.bin are optional files containing the
calibration data, in case you don't have the calibration data in OTP.
But my guess is that in your device you have the calibration data in OTP
so you don't need cal-*.bin.

Hopefully in 4.18 that warning will be away and users won't get confused 
anymore.


    I tried using the athsetup.bin file for this, but I do not
think that works.  The driver reports:

/lib/firmware/ath10k/QCA9377/hw1.0# usb 1-1.2: qca9377 hw1.1 SparkLAN
WPEQ-160ACN target 0x05020001 chip_id 0x sub :
usb 1-1.2: kconfig debug 1 debugfs 0 tracing 0 dfs 0 testmode 1
usb 1-1.2: firmware ver  api 6 features ignore-otp crc32 e8985f67
usb 1-1.2: found invalid board magic
usb 1-1.2: board_file api 1 bmi_id N/A crc32 58a139e9
usb 1-1.2: invalid hw_params.n_cipher_suites 0

What does invalid board magic mean?

This log means that ath10k first tried to load board-2.bin but it was
corrupted for some reason. Then it found and used board.bin instead.

It seems odd that the board-2.bin file I downloaded from
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/ath10k/QCA9377/hw1.0
is somehow corrupted.  Does the message mean that the board-2.bin file
itself is bad or that it is not appropriate/useful for my particular
Wi-Fi device?

I meant that the file itself is bad, but of course there could be a bug
lurking somewhere as well. The md5sum should be:

0234621d41643e46243438b1661c2407  ath10k/QCA9377/hw1.0/board-2.bin

But this does not make any difference for you as the board-2.bin file
does not have any board files for usb devices yet.
This was my bad.  My file was corrupted.  I fixed it (matches the md5sum 
above), but as you noted, it is of no help for USB devices.


usb 1-1.2: failed to fetch board data for 
bus=usb,vendor=0cf3,device=9378,subsystem-vendor=,subsystem-device= 
from ath10k/QCA9377/hw1.0/board-2.bin


The driver then goes on and reads from board-usb.bin:
usb 1-1.2: board_file api 1 bmi_id N/A crc32 58a139e9
usb 1-1.2: invalid hw_params.n_cipher_suites 0




When you say that the driver then used board.bin instead, I think in
my case this is board-usb.bin (the same as my fakeboar.bin file from
SparkLAN), since my device is a USB device.  I am just trying to be
clear on my understanding.

A good point and you are correct. I forgot that Erik's patches are still
using that special board-usb.bin. That should be removed before the
patches get applied upstream as we should get all the board files to
board-2.bin anyway. (board.bin is just for testing purposes)


The Wi-Fi USB adapter may be installed in any number of different USB
locations, so why is the USB location (1-1.2) part of one of the
filenames?

Because there needs to be some way to identify multiple devices on the
same host. But cal-*.bin is mainly meant for AP devices where the
devices have a fixed slot in the PCI bus and the calibration data is
stored in host's filesystem (check openwrt to see how it's used).


I did manage to get a successful Wi-Fi STA mode connection with this
driver.  One issue that I don't understand is when the driver attempts
to load a FW file that is not present, it fails with 

Re: Support for QCA9377

[Kalle Valo]

+ linux-wireless

Jay Foster  writes:

> On 5/15/2018 9:56 PM, Kalle Valo wrote:
>> Jay Foster  writes:
>>
>>> I too have been, off and on, looking for an ath10k driver solution for
>>> a SparkLAN WUBQ-159ACN USB Wi-Fi adapter, so I have been keeping an
>>> eye on this mailing list.  I just tried the latest
>>> ath10k-pending-sdio-usb branch (ath10k-pending-sdio-usb-201804210910
>>> tag), since I could see that support for the SparkLAN USB 0CF3:9378
>>> device was just added.  The driver refers to this as the SparkLAN
>>> WPEQ-160ACN device, but it has the same USB vendor/product ID as my
>>> WUBQ-159ACN.  They both use the QCA9377 chip.
>>>
>>> I got a driver to build with the 4.9 kernel and when it boots, it
>>> recognizes my Wi-Fi adapter.  Now, I am trying to sort out what to do
>>> about firmware.  I downloaded the board-2.bin, board.bin,
>>> firmware-5.bin files from
>>> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/ath10k/QCA9377/hw1.0.
>>> I used the ath10k-fwencoder application from the qca-swiss-army-knife
>>> tools to also build a firmware file, but I am not clear on what files
>>> I should be using.  SparkLAN provided, with the qcacld-2.0 wlan
>>> driver, the following files:
>>> athsetup.bin, athwlan.bin, cfg.dat, fakeboar.bin, otp.bin, and
>>> qcom_cfg.ini.  I used the command:
>>>
>>> qca-swiss-army-knife/tools/scripts/ath10k/ath10k-fwencoder --create
>>> --otp ../../../otp.bin --firmware ../../../athwlan.bin
>>> --set-wmi-op-version=tlv --set-htt-op-version=tlv --set-fw-api=6
>>> --features=ignore-otp-result
>>>
>>> to create my firmware-usb-6.bin and used the fakeboar.bin for my
>>> board-usb.bin files.  However, when the driver loads, it is looking
>>> for a file called ath10k/cal-usb-1-1.2.bin.  Where do I get that
>>> file?
>> You can ignore that warning. cal-*.bin are optional files containing the
>> calibration data, in case you don't have the calibration data in OTP.
>> But my guess is that in your device you have the calibration data in OTP
>> so you don't need cal-*.bin.
>>
>> Hopefully in 4.18 that warning will be away and users won't get confused 
>> anymore.
>>
>>>    I tried using the athsetup.bin file for this, but I do not
>>> think that works.  The driver reports:
>>>
>>> /lib/firmware/ath10k/QCA9377/hw1.0# usb 1-1.2: qca9377 hw1.1 SparkLAN
>>> WPEQ-160ACN target 0x05020001 chip_id 0x sub :
>>> usb 1-1.2: kconfig debug 1 debugfs 0 tracing 0 dfs 0 testmode 1
>>> usb 1-1.2: firmware ver  api 6 features ignore-otp crc32 e8985f67
>>> usb 1-1.2: found invalid board magic
>>> usb 1-1.2: board_file api 1 bmi_id N/A crc32 58a139e9
>>> usb 1-1.2: invalid hw_params.n_cipher_suites 0
>>>
>>> What does invalid board magic mean?
>> This log means that ath10k first tried to load board-2.bin but it was
>> corrupted for some reason. Then it found and used board.bin instead.
> It seems odd that the board-2.bin file I downloaded from
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/ath10k/QCA9377/hw1.0
> is somehow corrupted.  Does the message mean that the board-2.bin file
> itself is bad or that it is not appropriate/useful for my particular
> Wi-Fi device?

I meant that the file itself is bad, but of course there could be a bug
lurking somewhere as well. The md5sum should be:

0234621d41643e46243438b1661c2407  ath10k/QCA9377/hw1.0/board-2.bin

But this does not make any difference for you as the board-2.bin file
does not have any board files for usb devices yet.

> When you say that the driver then used board.bin instead, I think in
> my case this is board-usb.bin (the same as my fakeboar.bin file from
> SparkLAN), since my device is a USB device.  I am just trying to be
> clear on my understanding.

A good point and you are correct. I forgot that Erik's patches are still
using that special board-usb.bin. That should be removed before the
patches get applied upstream as we should get all the board files to
board-2.bin anyway. (board.bin is just for testing purposes)

>>> The Wi-Fi USB adapter may be installed in any number of different USB
>>> locations, so why is the USB location (1-1.2) part of one of the
>>> filenames?
>> Because there needs to be some way to identify multiple devices on the
>> same host. But cal-*.bin is mainly meant for AP devices where the
>> devices have a fixed slot in the PCI bus and the calibration data is
>> stored in host's filesystem (check openwrt to see how it's used).
>>
> I did manage to get a successful Wi-Fi STA mode connection with this
> driver.  One issue that I don't understand is when the driver attempts
> to load a FW file that is not present, it fails with error -2 and then
> reports, "Falling back to user helper".  However, this 'user helper'
> does not exist/work either, but the driver waits quite a while waiting
> for it (about half a minute or so).  This causes a delay loading the
> driver (about half a 

Re: ath10k wake_tx_queue issues

[Erik Stromdahl]

Hello Niklas

Quick question:
Are you using my patch: "ath10k: add htt_tx num_pending window"?

I assume (from your logs below) that you are not...

See more comments below.




I guess the best way to describe this is to show my ftrace buffer:

  ksoftirqd/2-21[002] .ns474.711744: ath10k_htt_tx_dec_pending: 
num_pen: 60
  ksoftirqd/2-21[002] .ns374.711761: ath10k_mac_op_wake_tx_queue: 
txq: frame_cnt: 1 byte_cnt: 1534 f_txq: frame_cnt: 1 byte_cnt: 1534 num_pen: 60 
queue: 0
  ksoftirqd/2-21[002] .ns474.711765: ath10k_htt_tx_inc_pending: 
num_pen: 61
  ksoftirqd/2-21[002] .ns474.711781: ath10k_htt_tx_inc_pending: 
num_pen: 62
  ksoftirqd/2-21[002] .ns474.711787: ath10k_htt_tx_dec_pending: 
num_pen: 61
  ksoftirqd/2-21[002] .ns374.711803: ath10k_mac_op_wake_tx_queue: 
txq: frame_cnt: 1 byte_cnt: 1534 f_txq: frame_cnt: 1 byte_cnt: 1534 num_pen: 61 
queue: 0
  ksoftirqd/2-21[002] .ns474.711807: ath10k_htt_tx_inc_pending: 
num_pen: 62
  ksoftirqd/2-21[002] .ns474.711823: ath10k_htt_tx_inc_pending: 
num_pen: 63
  ksoftirqd/2-21[002] .ns474.711829: ath10k_htt_tx_dec_pending: 
num_pen: 62
  ksoftirqd/2-21[002] .ns374.711845: ath10k_mac_op_wake_tx_queue: 
txq: frame_cnt: 1 byte_cnt: 1534 f_txq: frame_cnt: 1 byte_cnt: 1534 num_pen: 62 
queue: 0
  ksoftirqd/2-21[002] .ns474.711849: ath10k_htt_tx_inc_pending: 
num_pen: 63
  ksoftirqd/2-21[002] .ns474.711865: ath10k_htt_tx_inc_pending: 
num_pen: 64

For high latency devices, when the num_pending counter reaches this point (64),
ath10k calls ieee80211_stop_queues (from ath10k_htt_tx_inc_pending -> 
ath10k_mac_tx_lock).
This will stop all per-TID queues (16 in total).


  ksoftirqd/2-21[002] dns574.711870: stop_queue: phy0 queue:0, 
reason:0
  ksoftirqd/2-21[002] dns574.711874: stop_queue: phy0 queue:1, 
reason:0
  ksoftirqd/2-21[002] dns574.711877: stop_queue: phy0 queue:2, 
reason:0
  ksoftirqd/2-21[002] dns574.711880: stop_queue: phy0 queue:3, 
reason:0
  ksoftirqd/2-21[002] dns574.711882: stop_queue: phy0 queue:4, 
reason:0
  ksoftirqd/2-21[002] dns574.711885: stop_queue: phy0 queue:5, 
reason:0
  ksoftirqd/2-21[002] dns574.711887: stop_queue: phy0 queue:6, 
reason:0
  ksoftirqd/2-21[002] dns574.711890: stop_queue: phy0 queue:7, 
reason:0
  ksoftirqd/2-21[002] dns574.711892: stop_queue: phy0 queue:8, 
reason:0
  ksoftirqd/2-21[002] dns574.711895: stop_queue: phy0 queue:9, 
reason:0
  ksoftirqd/2-21[002] dns574.711898: stop_queue: phy0 queue:10, 
reason:0
  ksoftirqd/2-21[002] dns574.711900: stop_queue: phy0 queue:11, 
reason:0
  ksoftirqd/2-21[002] dns574.711903: stop_queue: phy0 queue:12, 
reason:0
  ksoftirqd/2-21[002] dns574.711905: stop_queue: phy0 queue:13, 
reason:0
  ksoftirqd/2-21[002] dns574.711908: stop_queue: phy0 queue:14, 
reason:0
  ksoftirqd/2-21[002] dns574.711910: stop_queue: phy0 queue:15, 
reason:0
  ksoftirqd/2-21[002] .ns474.711917: ath10k_htt_tx_dec_pending: 
num_pen: 63

At this point, the driver have received a TX_COMPL_IND (since num_pending has 
been decremented to 63).
Without the patch I mentioned above, the logic is that the TX queues will be 
re-enabled immediately.
This is achieved by calling ieee80211_stop_queues.


  ksoftirqd/2-21[002] dns574.711922: wake_queue: phy0 queue:0, 
reason:0
  ksoftirqd/2-21[002] dns574.711929: wake_queue: phy0 queue:15, 
reason:0

2 queues have been enabled here. I don't know why not all queues have been 
re-enabled.
Perhaps it is due to that mac80211 immediately gets more data on one of the 
just re-enabled queues,
resulting in...

  ksoftirqd/2-21[002] .ns374.711948: ath10k_mac_op_wake_tx_queue: 
txq: frame_cnt: 1 byte_cnt: 1534 f_txq: frame_cnt: 1 byte_cnt: 1534 num_pen: 63 
queue: 0

...the the wake_tx_queue op beeing invoked again ...

  ksoftirqd/2-21[002] .ns474.711952: ath10k_htt_tx_inc_pending: 
num_pen: 64

... and the num_pending counter beeing incremented as a result of this.
This results in all queues beeing ...

  ksoftirqd/2-21[002] dns574.711956: stop_queue: phy0 queue:0, 
reason:0
  ksoftirqd/2-21[002] dns574.711959: stop_queue: phy0 queue:1, 
reason:0
  ksoftirqd/2-21[002] dns574.711962: stop_queue: phy0 queue:2, 
reason:0
  ksoftirqd/2-21[002] dns574.711964: stop_queue: phy0 queue:3, 
reason:0
  ksoftirqd/2-21[002] dns574.711967: stop_queue: phy0 queue:4, 
reason:0
  ksoftirqd/2-21[002] dns574.711969: stop_queue: phy0 queue:5, 
reason:0
  ksoftirqd/2-21[002] dns574.711972: stop_queue: phy0 queue:6, 
reason:0
  ksoftirqd/2-21[002] dns574.711974: stop_queue: phy0 queue:7, 
reason:0
  ksoftirqd/2-21  

Re: Support for QCA9377

[Jay Foster]

On 5/15/2018 9:56 PM, Kalle Valo wrote:

Jay Foster  writes:


I too have been, off and on, looking for an ath10k driver solution for
a SparkLAN WUBQ-159ACN USB Wi-Fi adapter, so I have been keeping an
eye on this mailing list.  I just tried the latest
ath10k-pending-sdio-usb branch (ath10k-pending-sdio-usb-201804210910
tag), since I could see that support for the SparkLAN USB 0CF3:9378
device was just added.  The driver refers to this as the SparkLAN
WPEQ-160ACN device, but it has the same USB vendor/product ID as my
WUBQ-159ACN.  They both use the QCA9377 chip.

I got a driver to build with the 4.9 kernel and when it boots, it
recognizes my Wi-Fi adapter.  Now, I am trying to sort out what to do
about firmware.  I downloaded the board-2.bin, board.bin,
firmware-5.bin files from
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/ath10k/QCA9377/hw1.0.
I used the ath10k-fwencoder application from the qca-swiss-army-knife
tools to also build a firmware file, but I am not clear on what files
I should be using.  SparkLAN provided, with the qcacld-2.0 wlan
driver, the following files:
athsetup.bin, athwlan.bin, cfg.dat, fakeboar.bin, otp.bin, and
qcom_cfg.ini.  I used the command:

qca-swiss-army-knife/tools/scripts/ath10k/ath10k-fwencoder --create
--otp ../../../otp.bin --firmware ../../../athwlan.bin
--set-wmi-op-version=tlv --set-htt-op-version=tlv --set-fw-api=6
--features=ignore-otp-result

to create my firmware-usb-6.bin and used the fakeboar.bin for my
board-usb.bin files.  However, when the driver loads, it is looking
for a file called ath10k/cal-usb-1-1.2.bin.  Where do I get that
file?

You can ignore that warning. cal-*.bin are optional files containing the
calibration data, in case you don't have the calibration data in OTP.
But my guess is that in your device you have the calibration data in OTP
so you don't need cal-*.bin.

Hopefully in 4.18 that warning will be away and users won't get confused 
anymore.


   I tried using the athsetup.bin file for this, but I do not
think that works.  The driver reports:

/lib/firmware/ath10k/QCA9377/hw1.0# usb 1-1.2: qca9377 hw1.1 SparkLAN
WPEQ-160ACN target 0x05020001 chip_id 0x sub :
usb 1-1.2: kconfig debug 1 debugfs 0 tracing 0 dfs 0 testmode 1
usb 1-1.2: firmware ver  api 6 features ignore-otp crc32 e8985f67
usb 1-1.2: found invalid board magic
usb 1-1.2: board_file api 1 bmi_id N/A crc32 58a139e9
usb 1-1.2: invalid hw_params.n_cipher_suites 0

What does invalid board magic mean?

This log means that ath10k first tried to load board-2.bin but it was
corrupted for some reason. Then it found and used board.bin instead.
It seems odd that the board-2.bin file I downloaded from 
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/ath10k/QCA9377/hw1.0 
is somehow corrupted.  Does the message mean that the board-2.bin file 
itself is bad or that it is not appropriate/useful for my particular 
Wi-Fi device?


When you say that the driver then used board.bin instead, I think in my 
case this is board-usb.bin (the same as my fakeboar.bin file from 
SparkLAN), since my device is a USB device.  I am just trying to be 
clear on my understanding.





The Wi-Fi USB adapter may be installed in any number of different USB
locations, so why is the USB location (1-1.2) part of one of the
filenames?

Because there needs to be some way to identify multiple devices on the
same host. But cal-*.bin is mainly meant for AP devices where the
devices have a fixed slot in the PCI bus and the calibration data is
stored in host's filesystem (check openwrt to see how it's used).

I did manage to get a successful Wi-Fi STA mode connection with this 
driver.  One issue that I don't understand is when the driver attempts 
to load a FW file that is not present, it fails with error -2 and then 
reports, "Falling back to user helper".  However, this 'user helper' 
does not exist/work either, but the driver waits quite a while waiting 
for it (about half a minute or so).  This causes a delay loading the 
driver (about half a minute for each missing file).  So, even though the 
cal files are optional, if they are not there, it significantly delays 
loading of the driver.  I need to eliminate this delay.  For now, I 
patched the driver to not attempt to load the pre-cal-usb-.bin or 
the cal-usb-.bin files (that do not exist for my adapter), but 
there must be a better way to avoid this delay.


Thanks very much for your help.


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

Re: [PATCH 2/2] ath10k: DFS Host Confirmation

[Kalle Valo]

Peter Oh  writes:

>> Sure, every software change can cause regressions. But the thing is that
>> this isn't an optional, ath10k has to have this to be able to continue
>> using DFS channels.
>
> Kalle, you said you don't know which exact FCC requirement this is for
> in another email thread. Then how come you're sure this is not an
> optional 

To me this is a mandatory ath10k feature because if the host driver does
not have this DFS channels won't work anymore.

> and this approach is right one?

That's something you need to ask the firmware team who designed and
implemented this.

This discussion is going circles, it would be a lot easier if you could
clearly say your point. But if your point is just "I don't like this"
then there's not much, if any, I can do about that.

-- 
Kalle Valo

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

Re: ath10k wake_tx_queue issues

[Toke Høiland-Jørgensen]

Niklas Cassel  writes:
> [ .. snip .. ]
>> > Sure, the regular way ath10k_mac_op_wake_tx_queue is called is via
>> > ieee80211_subif_start_xmit => __ieee80211_subif_start_xmit => 
>> > ieee80211_xmit_fast
>> > => ieee80211_queue_skb => drv_wake_tx_queue.
>> >
>> > But I was expecting the call to ieee80211_wake_queue to somehow trigger a 
>> > call
>> > to ath10k_mac_op_wake_tx_queue, since there is still data in the send 
>> > buffer/
>> > in the ieee80211_txq that needs to be sent, to allow more data to be 
>> > written to
>> > the socket. But obviously the callback never comes.
>> > Or how else is this supposed to work?
>> 
>> The driver should reschedule itself before/after calling
>> ieee80211_wake_queue. mt76 does this; I'm not actually sure if ath9k
>> does the right thing either, I'm not too familiar with that part of the
>> code. There's no direct call to reschedule that I can see, but there may
>> be another reason why this is not needed for ath9k. I'm sure Felix
>> knows?
>
> Hello Toke
>
> Unfortunately, it doesn't look like mt76 uses any ieee80211_* function
> to reschedule.

It doesn't need to; it just reschedules itself.

Basically, the wake_tx_queue() callback is just a way for mac80211 to
notify the driver that new packets are available and that it should
start its scheduling function. But in this case it is the driver that is
restarting the queues, so it already knows that. And so it can just call
its internal scheduling function. This is what mt76 does in
mt76_dma_tx_cleanup() with the call to mt76_txq_schedule() before
calling ieee80211_wake_queue().

I think that what ath10k should be doing is calling
ath10k_mac_tx_push_pending() when it restarts the queues.

> I just came across a ieee80211_schedule_txq() function in e937b8da5a59
> ("mac80211: Add TXQ scheduling API"). However, this commit was
> reverted. Any plans on resubmitting this?

Yeah, I have a revised version lying around waiting for Felix to review
it. But that wouldn't help this bug; it's just an API change, it doesn't
change behaviour...

-Toke

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

Re: ath10k wake_tx_queue issues

[Alexander Wetzel]

Hello,

This sounds exactly like the issue I just submitted a patch for.
Can you test https://patchwork.kernel.org/patch/10399613/ if that solves
the issue?



Am 15.05.2018 um 22:31 schrieb Niklas Cassel:
> On Tue, May 15, 2018 at 04:13:48PM +0200, Toke Høiland-Jørgensen wrote:
>> [ Adding Felix ]
>>
>>
>> Niklas Cassel  writes:
>>
>>> Hello mac80211 and ath10k people
>>>
>>> Using ath10k, TX stops working when running iperf
>>>
>>> [  3]  0.0- 1.0 sec  2.00 MBytes  16.8 Mbits/sec
>>> [  3]  1.0- 2.0 sec  3.12 MBytes  26.2 Mbits/sec
>>> [  3]  2.0- 3.0 sec  3.25 MBytes  27.3 Mbits/sec
>>> [  3]  3.0- 4.0 sec   655 KBytes  5.36 Mbits/sec
>>> [  3]  4.0- 5.0 sec  0.00 Bytes  0.00 bits/sec
>>> [  3]  5.0- 6.0 sec  0.00 Bytes  0.00 bits/sec
>>> [  3]  6.0- 7.0 sec  0.00 Bytes  0.00 bits/sec
>>> [  3]  7.0- 8.0 sec  0.00 Bytes  0.00 bits/sec
>>> [  3]  8.0- 9.0 sec  0.00 Bytes  0.00 bits/sec
>>> [  3]  9.0-10.0 sec  0.00 Bytes  0.00 bits/sec
>>> [  3]  0.0-10.3 sec  9.01 MBytes  7.32 Mbits/sec
>>>
>>> The problem can be reproduced without specifying a send buffer size,
>>> however, specifying a small send buffer helps to reproduce the problem 
>>> faster.
>>>
>>> What happens is that iperf gets -EAGAIN on write().
>>> It continues to get -EAGAIN, even if iperf runs for e.g. 300 seconds.
>>> The reason why we get -EAGAIN is because the send socket buffer is full
>>> (iperf uses non-blocking I/O).
>>>
>>> The problem is that the mac80211 wake_tx_queue callback never comes.
>>>
>>> I guess the best way to describe this is to show my ftrace buffer:
>>>
>>>  ksoftirqd/2-21[002] .ns474.711744: ath10k_htt_tx_dec_pending: 
>>> num_pen: 60
>>>  ksoftirqd/2-21[002] .ns374.711761: 
>>> ath10k_mac_op_wake_tx_queue: txq: frame_cnt: 1 byte_cnt: 1534 f_txq: 
>>> frame_cnt: 1 byte_cnt: 1534 num_pen: 60 queue: 0
>>>  ksoftirqd/2-21[002] .ns474.711765: ath10k_htt_tx_inc_pending: 
>>> num_pen: 61
>>>  ksoftirqd/2-21[002] .ns474.711781: ath10k_htt_tx_inc_pending: 
>>> num_pen: 62
>>>  ksoftirqd/2-21[002] .ns474.711787: ath10k_htt_tx_dec_pending: 
>>> num_pen: 61
>>>  ksoftirqd/2-21[002] .ns374.711803: 
>>> ath10k_mac_op_wake_tx_queue: txq: frame_cnt: 1 byte_cnt: 1534 f_txq: 
>>> frame_cnt: 1 byte_cnt: 1534 num_pen: 61 queue: 0
>>>  ksoftirqd/2-21[002] .ns474.711807: ath10k_htt_tx_inc_pending: 
>>> num_pen: 62
>>>  ksoftirqd/2-21[002] .ns474.711823: ath10k_htt_tx_inc_pending: 
>>> num_pen: 63
>>>  ksoftirqd/2-21[002] .ns474.711829: ath10k_htt_tx_dec_pending: 
>>> num_pen: 62
>>>  ksoftirqd/2-21[002] .ns374.711845: 
>>> ath10k_mac_op_wake_tx_queue: txq: frame_cnt: 1 byte_cnt: 1534 f_txq: 
>>> frame_cnt: 1 byte_cnt: 1534 num_pen: 62 queue: 0
>>>  ksoftirqd/2-21[002] .ns474.711849: ath10k_htt_tx_inc_pending: 
>>> num_pen: 63
>>>  ksoftirqd/2-21[002] .ns474.711865: ath10k_htt_tx_inc_pending: 
>>> num_pen: 64
>>>  ksoftirqd/2-21[002] dns574.711870: stop_queue: phy0 queue:0, 
>>> reason:0
>>>  ksoftirqd/2-21[002] dns574.711874: stop_queue: phy0 queue:1, 
>>> reason:0
>>>  ksoftirqd/2-21[002] dns574.711877: stop_queue: phy0 queue:2, 
>>> reason:0
>>>  ksoftirqd/2-21[002] dns574.711880: stop_queue: phy0 queue:3, 
>>> reason:0
>>>  ksoftirqd/2-21[002] dns574.711882: stop_queue: phy0 queue:4, 
>>> reason:0
>>>  ksoftirqd/2-21[002] dns574.711885: stop_queue: phy0 queue:5, 
>>> reason:0
>>>  ksoftirqd/2-21[002] dns574.711887: stop_queue: phy0 queue:6, 
>>> reason:0
>>>  ksoftirqd/2-21[002] dns574.711890: stop_queue: phy0 queue:7, 
>>> reason:0
>>>  ksoftirqd/2-21[002] dns574.711892: stop_queue: phy0 queue:8, 
>>> reason:0
>>>  ksoftirqd/2-21[002] dns574.711895: stop_queue: phy0 queue:9, 
>>> reason:0
>>>  ksoftirqd/2-21[002] dns574.711898: stop_queue: phy0 queue:10, 
>>> reason:0
>>>  ksoftirqd/2-21[002] dns574.711900: stop_queue: phy0 queue:11, 
>>> reason:0
>>>  ksoftirqd/2-21[002] dns574.711903: stop_queue: phy0 queue:12, 
>>> reason:0
>>>  ksoftirqd/2-21[002] dns574.711905: stop_queue: phy0 queue:13, 
>>> reason:0
>>>  ksoftirqd/2-21[002] dns574.711908: stop_queue: phy0 queue:14, 
>>> reason:0
>>>  ksoftirqd/2-21[002] dns574.711910: stop_queue: phy0 queue:15, 
>>> reason:0
>>>  ksoftirqd/2-21[002] .ns474.711917: ath10k_htt_tx_dec_pending: 
>>> num_pen: 63
>>>  ksoftirqd/2-21[002] dns574.711922: wake_queue: phy0 queue:0, 
>>> reason:0
>>>  ksoftirqd/2-21[002] dns574.711929: wake_queue: phy0 queue:15, 
>>> reason:0
>>>  ksoftirqd/2-21[002] .ns374.711948: 
>>> ath10k_mac_op_wake_tx_queue: txq: frame_cnt: 1 byte_cnt: 1534 f_txq: 
>>> frame_cnt: 1 byte_cnt: 1534 num_pen: 63 queue: 0
>>>  ksoftirqd/2-21[002] .ns474.711952: