Re: [ath9k-devel] [RFC 0/3] of: add common bindings to (de)activate IEEE 802.11 bands

[Felix Fietkau]

On 2016-10-05 22:31, Rob Herring wrote:
> On Wed, Oct 5, 2016 at 1:36 PM, Felix Fietkau <n...@nbd.name> wrote:
>> On 2016-10-05 20:25, Martin Blumenstingl wrote:
>>> On Mon, Oct 3, 2016 at 5:22 PM, Rob Herring <robh...@kernel.org> wrote:
>>>> On Sun, Oct 2, 2016 at 5:50 PM, Martin Blumenstingl
>>>> <martin.blumensti...@googlemail.com> wrote:
>>>>> There are at least two drivers (ath9k and mt76) out there, where
>>>>> devicetree authors need to override the enabled bands.
>>>>>
>>>>> For ath9k there is only one use-case: disabling a band which has been
>>>>> incorrectly enabled by the vendor in the EEPROM (enabling a band is not
>>>>> possible because the calibration data would be missing in the EEPROM).
>>>>> The mt76 driver (currently pending for review) however allows enabling
>>>>> and disabling the 2.4GHz and 5GHz band, see [0].
>>>>>
>>>>> Based on the discussion of (earlier versions of) my ath9k devicetree
>>>>> patch it was suggested [1] that we use enable- and disable- properties.
>>>>> The current patch implements:
>>>>> - bands can be enabled or disabled with the corresponding property
>>>>> - if both (disable and enable) properties are given and a driver asks
>>>>>   whether the band is enabled then the logic will return false (= not
>>>>>   enabled, preferring the disabled flag)
>>>>> - if both (disable and enable) properties are given and a driver asks
>>>>>   whether the band is disabled then the logic will return true (again,
>>>>>   preferring the disabled flag over the enabled flag)
>>>>>
>>>>> We can still change the logic to do what the mt76 driver does (I am
>>>>> fine with both solutions):
>>>>> - property not available: driver decides which bands to enable
>>>>> - property set to 0: disable the band
>>>>> - property set to 1: enable the band
>>>>
>>>> I prefer this way. Really, I'd prefer just a boolean disable property.
>>>> I'm not sure why you need the enable. We usually have these tri-state
>>>> properties when you want not present to mean use the bootloader or
>>>> default setting. Try to make not present the most common case.
>>> Felix: could you please give a few details why mt76 can not only
>>> disable but also enable a specific band?
>>> There is no specific comment in the sources [0] why this is needed.
>>> All other drivers that I am aware of (ath9k, rt2x00) only allow
>>> disabling a specific band, they never enable it (this has to be done
>>> explicitly by the EEPROM).
>> None of the devices use it at the moment, I probably added it when I
>> played with a device that had broken EEPROM data. I guess I decided to
>> do it this way because on many devices the band capability field simply
>> cannot be trusted.
>> I guess I would be okay with just having a disable property and adding
>> an enable property later only if we end up actually needing it.
> 
> If EEPROM is commonly wrong or missing, then seems like you want to
> plan ahead and support both enable and disable.
> 
> The other approach I've mentioned before is just put raw EEPROM data
> into DT to override the EEPROM. This would be better if there's a
> large number of settings you need.
So far, other EEPROM settings didn't need to be changed.

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [RFC 0/3] of: add common bindings to (de)activate IEEE 802.11 bands

[Felix Fietkau]

On 2016-10-05 20:25, Martin Blumenstingl wrote:
> On Mon, Oct 3, 2016 at 5:22 PM, Rob Herring  wrote:
>> On Sun, Oct 2, 2016 at 5:50 PM, Martin Blumenstingl
>>  wrote:
>>> There are at least two drivers (ath9k and mt76) out there, where
>>> devicetree authors need to override the enabled bands.
>>>
>>> For ath9k there is only one use-case: disabling a band which has been
>>> incorrectly enabled by the vendor in the EEPROM (enabling a band is not
>>> possible because the calibration data would be missing in the EEPROM).
>>> The mt76 driver (currently pending for review) however allows enabling
>>> and disabling the 2.4GHz and 5GHz band, see [0].
>>>
>>> Based on the discussion of (earlier versions of) my ath9k devicetree
>>> patch it was suggested [1] that we use enable- and disable- properties.
>>> The current patch implements:
>>> - bands can be enabled or disabled with the corresponding property
>>> - if both (disable and enable) properties are given and a driver asks
>>>   whether the band is enabled then the logic will return false (= not
>>>   enabled, preferring the disabled flag)
>>> - if both (disable and enable) properties are given and a driver asks
>>>   whether the band is disabled then the logic will return true (again,
>>>   preferring the disabled flag over the enabled flag)
>>>
>>> We can still change the logic to do what the mt76 driver does (I am
>>> fine with both solutions):
>>> - property not available: driver decides which bands to enable
>>> - property set to 0: disable the band
>>> - property set to 1: enable the band
>>
>> I prefer this way. Really, I'd prefer just a boolean disable property.
>> I'm not sure why you need the enable. We usually have these tri-state
>> properties when you want not present to mean use the bootloader or
>> default setting. Try to make not present the most common case.
> Felix: could you please give a few details why mt76 can not only
> disable but also enable a specific band?
> There is no specific comment in the sources [0] why this is needed.
> All other drivers that I am aware of (ath9k, rt2x00) only allow
> disabling a specific band, they never enable it (this has to be done
> explicitly by the EEPROM).
None of the devices use it at the moment, I probably added it when I
played with a device that had broken EEPROM data. I guess I decided to
do it this way because on many devices the band capability field simply
cannot be trusted.
I guess I would be okay with just having a disable property and adding
an enable property later only if we end up actually needing it.

- Felix

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [v3] ath9k: Switch to using mac80211 intermediate software queues.

[Felix Fietkau]

On 2016-07-08 18:28, Toke Høiland-Jørgensen wrote:
> Felix Fietkau <n...@nbd.name> writes:
> 
>> On 2016-07-08 17:53, Toke Høiland-Jørgensen wrote:
>>> Kalle Valo <kv...@qca.qualcomm.com> writes:
>>> 
>>>> Toke Høiland-Jørgensen wrote:
>>>>> This switches ath9k over to using the mac80211 intermediate software
>>>>> queueing mechanism for data packets. It removes the queueing inside the
>>>>> driver, except for the retry queue, and instead pulls from mac80211 when
>>>>> a packet is needed. The retry queue is used to store a packet that was
>>>>> pulled but can't be sent immediately.
>>>>> 
>>>>> The old code path in ath_tx_start that would queue packets has been
>>>>> removed completely, as has the qlen limit tunables (since there's no
>>>>> longer a queue in the driver to limit).
>>>>> 
>>>>> Based on Tim's original patch set, but reworked quite thoroughly.
>>>>> 
>>>>> Cc: Tim Shepard <s...@alum.mit.edu>
>>>>> Cc: Felix Fietkau <n...@nbd.name>
>>>>> Signed-off-by: Toke Høiland-Jørgensen <t...@toke.dk>
>>>>
>>>> Nice work.
>>> 
>>> Thanks :)
>>> 
>>>> Because this is such a significant change, and to maximise testing
>>>> time, I'm planning to queue this for 4.9 (so I would apply this to
>>>> ath-next in 3-4 weeks after the merge window closes). But anyone who
>>>> wants to test this can use master-pending branch from my ath.git tree
>>>> (uses wireless-testing as the baseline). Sounds good?
>>> 
>>> Sounds good to me. I'm planning on backporting this and Michael's
>>> mac80211 FQ-CoDel patches to 4.4 and post them for inclusion in LEDE.
>>> Hopefully that will get it some more testing as well.
>> I've pushed a backport of this into my LEDE staging tree:
>> https://git.lede-project.org/?p=lede/nbd/staging.git;a=summary
> 
> Awesome! What about the FQ-CoDel mac80211 patches themselves? I have a
> tree where I've separated out the needed patches and rebased them on
> mainline 4.4.9. Can I post that somewhere (or just email you the series)
> and get you to include those as well? Or do I just dump the patch files
> into the LEDE patches dir and send that as a patch to LEDE? (I see your
> patch also refreshed subsequent patches; is there a script to do that
> automatically?)
You don't need to do anything here. LEDE does not use mac80211 and
drivers from the kernel tree, it's built using backports.
It's currently using a backports snapshot that I built myself from
wireless-testing 2016-06-20, which already includes FQ-Codel.

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH v2] ath9k: Switch to using mac80211 intermediate software queues.

[Felix Fietkau]

On 2016-07-06 20:52, Toke Høiland-Jørgensen wrote:
> Felix Fietkau <n...@nbd.name> writes:
> 
>> On 2016-07-06 18:16, Toke Høiland-Jørgensen wrote:
>>> This switches ath9k over to using the mac80211 intermediate software
>>> queueing mechanism for data packets. It removes the queueing inside the
>>> driver, except for the retry queue, and instead pulls from mac80211 when
>>> a packet is needed. The retry queue is used to store a packet that was
>>> pulled but can't be sent immediately.
>>> 
>>> The old code path in ath_tx_start that would queue packets has been
>>> removed completely, as has the qlen limit tunables (since there's no
>>> longer a queue in the driver to limit).
>>> 
>>> Based on Tim's original patch set, but reworked quite thoroughly.
>>> 
>>> Cc: Tim Shepard <s...@alum.mit.edu>
>>> Cc: Felix Fietkau <n...@nbd.name>
>>> Signed-off-by: Toke Høiland-Jørgensen <t...@toke.dk>
>>> ---
>>> Changes since v1:
>>>   - Remove the old intermediate queueing logic completely instead of
>>> just disabling it.
>>>   - Remove the qlen debug tunables.
>>>   - Remove the force_channel parameter from struct txctl (since we just
>>> removed the code path that was using it).
>>> 
>>>  drivers/net/wireless/ath/ath9k/ath9k.h |  12 +-
>>>  drivers/net/wireless/ath/ath9k/channel.c   |   2 -
>>>  drivers/net/wireless/ath/ath9k/debug.c |  14 +-
>>>  drivers/net/wireless/ath/ath9k/debug.h |   2 -
>>>  drivers/net/wireless/ath/ath9k/debug_sta.c |   4 +-
>>>  drivers/net/wireless/ath/ath9k/init.c  |   2 +-
>>>  drivers/net/wireless/ath/ath9k/main.c  |   1 +
>>>  drivers/net/wireless/ath/ath9k/xmit.c  | 307 
>>> +++--
>>>  8 files changed, 130 insertions(+), 214 deletions(-)
>> Nice work!
> 
> Thanks :)
> 
>>> diff --git a/drivers/net/wireless/ath/ath9k/xmit.c 
>>> b/drivers/net/wireless/ath/ath9k/xmit.c
>>> index fe795fc..4077eeb 100644
>>> --- a/drivers/net/wireless/ath/ath9k/xmit.c
>>> +++ b/drivers/net/wireless/ath/ath9k/xmit.c
>>> @@ -912,8 +923,16 @@ ath_tx_get_tid_subframe(struct ath_softc *sc, struct 
>>> ath_txq *txq,
>>> seqno = bf->bf_state.seqno;
>>>  
>>> /* do not step over block-ack window */
>>> -   if (!BAW_WITHIN(tid->seq_start, tid->baw_size, seqno))
>>> +   if (!BAW_WITHIN(tid->seq_start, tid->baw_size, seqno)) {
>>> +   __skb_queue_tail(>retry_q, skb);
>>> +
>>> +   /* If there are other skbs in the retry q, they are
>>> +* probably within the BAW, so loop immediately to get
>>> +* one of them. Otherwise the queue can get stuck. */
>>> +   if (!skb_queue_is_first(>retry_q, skb))
>>> +   continue;
>> Not sure if this can happen, but if we ever somehow end up with two skbs
>> in the retry queue that do not fit into the Block-Ack window, there's
>> potential for an infinite loop here.
> 
> Yes, I realise that (v1 contained a comment on that). However, I don't
> actually think it can happen: The code will only ever put one skb from
> the intermediate queues on the retry queue (ath_tid_pull() is only
> called if the retry queue is empty). Everything else on there are actual
> retries that have been put on there by ath_tx_complete_aggr(). Figure
> the latter will always be within the BAW?
I think it would be a good idea to have a check there (with WARN_ON), in
case there's some weird corner case with seqno handling, software retry
and aggregation state changes.

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH v2] ath9k: Switch to using mac80211 intermediate software queues.

[Felix Fietkau]

On 2016-07-06 18:16, Toke Høiland-Jørgensen wrote:
> This switches ath9k over to using the mac80211 intermediate software
> queueing mechanism for data packets. It removes the queueing inside the
> driver, except for the retry queue, and instead pulls from mac80211 when
> a packet is needed. The retry queue is used to store a packet that was
> pulled but can't be sent immediately.
> 
> The old code path in ath_tx_start that would queue packets has been
> removed completely, as has the qlen limit tunables (since there's no
> longer a queue in the driver to limit).
> 
> Based on Tim's original patch set, but reworked quite thoroughly.
> 
> Cc: Tim Shepard <s...@alum.mit.edu>
> Cc: Felix Fietkau <n...@nbd.name>
> Signed-off-by: Toke Høiland-Jørgensen <t...@toke.dk>
> ---
> Changes since v1:
>   - Remove the old intermediate queueing logic completely instead of
> just disabling it.
>   - Remove the qlen debug tunables.
>   - Remove the force_channel parameter from struct txctl (since we just
> removed the code path that was using it).
> 
>  drivers/net/wireless/ath/ath9k/ath9k.h |  12 +-
>  drivers/net/wireless/ath/ath9k/channel.c   |   2 -
>  drivers/net/wireless/ath/ath9k/debug.c |  14 +-
>  drivers/net/wireless/ath/ath9k/debug.h |   2 -
>  drivers/net/wireless/ath/ath9k/debug_sta.c |   4 +-
>  drivers/net/wireless/ath/ath9k/init.c  |   2 +-
>  drivers/net/wireless/ath/ath9k/main.c  |   1 +
>  drivers/net/wireless/ath/ath9k/xmit.c  | 307 
> +++--
>  8 files changed, 130 insertions(+), 214 deletions(-)
Nice work!


> diff --git a/drivers/net/wireless/ath/ath9k/xmit.c 
> b/drivers/net/wireless/ath/ath9k/xmit.c
> index fe795fc..4077eeb 100644
> --- a/drivers/net/wireless/ath/ath9k/xmit.c
> +++ b/drivers/net/wireless/ath/ath9k/xmit.c
> @@ -912,8 +923,16 @@ ath_tx_get_tid_subframe(struct ath_softc *sc, struct 
> ath_txq *txq,
>   seqno = bf->bf_state.seqno;
>  
>   /* do not step over block-ack window */
> - if (!BAW_WITHIN(tid->seq_start, tid->baw_size, seqno))
> + if (!BAW_WITHIN(tid->seq_start, tid->baw_size, seqno)) {
> + __skb_queue_tail(>retry_q, skb);
> +
> + /* If there are other skbs in the retry q, they are
> +  * probably within the BAW, so loop immediately to get
> +  * one of them. Otherwise the queue can get stuck. */
> + if (!skb_queue_is_first(>retry_q, skb))
> + continue;
Not sure if this can happen, but if we ever somehow end up with two skbs
in the retry queue that do not fit into the Block-Ack window, there's
potential for an infinite loop here.

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH] ath9k: Switch to using mac80211 intermediate software queues.

[Felix Fietkau]

On 2016-07-04 19:46, Toke Høiland-Jørgensen wrote:
> Tim Shepard  writes:
> 
>> Thanks for unconfusing me a couple weeks ago, and cluing me into how
>> the limit on ->pending_frames is not really relevant for the data
>> packets that go through the new intermediate queues.
>>
>> But I'm not sure if this would allow us to remove the limit on
>> pending_frames because even though normal data packets would not
>> normally build up that many packets, there are other packet types
>> which bypass the intermediate queues and are transmitted directly
>> (also in most cases bypassing the ath9k internal queues in the way
>> ath9k worked before we patched it to use the mac80211 intermediate
>> queues).
> 
> Yes, but, well, since they're not queued they are not going to overflow
> anything. The aggregation building logic stops at two queued aggregates,
> so the default limit of 123 packets is never going to be hit when the
> queue is moved into the mac80211 layer. So keeping the knobs around only
> helps people who purposefully want to cripple their ability to do
> aggregation; and it won't be doing what it promises (limiting qlen),
> since that is now moved out of the driver. So IMO, removing the knobs is
> the right thing to do. I have already updated my patch to do so, which
> I'll send as a v2 once the other bits are resolved.
I agree.

>> Earlier Felix said:
>>
>>> Channel context based queue handling can be dealt with by
>>> stopping/starting relevant queues on channel context changes.
>>
>> But I don't see how to handle the case here where packets get passed
>> to the driver with ath_tx_start() and wind up in the scenario above.
> 
> Well, presumably the upper layers won't try to transmit anything through
> the old TX path if the start/stop logic is implemented properly. The
> chanctx code already seems to call the ieee80211_{start,stop}_queue()
> functions when changing context, so not sure what else is needed. Guess
> I'll go see if I can provoke an actual triggering of the bug, unless
> Felix elaborates on what he means before I get around to it (poke,
> Felix? :)).
Then I guess the logic in ath_tx_start was a leftover from a time before
some queue related rework happened to the chanctx code.
In that case you can simply remove the chanctx related software queueing
stuff from ath_tx_start.

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH RFC v2 1/2] Documentation: dt: net: add ath9k wireless device binding

[Felix Fietkau]

On 2016-06-27 14:57, Mark Rutland wrote:
> On Thu, Jun 23, 2016 at 08:14:29PM +0200, Martin Blumenstingl wrote:
>> On Thu, Jun 23, 2016 at 7:58 PM, Mark Rutland  wrote:
>> > On Thu, Jun 23, 2016 at 07:45:35PM +0200, Martin Blumenstingl wrote:
>> >> +- qca,eeprom-name: The name of the file which contains the EEPROM data 
>> >> (which
>> >> + will be loaded via request_firmware)
>> >
>> > The binding shouldn't know anything about the host filesystem,
>> > request_firmware, etc. So the description is a best a little off.
>> >
>> > What happens when a new FW comes out? I shouldn't have to update my DT
>> > to cater for that.
>> This is not exactly a "firmware" but rather device-specific
>> calibration data (RF settings, MAC address, etc). Usually there is an
>> eeprom connected directly to the wifi chip, but on embedded devices
>> this is usually skipped and instead the calibration data is shipped
>> somewhere on the main flash (directly on SPI-/NOR-/NAND flash,
>> sometimes even inside an UBI volume).
> 
> Ok. I believe that previously, for ath10k, it was suggested that this
> calibration data be placed directly in the DT (assuming it's small
> enough).
I don't think the data should go directly into DT, because then we need
a lot more complex kernel loader stubs. There are hundreds of devices
out there with calibration data in flash, and many of them have the data
in different places, and almost all of them don't support passing DT via
boot loader.
The actual RF settings are calibrated for every individual device, so
they need to be read from the flash partition anyway.
I think it makes sense to add an optional reference to a mtd partition
and allow the kernel to read from it directly.

>> > Please find a better way to identify relevant FW. What exactly affects
>> > which FW can be used, or would ideally be used? Are different FWs
>> > required for the same HW in some contexts?
>> >
>> > Can we not figure out the relevant FW names in the driver based on some
>> > identification mechanism (e.g. a more thoroughly defined set of
>> > compatible strings)?
>> The only way of auto-detecting a "correct" name would be via
>> dev_name() (with some prefix this could give something like
>> ath9k-pci-:00:0e.0.bin).
> 
> That may work, if the above is not an option.
I think that's a good idea.

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH v3 2/3] ath9k: add a helper to get the string representation of ath_bus_type

[Felix Fietkau]

On 2016-06-24 14:34, Martin Blumenstingl wrote:
> Signed-off-by: Martin Blumenstingl 
> ---
> this is a new patch which didn't exist in v2 yet, it prepares the new
> function ath_bus_type_to_string which will be used in patch #3
> 
>  drivers/net/wireless/ath/ath.h  |  2 ++
>  drivers/net/wireless/ath/main.c | 15 +++
>  2 files changed, 17 insertions(+)
> 
> diff --git a/drivers/net/wireless/ath/ath.h b/drivers/net/wireless/ath/ath.h
> index da7a7c8..be0d292 100644
> --- a/drivers/net/wireless/ath/ath.h
> +++ b/drivers/net/wireless/ath/ath.h
> @@ -327,4 +327,6 @@ static inline const char *ath_opmode_to_string(enum 
> nl80211_iftype opmode)
>  }
>  #endif
>  
> +const char *ath_bus_type_to_string(enum ath_bus_type bustype);
> +
>  #endif /* ATH_H */
> diff --git a/drivers/net/wireless/ath/main.c b/drivers/net/wireless/ath/main.c
> index 338d723..90427cb 100644
> --- a/drivers/net/wireless/ath/main.c
> +++ b/drivers/net/wireless/ath/main.c
> @@ -90,3 +90,18 @@ void ath_printk(const char *level, const struct 
> ath_common* common,
>   va_end(args);
>  }
>  EXPORT_SYMBOL(ath_printk);
> +
> +const char *ath_bus_type_to_string(enum ath_bus_type bustype)
> +{
> + switch (bustype) {
> + case ATH_PCI:
> + return "pci";
> + case ATH_AHB:
> + return "ahb";
> + case ATH_USB:
> + return "usb";
> + default:
> + return "unknown";
> + }
> +}
> +EXPORT_SYMBOL(ath_bus_type_to_string);
Why not simply add a const char* array with ath_bus_type as index?

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH 1/2] ath9k: use mac80211 intermediate software queues

[Felix Fietkau]

On 2016-06-17 15:48, Felix Fietkau wrote:
> On 2016-06-17 15:43, Toke Høiland-Jørgensen wrote:
>> Felix Fietkau <n...@nbd.name> writes:
>> 
>>> On 2016-06-17 11:09, Toke Høiland-Jørgensen wrote:
>>>> This patch leaves the code for ath9k's internal per-node per-tid
>>>> queues in place and just modifies the driver to also pull from
>>>> the new mac80211 intermediate software queues, and implements
>>>> the .wake_tx_queue method, which will cause mac80211 to deliver
>>>> packets to be sent via the new intermediate queue.
>>>> 
>>>> Signed-off-by: Tim Shepard <s...@alum.mit.edu>
>>>> 
>>>> Reworked to not require the global variable renaming in ath9k.
>>>> 
>>>> Signed-off-by: Toke Høiland-Jørgensen <t...@toke.dk>
>>>> ---
>>>>  drivers/net/wireless/ath/ath9k/ath9k.h |  16 +++-
>>>>  drivers/net/wireless/ath/ath9k/debug_sta.c |   7 +-
>>>>  drivers/net/wireless/ath/ath9k/init.c  |   1 +
>>>>  drivers/net/wireless/ath/ath9k/main.c  |   1 +
>>>>  drivers/net/wireless/ath/ath9k/xmit.c  | 119 
>>>> +
>>>>  5 files changed, 125 insertions(+), 19 deletions(-)
>>>> 
>>>> diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h 
>>>> b/drivers/net/wireless/ath/ath9k/ath9k.h
>>>> index 93b3793..caeae10 100644
>>>> --- a/drivers/net/wireless/ath/ath9k/ath9k.h
>>>> +++ b/drivers/net/wireless/ath/ath9k/ath9k.h
>>>> @@ -145,8 +145,6 @@ int ath_descdma_setup(struct ath_softc *sc, struct 
>>>> ath_descdma *dd,
>>>>  #define BAW_WITHIN(_start, _bawsz, _seqno) \
>>>>_seqno) - (_start)) & 4095) < (_bawsz))
>>>>  
>>>> -#define ATH_AN_2_TID(_an, _tidno)  (&(_an)->tid[(_tidno)])
>>>> -
>>>>  #define IS_HT_RATE(rate)   (rate & 0x80)
>>>>  #define IS_CCK_RATE(rate)  ((rate >= 0x18) && (rate <= 0x1e))
>>>>  #define IS_OFDM_RATE(rate) ((rate >= 0x8) && (rate <= 0xf))
>>>> @@ -232,8 +230,10 @@ struct ath_buf {
>>>>  
>>>>  struct ath_atx_tid {
>>>>struct list_head list;
>>>> +  struct sk_buff_head i_q;
>>> Do we really need a third queue here? Instead of adding yet another
>>> layer of queueing here, I think we should even get rid of buf_q.
>> 
>> This is definitely something that needs to be improved. One other
>> sticking point related to this: in the current version of this patch
>> ath_tid_has_buffered() gains a side effect of pulling from the mac80211
>> txq, which is obviously not so nice.
>> 
>> The obvious way to get rid of this is to export a txq_has_buffered()
>> function at the mac80211 layer. But avoiding that may be possible; the
>> sticking point is what to do with the code paths that do not dequeue
>> packets, but check ath_tid_has_buffered() to decide whether to schedule
>> the queue and/or to tell ieee80211_sta_set_buffered() about it (these
>> are for instance ath_tx_aggr_sleep/wakeup(). Can those just be removed
>> (i.e. don't call into ieee80211, and always schedule the txq on wakeup?
>> I'm not familiar enough with the intermediate queues to make that
>> call...
> For tx scheduling, we can use swq_nonempty and deal with false positives.
> For power save we should only use ieee80211_sta_set_buffered if the
> driver itself has buffered some frames. Indication of packets in the
> mac80211 intermediate queue is already taken care of inside mac80211.
One more thing that I forgot in my previous reply: on PS wakeup, the
driver does not need to schedule the intermediate queues itself -
mac80211 will call drv_wake_tx_queue if frames are pending.

- Felix

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH 1/2] ath9k: use mac80211 intermediate software queues

[Felix Fietkau]

On 2016-06-17 15:41, Tim Shepard wrote:
>> > diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h 
>> > b/drivers/net/wireless/ath/ath9k/ath9k.h
>> > index 93b3793..caeae10 100644
>> > --- a/drivers/net/wireless/ath/ath9k/ath9k.h
>> > +++ b/drivers/net/wireless/ath/ath9k/ath9k.h
>> > @@ -145,8 +145,6 @@ int ath_descdma_setup(struct ath_softc *sc, struct 
>> > ath_descdma *dd,
>> >  #define BAW_WITHIN(_start, _bawsz, _seqno) \
>> >_seqno) - (_start)) & 4095) < (_bawsz))
>> >  
>> > -#define ATH_AN_2_TID(_an, _tidno)  (&(_an)->tid[(_tidno)])
>> > -
>> >  #define IS_HT_RATE(rate)   (rate & 0x80)
>> >  #define IS_CCK_RATE(rate)  ((rate >= 0x18) && (rate <= 0x1e))
>> >  #define IS_OFDM_RATE(rate) ((rate >= 0x8) && (rate <= 0xf))
>> > @@ -232,8 +230,10 @@ struct ath_buf {
>> >  
>> >  struct ath_atx_tid {
>> >struct list_head list;
>> > +  struct sk_buff_head i_q;
>> Do we really need a third queue here? Instead of adding yet another
>> layer of queueing here, I think we should even get rid of buf_q.
>> 
>> Channel context based queue handling can be dealt with by
>> stopping/starting relevant queues on channel context changes.
>> 
>> buf_q becomes unnecessary when you remove all code in the drv_tx
>> codepath that moves frames to the intermediate queue.
>> 
>> Any frame that was pulled from the intermediate queue and prepared for
>> tx, but which can't be sent right now can simply be queued to retry_q.
>> 
>> This will also help with getting the diffstat insertion/deletion ratio
>> under control ;)
>> 
>> >struct sk_buff_head buf_q;
>> >struct sk_buff_head retry_q;
>> > +  struct ieee80211_txq *swq;
>> No need for this pointer, you can use container_of.
> 
> 
> Felix, great to hear from you and thanks for your feedback.  I will
> try to work on this.
> 
> I was struggling to understand the channel context stuff, and I have
> no idea how to test it.  (Is there anyone else listening who might be
> able to help with testing the channel context stuff as we improve this
> patch and simplify the ath9k driver's use of the new mac80211
> intermediate queues?)
> 
> 
> Felix, do you have any thoughts on the renaming of txq to hwx that I
> had done in my original version of this patch?  I had a good e-mail
> discussion with Toke a week or two ago (cc these same various lists)
> and I believe he came to understand that perhaps the renaming I had
> done in the original version of this patch was worth doing.
> 
> Now in Toke's version of my patch he calls the ieee80211 txq a "swq"
> and the ath9k hardware queue is called a "txq".  (I had called the
> ieee80211 txq a "txq" and I renamed the ath9k hardware queue "hwq"
> throught all the ath9k driver code.This also made ath9k's names of
> things more similar to mt76 which I was looking at as an example of a
> driver that uses your new ieee80211 txq mechanism.
> 
> I think the renaming is worth doing, but I also understand the
> renaming can be disruptive to others actively working on ath9k.
> It would be nice to have another opinion on this.
I think we should finish intermediate queues support first and then look
into the rename later.

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH 1/2] ath9k: use mac80211 intermediate software queues

[Felix Fietkau]

On 2016-06-17 15:43, Toke Høiland-Jørgensen wrote:
> Felix Fietkau <n...@nbd.name> writes:
> 
>> On 2016-06-17 11:09, Toke Høiland-Jørgensen wrote:
>>> This patch leaves the code for ath9k's internal per-node per-tid
>>> queues in place and just modifies the driver to also pull from
>>> the new mac80211 intermediate software queues, and implements
>>> the .wake_tx_queue method, which will cause mac80211 to deliver
>>> packets to be sent via the new intermediate queue.
>>> 
>>> Signed-off-by: Tim Shepard <s...@alum.mit.edu>
>>> 
>>> Reworked to not require the global variable renaming in ath9k.
>>> 
>>> Signed-off-by: Toke Høiland-Jørgensen <t...@toke.dk>
>>> ---
>>>  drivers/net/wireless/ath/ath9k/ath9k.h |  16 +++-
>>>  drivers/net/wireless/ath/ath9k/debug_sta.c |   7 +-
>>>  drivers/net/wireless/ath/ath9k/init.c  |   1 +
>>>  drivers/net/wireless/ath/ath9k/main.c  |   1 +
>>>  drivers/net/wireless/ath/ath9k/xmit.c  | 119 
>>> +
>>>  5 files changed, 125 insertions(+), 19 deletions(-)
>>> 
>>> diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h 
>>> b/drivers/net/wireless/ath/ath9k/ath9k.h
>>> index 93b3793..caeae10 100644
>>> --- a/drivers/net/wireless/ath/ath9k/ath9k.h
>>> +++ b/drivers/net/wireless/ath/ath9k/ath9k.h
>>> @@ -145,8 +145,6 @@ int ath_descdma_setup(struct ath_softc *sc, struct 
>>> ath_descdma *dd,
>>>  #define BAW_WITHIN(_start, _bawsz, _seqno) \
>>> _seqno) - (_start)) & 4095) < (_bawsz))
>>>  
>>> -#define ATH_AN_2_TID(_an, _tidno)  (&(_an)->tid[(_tidno)])
>>> -
>>>  #define IS_HT_RATE(rate)   (rate & 0x80)
>>>  #define IS_CCK_RATE(rate)  ((rate >= 0x18) && (rate <= 0x1e))
>>>  #define IS_OFDM_RATE(rate) ((rate >= 0x8) && (rate <= 0xf))
>>> @@ -232,8 +230,10 @@ struct ath_buf {
>>>  
>>>  struct ath_atx_tid {
>>> struct list_head list;
>>> +   struct sk_buff_head i_q;
>> Do we really need a third queue here? Instead of adding yet another
>> layer of queueing here, I think we should even get rid of buf_q.
> 
> This is definitely something that needs to be improved. One other
> sticking point related to this: in the current version of this patch
> ath_tid_has_buffered() gains a side effect of pulling from the mac80211
> txq, which is obviously not so nice.
> 
> The obvious way to get rid of this is to export a txq_has_buffered()
> function at the mac80211 layer. But avoiding that may be possible; the
> sticking point is what to do with the code paths that do not dequeue
> packets, but check ath_tid_has_buffered() to decide whether to schedule
> the queue and/or to tell ieee80211_sta_set_buffered() about it (these
> are for instance ath_tx_aggr_sleep/wakeup(). Can those just be removed
> (i.e. don't call into ieee80211, and always schedule the txq on wakeup?
> I'm not familiar enough with the intermediate queues to make that
> call...
For tx scheduling, we can use swq_nonempty and deal with false positives.
For power save we should only use ieee80211_sta_set_buffered if the
driver itself has buffered some frames. Indication of packets in the
mac80211 intermediate queue is already taken care of inside mac80211.

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH 1/2] ath9k: use mac80211 intermediate software queues

[Felix Fietkau]

On 2016-06-17 11:09, Toke Høiland-Jørgensen wrote:
> This patch leaves the code for ath9k's internal per-node per-tid
> queues in place and just modifies the driver to also pull from
> the new mac80211 intermediate software queues, and implements
> the .wake_tx_queue method, which will cause mac80211 to deliver
> packets to be sent via the new intermediate queue.
> 
> Signed-off-by: Tim Shepard 
> 
> Reworked to not require the global variable renaming in ath9k.
> 
> Signed-off-by: Toke Høiland-Jørgensen 
> ---
>  drivers/net/wireless/ath/ath9k/ath9k.h |  16 +++-
>  drivers/net/wireless/ath/ath9k/debug_sta.c |   7 +-
>  drivers/net/wireless/ath/ath9k/init.c  |   1 +
>  drivers/net/wireless/ath/ath9k/main.c  |   1 +
>  drivers/net/wireless/ath/ath9k/xmit.c  | 119 
> +
>  5 files changed, 125 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h 
> b/drivers/net/wireless/ath/ath9k/ath9k.h
> index 93b3793..caeae10 100644
> --- a/drivers/net/wireless/ath/ath9k/ath9k.h
> +++ b/drivers/net/wireless/ath/ath9k/ath9k.h
> @@ -145,8 +145,6 @@ int ath_descdma_setup(struct ath_softc *sc, struct 
> ath_descdma *dd,
>  #define BAW_WITHIN(_start, _bawsz, _seqno) \
>   _seqno) - (_start)) & 4095) < (_bawsz))
>  
> -#define ATH_AN_2_TID(_an, _tidno)  (&(_an)->tid[(_tidno)])
> -
>  #define IS_HT_RATE(rate)   (rate & 0x80)
>  #define IS_CCK_RATE(rate)  ((rate >= 0x18) && (rate <= 0x1e))
>  #define IS_OFDM_RATE(rate) ((rate >= 0x8) && (rate <= 0xf))
> @@ -232,8 +230,10 @@ struct ath_buf {
>  
>  struct ath_atx_tid {
>   struct list_head list;
> + struct sk_buff_head i_q;
Do we really need a third queue here? Instead of adding yet another
layer of queueing here, I think we should even get rid of buf_q.

Channel context based queue handling can be dealt with by
stopping/starting relevant queues on channel context changes.

buf_q becomes unnecessary when you remove all code in the drv_tx
codepath that moves frames to the intermediate queue.

Any frame that was pulled from the intermediate queue and prepared for
tx, but which can't be sent right now can simply be queued to retry_q.

This will also help with getting the diffstat insertion/deletion ratio
under control ;)

>   struct sk_buff_head buf_q;
>   struct sk_buff_head retry_q;
> + struct ieee80211_txq *swq;
No need for this pointer, you can use container_of.

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH 5/6] ath9k: Use defined constants consistently.

[Felix Fietkau]

On 2016-06-07 15:10, Benjamin Berg wrote:
> From: Benjamin Berg 
> 
> Signed-off-by: Benjamin Berg 
> ---
>  drivers/net/wireless/ath/ath9k/main.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/wireless/ath/ath9k/main.c 
> b/drivers/net/wireless/ath/ath9k/main.c
> index f2ebc85..6a81298 100644
> --- a/drivers/net/wireless/ath/ath9k/main.c
> +++ b/drivers/net/wireless/ath/ath9k/main.c
> @@ -1785,9 +1785,10 @@ static void ath9k_bss_info_changed(struct ieee80211_hw 
> *hw,
>   if ((avp->chanctx == sc->cur_chan) &&
>   (changed & BSS_CHANGED_ERP_SLOT)) {
>   if (bss_conf->use_short_slot)
> - slottime = 9;
> + slottime = ATH9K_SLOT_TIME_9;
>   else
> - slottime = 20;
> + slottime = ATH9K_SLOT_TIME_20;
Wouldn't it be better to just remove those pointless defines?

- Felix

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH v2] ath9k: interpret requested txpower in EIRP domain

[Felix Fietkau]

On 2016-05-17 12:54, Zefir Kurtisi wrote:
> On 05/14/2016 02:50 PM, Felix Fietkau wrote:
>> On 2016-04-01 11:37, Zefir Kurtisi wrote:
>>> Tx power limitations at upper layers are interpreted in
>>> the EIRP domain. When the user requests a given maximum
>>> txpower, e.g. with: 'iw phy0 set txpower fixed 1500',
>>> he expects the EIRP to be at or below 15dBm.
>>>
>>> In ath9k_hw_apply_txpower(), the interpretation is
>>> different: the antenna-gain is capped against the
>>> current txpower limit in the regulatory, but not
>>> against the user set value. It ensures that the
>>> resulting EIRP is below the limit defined by the
>>> active countrycode, but not below the value the
>>> user requested.
>>>
>>> In a scenario like e.g.
>>>  a) antenna_gain=6
>>>  b) countrycode limits to eirp=18
>>>  c) user set txpower=15
>>> this will cause a setting for AR_PHY_POWER_TX_RATE
>>> regs resulting in an EIRP > 15.
>>>
>>> This patch ensures that antenna-gain is considered
>>> whenever the txpower limit is adjusted and with that
>>> the user set limits are kept.
>>>
>>> Signed-off-by: Zefir Kurtisi <zefir.kurt...@neratec.com>
>> I just noticed this change and I believe it should be reverted. In many
>> cases the EEPROM antenna gain value does not accurately reflect the real
>> antenna gain and is used more as a worst case value to prevent exceeding
>> regulatory limits.
>> 
>> I believe using this to limit the user specified tx power values will
>> not only make this inconsistent with other drivers, but it will also
>> confuse users by using significantly lower tx power than they wanted.
>> 
>> The EEPROM antenna gain value is already causing more tx power reduction
>> than necessary, because AFAIK at least the FCC regulatory rules allow an
>> antenna gain of 3 dB while at the power limit, yet this is not
>> subtracted from the EEPROM antenna gain value when considering the limit.
>> 
>> - Felix
>> 
> Two things to be considered before reverting that commit:
> 1) the change affects only setups where a valid antenna gain value is set
> I checked some consumer ath9k cards I collected over time from (rather old) 
> WiFi
> routers - none of them have an antenna gain set in EEPROM. Therefore, none of 
> them
> would be affected by the change (alas I have no current ath9k NICs at hand to
> check if this is still valid). I'd argue that valid antenna gain values are 
> set by
> manufacturers or professional integrators who took time to calibrate and 
> measure
> the antennas' characteristics accurately.
Maybe not many NICs have antenna gain set, but I did see several
embedded devices with antenna gain set. Sometimes the value was set to
just 6 db, sometimes it was more than that.

> 2) EIRP is what matters
> As explained in the commit, every layer above the driver is interpreting 
> txpower
> in the EIRP domain. When you visit a certification lab and the engineer sets 
> a max
> txpower of 15dBm but measures an EIRP of 18 (as in the example above), the 
> device
> won't pass the test.
> 
> I think the latter point is a strong argument to leave the change intact.
I completely agree that this is something that needs fixing, but I think
this change is not the way to do it. On devices with detachable antennas
and a programmed antenna gain value in EEPROM this will make it really
hard for the user to set the right tx power, especially when using
different antennas. I think this is a serious regression.

A much better approach would be to expose the antenna gain to the stack,
filling in the default from the EEPROM. That way the user at least has a
chance to figure out what's going on if the tx power is too low and can
set the antenna gain value to something sane as opposed to whatever
potentially bogus value is in the EEPROM.

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH v2] ath9k: interpret requested txpower in EIRP domain

[Felix Fietkau]

On 2016-04-01 11:37, Zefir Kurtisi wrote:
> Tx power limitations at upper layers are interpreted in
> the EIRP domain. When the user requests a given maximum
> txpower, e.g. with: 'iw phy0 set txpower fixed 1500',
> he expects the EIRP to be at or below 15dBm.
> 
> In ath9k_hw_apply_txpower(), the interpretation is
> different: the antenna-gain is capped against the
> current txpower limit in the regulatory, but not
> against the user set value. It ensures that the
> resulting EIRP is below the limit defined by the
> active countrycode, but not below the value the
> user requested.
> 
> In a scenario like e.g.
>  a) antenna_gain=6
>  b) countrycode limits to eirp=18
>  c) user set txpower=15
> this will cause a setting for AR_PHY_POWER_TX_RATE
> regs resulting in an EIRP > 15.
> 
> This patch ensures that antenna-gain is considered
> whenever the txpower limit is adjusted and with that
> the user set limits are kept.
> 
> Signed-off-by: Zefir Kurtisi 
I just noticed this change and I believe it should be reverted. In many
cases the EEPROM antenna gain value does not accurately reflect the real
antenna gain and is used more as a worst case value to prevent exceeding
regulatory limits.

I believe using this to limit the user specified tx power values will
not only make this inconsistent with other drivers, but it will also
confuse users by using significantly lower tx power than they wanted.

The EEPROM antenna gain value is already causing more tx power reduction
than necessary, because AFAIK at least the FCC regulatory rules allow an
antenna gain of 3 dB while at the power limit, yet this is not
subtracted from the EEPROM antenna gain value when considering the limit.

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH] ath9k: Fix symbol overlap window for half/quarter channels

[Felix Fietkau]

On 2016-04-29 20:06, Helmut Schaa wrote:
> Since commit cd6cfd7311a385144a2f9c74f692ae2df3ae033f
> "ath9k: do not set half/quarter channel flags in AR_PHY_MODE" the
> condition "rfMode & (AR_PHY_MODE_QUARTER | AR_PHY_MODE_HALF)" would
> never evaluate to true.
> 
> Fix this by using the available IS_CHAN_HALF_RATE and IS_CHAN_QUARTER_RATE
> marcros instead.
> 
> Signed-off-by: Helmut Schaa <helmut.sc...@googlemail.com>
> Cc: Felix Fietkau <n...@openwrt.org>
> ---
> Just stumbled over that piece of code while looking into TX99, so
> this is only compile-tested.
> 
> Felix, can you please confirm if this is correct or if removing
> the whole block would be better?
This patch looks good to me.
Acked-by: Felix Fietkau <n...@openwrt.org>
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH 2/3] ath9k: make rxfilter per HW

[Felix Fietkau]

On 2015-06-22 13:59, Johannes Berg wrote:
 On Mon, 2015-06-22 at 13:58 +0200, Johannes Berg wrote:
 On Mon, 2015-06-22 at 13:43 +0200, Janusz Dziedzic wrote:
  mac80211 configure rxfilter per HW,
  so we don't need this per channel.
 
 As I said before, I think there's value in mac80211 doing it per chanctx
 or even per vif, and it should be more efficient to do so.
 
 It's tempting to do it per vif and leave the chanctx work up to the
 driver, but perhaps with CSA and all that it gets complicated enough
 that doing it per chanctx in mac80211 would make sense?
 
 On the other hand, I think our device requires it per vif, so we'd
 probably have to do both.
 
 +Andrei, who was looking into this.
There's value in it, but I think it makes more sense to fix this bug
now, and rework the code again later when mac80211 has support for
per-vif or per-chanctx rxfilter.

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [RFC] ath9k: allow to receive probe request when offchannel

[Felix Fietkau]

On 2015-06-10 07:03, Janusz Dziedzic wrote:
 This fix problem that p2p group negotiation didn't work
 correctly when chanctx used, because we didn't receive
 probe requests when offchannel and use_chanctx=1
 
 Signed-off-by: Janusz Dziedzic janusz.dzied...@tieto.com
 ---
 @Felix, Sujith could you review? I am not sure I put this in correct place.
 
  drivers/net/wireless/ath/ath9k/channel.c | 6 ++
  1 file changed, 6 insertions(+)
 
 diff --git a/drivers/net/wireless/ath/ath9k/channel.c 
 b/drivers/net/wireless/ath/ath9k/channel.c
 index 2066650..6301d44 100644
 --- a/drivers/net/wireless/ath/ath9k/channel.c
 +++ b/drivers/net/wireless/ath/ath9k/channel.c
 @@ -1157,6 +1157,7 @@ static bool ath_chanctx_defer_switch(struct ath_softc 
 *sc)
  static void ath_offchannel_channel_change(struct ath_softc *sc)
  {
   struct ath_common *common = ath9k_hw_common(sc-sc_ah);
 + u32 rfilt;
  
   ath_dbg(common, CHAN_CTX, %s: offchannel state: %s\n,
   __func__, offchannel_state_string(sc-offchannel.state));
 @@ -1179,6 +1180,11 @@ static void ath_offchannel_channel_change(struct 
 ath_softc *sc)
   ath_scan_complete(sc, false);
   break;
   case ATH_OFFCHANNEL_ROC_START:
 + /* Allow to receive probe requests */
 + rfilt = ath_calcrxfilter(sc);
 + rfilt |= ATH9K_RX_FILTER_PROBEREQ;
I think ath_calcrxfilter should set this, otherwise it might be
overwritten, e.g. on BB watchdog reset.

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH] ath9k: add phy.c

[Felix Fietkau]

On 2015-05-16 07:24, Oleksij Rempel wrote:
 Am 15.05.2015 um 21:34 schrieb Felix Fietkau:
 On 2015-05-15 14:35, Oleksij Rempel wrote:
 ... and move dup code from ar5008_phy.c and ar9002_phy.c to phy.c

 Signed-off-by: Oleksij Rempel li...@rempel-privat.de
 We already have base functionality for AR5008-AR9002 provided in some
 ar5008_phy.c, and ar5008_hw_attach_phy_ops is called for those chipsets
 as well. Please keep the de-duplicated code there instead of adding a
 new phy.c, because AR9003+ uses a completely different codepath.
 
 - Felix
 
 
 ok, thanks.
 Currently i celled this function phy_hw_spur_mitigate(), is it ok or
 there is some better name for this code?
Just use the ar5008 prefix like in the other functions.

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH] ath9k: add phy.c

[Felix Fietkau]

On 2015-05-15 14:35, Oleksij Rempel wrote:
 ... and move dup code from ar5008_phy.c and ar9002_phy.c to phy.c
 
 Signed-off-by: Oleksij Rempel li...@rempel-privat.de
We already have base functionality for AR5008-AR9002 provided in some
ar5008_phy.c, and ar5008_hw_attach_phy_ops is called for those chipsets
as well. Please keep the de-duplicated code there instead of adding a
new phy.c, because AR9003+ uses a completely different codepath.

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH 18/18] ath9k: use REG_RMW and rmw buffer in ath9k_hw_def_set_gain

[Felix Fietkau]

On 2015-03-20 13:38, Oleksij Rempel wrote:
 Signed-off-by: Oleksij Rempel li...@rempel-privat.de
 ---
  drivers/net/wireless/ath/ath9k/eeprom_def.c | 19 +++
  1 file changed, 11 insertions(+), 8 deletions(-)
 
 diff --git a/drivers/net/wireless/ath/ath9k/eeprom_def.c 
 b/drivers/net/wireless/ath/ath9k/eeprom_def.c
 index 0980590..4b43539 100644
 --- a/drivers/net/wireless/ath/ath9k/eeprom_def.c
 +++ b/drivers/net/wireless/ath/ath9k/eeprom_def.c
 @@ -466,6 +466,7 @@ static void ath9k_hw_def_set_gain(struct ath_hw *ah,
 struct ar5416_eeprom_def *eep,
 u8 txRxAttenLocal, int regChainOffset, int i)
  {
 + ENABLE_REG_RMW_BUFFER(ah);
   if (AR5416_VER_MASK = AR5416_EEP_MINOR_VER_3) {
   txRxAttenLocal = pModal-txRxAttenCh[i];
  
 @@ -483,16 +484,16 @@ static void ath9k_hw_def_set_gain(struct ath_hw *ah,
 AR_PHY_GAIN_2GHZ_XATTEN2_DB,
 pModal-xatten2Db[i]);
   } else {
 - REG_WRITE(ah, AR_PHY_GAIN_2GHZ + regChainOffset,
 + REG_RMW(ah, AR_PHY_GAIN_2GHZ + regChainOffset,
 (REG_READ(ah, AR_PHY_GAIN_2GHZ + regChainOffset) 
  ~AR_PHY_GAIN_2GHZ_BSW_MARGIN)
 | SM(pModal- bswMargin[i],
 -AR_PHY_GAIN_2GHZ_BSW_MARGIN));
 - REG_WRITE(ah, AR_PHY_GAIN_2GHZ + regChainOffset,
 +AR_PHY_GAIN_2GHZ_BSW_MARGIN), 0);
 + REG_RMW(ah, AR_PHY_GAIN_2GHZ + regChainOffset,
 (REG_READ(ah, AR_PHY_GAIN_2GHZ + regChainOffset) 
  ~AR_PHY_GAIN_2GHZ_BSW_ATTEN)
 | SM(pModal-bswAtten[i],
 -AR_PHY_GAIN_2GHZ_BSW_ATTEN));
 +AR_PHY_GAIN_2GHZ_BSW_ATTEN), 0);
   }
   }
  
 @@ -504,17 +505,19 @@ static void ath9k_hw_def_set_gain(struct ath_hw *ah,
 AR_PHY_RXGAIN + regChainOffset,
 AR9280_PHY_RXGAIN_TXRX_MARGIN, pModal-rxTxMarginCh[i]);
   } else {
 - REG_WRITE(ah,
 + REG_RMW(ah,
 AR_PHY_RXGAIN + regChainOffset,
 (REG_READ(ah, AR_PHY_RXGAIN + regChainOffset) 
  ~AR_PHY_RXGAIN_TXRX_ATTEN)
 -   | SM(txRxAttenLocal, AR_PHY_RXGAIN_TXRX_ATTEN));
 - REG_WRITE(ah,
 +   | SM(txRxAttenLocal, AR_PHY_RXGAIN_TXRX_ATTEN), 0);
 + REG_RMW(ah,
 AR_PHY_GAIN_2GHZ + regChainOffset,
 (REG_READ(ah, AR_PHY_GAIN_2GHZ + regChainOffset) 
  ~AR_PHY_GAIN_2GHZ_RXTX_MARGIN) |
 -   SM(pModal-rxTxMarginCh[i], 
 AR_PHY_GAIN_2GHZ_RXTX_MARGIN));
 +   SM(pModal-rxTxMarginCh[i],
 +   AR_PHY_GAIN_2GHZ_RXTX_MARGIN), 0);
   }
 + REG_RMW_BUFFER_FLUSH(ah);
Same in those chunks as in the other patch, do proper conversion to
REG_RMW by eliminating the REG_READ.

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH 16/18] ath9k: use REG_RMW and rmw buffer in ath9k_hw_4k_set_gain

[Felix Fietkau]

On 2015-03-20 13:38, Oleksij Rempel wrote:
 it is possible to reduce time needed for this function
 by rplacing REG_WRITE with REG_RMW (plus dummy 0) and putt all commands
 in same buffer.
 
 Signed-off-by: Oleksij Rempel li...@rempel-privat.de
 ---
  drivers/net/wireless/ath/ath9k/eeprom_4k.c | 18 ++
  1 file changed, 10 insertions(+), 8 deletions(-)
 
 diff --git a/drivers/net/wireless/ath/ath9k/eeprom_4k.c 
 b/drivers/net/wireless/ath/ath9k/eeprom_4k.c
 index 291c1d1..56621be 100644
 --- a/drivers/net/wireless/ath/ath9k/eeprom_4k.c
 +++ b/drivers/net/wireless/ath/ath9k/eeprom_4k.c
 @@ -772,15 +772,16 @@ static void ath9k_hw_4k_set_gain(struct ath_hw *ah,
struct ar5416_eeprom_4k *eep,
u8 txRxAttenLocal)
  {
 - REG_WRITE(ah, AR_PHY_SWITCH_CHAIN_0,
 -   pModal-antCtrlChain[0]);
 + ENABLE_REG_RMW_BUFFER(ah);
 + REG_RMW(ah, AR_PHY_SWITCH_CHAIN_0,
 + pModal-antCtrlChain[0], 0);
How about combining the WRITE/RMW buffering in ath9k_htc (automatically
deciding whether to use RMW or WRITE for the whole transaction), instead
of quirky looking REG_WRITE to REG_RMW conversions?

 - REG_WRITE(ah, AR_PHY_TIMING_CTRL4(0),
 -   (REG_READ(ah, AR_PHY_TIMING_CTRL4(0)) 
 -~(AR_PHY_TIMING_CTRL4_IQCORR_Q_Q_COFF |
 -  AR_PHY_TIMING_CTRL4_IQCORR_Q_I_COFF)) |
 -   SM(pModal-iqCalICh[0], AR_PHY_TIMING_CTRL4_IQCORR_Q_I_COFF) |
 -   SM(pModal-iqCalQCh[0], AR_PHY_TIMING_CTRL4_IQCORR_Q_Q_COFF));
 + REG_RMW(ah, AR_PHY_TIMING_CTRL4(0),
 + (REG_READ(ah, AR_PHY_TIMING_CTRL4(0)) 
 +  ~(AR_PHY_TIMING_CTRL4_IQCORR_Q_Q_COFF |
 +AR_PHY_TIMING_CTRL4_IQCORR_Q_I_COFF)) |
 + SM(pModal-iqCalICh[0], AR_PHY_TIMING_CTRL4_IQCORR_Q_I_COFF) |
 + SM(pModal-iqCalQCh[0], AR_PHY_TIMING_CTRL4_IQCORR_Q_Q_COFF), 
 0);
If you translate it to REG_RMW, you should get rid of the REG_READ part.

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH] ath9k: Configure beacons for AP vif if this has not happened yet

[Felix Fietkau]

On 2015-03-13 14:33, Benjamin Berg wrote:
 Right now there is a bug where beaconing might not be enabled correctly
 if the user has configuring multiple VIFs.
 The issue surfaces if the userspace first creates the AP devices and
 only then configures the first VIF (ath9k_bss_info_changed is called).
 In this case the current ath9k_allow_beacon_config implementation will
 not allow configuration as multiple AP VIFs are already present and
 beaconing is never configured in the driver.
 
 This issue was probably introduced back in 2012 by commit ef4ad6336
 ath9k: Cleanup beacon logic. The fix in this patch simply checks
 whether beaconing has been configured yet (or configuration is scheduled)
 and allows the configuration in that case. This works around the issue
 here, but I have no idea whether it is a sane solution.
 
 Signed-off-by: Benjamin Berg benja...@sipsolutions.net
I sent the following patch yesterday - I think it addresses the exact 
same issue. Please test it to see if it works for you as well.

Subject: [PATCH 4.0] ath9k: fix tracking of enabled AP beacons

sc-nbcnvifs tracks assigned beacon slots, not enabled beacons.
Therefore, it cannot be used to decide if cur_conf-enable_beacon (bool)
should be updated, or if beacons have been enabled already.
With the current code (depending on the order of calls), beacons often
do not get enabled in an AP+STA setup.
To fix tracking of enabled beacons, convert cur_conf-enable_beacon to a
bitmask of enabled beacon slots.

Cc: sta...@vger.kernel.org
Signed-off-by: Felix Fietkau n...@openwrt.org
---
 drivers/net/wireless/ath/ath9k/beacon.c | 20 
 drivers/net/wireless/ath/ath9k/common.h |  2 +-
 2 files changed, 13 insertions(+), 9 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/beacon.c 
b/drivers/net/wireless/ath/ath9k/beacon.c
index cb366ad..f50a6bc 100644
--- a/drivers/net/wireless/ath/ath9k/beacon.c
+++ b/drivers/net/wireless/ath/ath9k/beacon.c
@@ -219,12 +219,15 @@ void ath9k_beacon_remove_slot(struct ath_softc *sc, 
struct ieee80211_vif *vif)
struct ath_common *common = ath9k_hw_common(sc-sc_ah);
struct ath_vif *avp = (void *)vif-drv_priv;
struct ath_buf *bf = avp-av_bcbuf;
+   struct ath_beacon_config *cur_conf = sc-cur_chan-beacon;
 
ath_dbg(common, CONFIG, Removing interface at beacon slot: %d\n,
avp-av_bslot);
 
tasklet_disable(sc-bcon_tasklet);
 
+   cur_conf-enable_beacon = ~BIT(avp-av_bslot);
+
if (bf  bf-bf_mpdu) {
struct sk_buff *skb = bf-bf_mpdu;
dma_unmap_single(sc-dev, bf-bf_buf_addr,
@@ -521,8 +524,7 @@ static bool ath9k_allow_beacon_config(struct ath_softc *sc,
}
 
if (sc-sc_ah-opmode == NL80211_IFTYPE_AP) {
-   if ((vif-type != NL80211_IFTYPE_AP) ||
-   (sc-nbcnvifs  1)) {
+   if (vif-type != NL80211_IFTYPE_AP) {
ath_dbg(common, CONFIG,
An AP interface is already present !\n);
return false;
@@ -616,12 +618,14 @@ void ath9k_beacon_config(struct ath_softc *sc, struct 
ieee80211_vif *vif,
 * enabling/disabling SWBA.
 */
if (changed  BSS_CHANGED_BEACON_ENABLED) {
-   if (!bss_conf-enable_beacon 
-   (sc-nbcnvifs = 1)) {
-   cur_conf-enable_beacon = false;
-   } else if (bss_conf-enable_beacon) {
-   cur_conf-enable_beacon = true;
-   ath9k_cache_beacon_config(sc, ctx, bss_conf);
+   bool enabled = cur_conf-enable_beacon;
+
+   if (!bss_conf-enable_beacon) {
+   cur_conf-enable_beacon = ~BIT(avp-av_bslot);
+   } else {
+   cur_conf-enable_beacon |= BIT(avp-av_bslot);
+   if (!enabled)
+   ath9k_cache_beacon_config(sc, ctx, bss_conf);
}
}
 
diff --git a/drivers/net/wireless/ath/ath9k/common.h 
b/drivers/net/wireless/ath/ath9k/common.h
index 2b79a56..d237373 100644
--- a/drivers/net/wireless/ath/ath9k/common.h
+++ b/drivers/net/wireless/ath/ath9k/common.h
@@ -54,7 +54,7 @@ struct ath_beacon_config {
u16 dtim_period;
u16 bmiss_timeout;
u8 dtim_count;
-   bool enable_beacon;
+   u8 enable_beacon;
bool ibss_creator;
u32 nexttbtt;
u32 intval;
-- 2.2.2 --
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCHv2] ath9k_htc: add adaptive usb receive flow control to repair soft lockup with monitor mode

[Felix Fietkau]

On 2015-02-10 11:34, Yuwei Zheng wrote:
 The ath9k_hif_usb_rx_cb function excute on  the interrupt context, and 
 ath9k_rx_tasklet excute
 on the soft irq context. In other words, the ath9k_hif_usb_rx_cb have more 
 chance to excute than
 ath9k_rx_tasklet.  So in the worst condition,  the rx.rxbuf receive list is 
 always full,
 and the do {}while(true) loop will not be break. The kernel get a soft lockup 
 panic. 
  
 [59011.007210] BUG: soft lockup - CPU#0 stuck for 23s!
 [kworker/0:0:30609]
 [59011.030560] BUG: scheduling while atomic: kworker/0:0/30609/0x40010100
 [59013.804486] BUG: scheduling while atomic: kworker/0:0/30609/0x40010100
 [59013.858522] Kernel panic - not syncing: softlockup: hung tasks
  
 [59014.038891] Exception stack(0xdf4bbc38 to 0xdf4bbc80)
 [59014.046834] bc20:   
 de57b950 6113
 [59014.059579] bc40:  bb32bb32 6113 de57b948 de57b500 dc7bb440 
 df4bbcd0 
 [59014.072337] bc60: de57b950 6113 df4bbcd0 df4bbc80 c04c259d c04c25a0 
 6133 
 [59014.085233] [c04c28db] (__irq_svc+0x3b/0x5c) from [c04c25a0] 
 (_raw_spin_unlock_irqrestore+0xc/0x10)
 [59014.100437] [c04c25a0] (_raw_spin_unlock_irqrestore+0xc/0x10) from 
 [bf9c2089] (ath9k_rx_tasklet+0x290/0x490 [ath9k_htc])
 [59014.118267] [bf9c2089] (ath9k_rx_tasklet+0x290/0x490 [ath9k_htc]) from 
 [c0036d23] (tasklet_action+0x3b/0x98)
 [59014.134132] [c0036d23] (tasklet_action+0x3b/0x98) from [c0036709] 
 (__do_softirq+0x99/0x16c)
 [59014.147784] [c0036709] (__do_softirq+0x99/0x16c) from [c00369f7] 
 (irq_exit+0x5b/0x5c)
 [59014.160653] [c00369f7] (irq_exit+0x5b/0x5c) from [c000cfc3] 
 (handle_IRQ+0x37/0x78)
 [59014.173124] [c000cfc3] (handle_IRQ+0x37/0x78) from [c00085df] 
 (omap3_intc_handle_irq+0x5f/0x68)
 [59014.187225] [c00085df] (omap3_intc_handle_irq+0x5f/0x68) from 
 [c04c28db](__irq_svc+0x3b/0x5c)
  
 This bug can be see with low performance board, such as uniprocessor beagle 
 bone board. Add some debug 
 message in the ath9k_hif_usb_rx_cb function may trigger this bug quickly.
  
 Signed-off-by: Yuwei Zheng yuweizh...@139.com
This approach of interaction between tasklet and workqueue processing
seems quite complex to me. Wouldn't it be simpler and better to simply
always run the rx processing code in workqueue context?
That way it can go on processing forever (as long as there is data to be
received), while the scheduler ensures that it doesn't interfere with
other critical work on the CPU.

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] strange MPDU loss pattern

[Felix Fietkau]

Hi Seongho,

that paper looks quite interesting.
Are you planning to publish code/patches for your implementation as well?
It would be nice to have dynamic A-MPDU limiting integrated in minstrel_ht.

Thanks,

- Felix

On 26/10/2014 12:14 AM, Seongho Byeon wrote:

 Hi, I am Ph.d. student in Seoul National University , Korea.
 Recently, we have dealt with the problem you observe, and we published
 a paper into CoNEXT 2014 which is a major conference in our field.

 Title of the paper 'MoFa: Mobility-aware Frame Aggregation in WiFi
 networks'.
 You can download it a site below.
 http://www.mwnl.snu.ac.kr/~schoi/publication/Conferences/14-CONEXT-BYEON.pdf
 http://www.mwnl.snu.ac.kr/%7Eschoi/publication/Conferences/14-CONEXT-BYEON.pdf
 If you have a question please contact me anytime.

 Best regards,
 Seongho Byeon.

 Thank you for sharing the story.
 Even if I consider interference as a possibility, still I can't
 justify the higher
 chance of frame loss in the second half of the aggregate frame.

 We use

 PCI-express 3 antenna dual band cards
 product: AR93xx Wireless Network Adapter
 and/or
 Atheors AR5B97 which is a 2.4 GHz dual antenna internal card in a laptop

 we also tried TP-LINK TL-WDN4200 N900as the receiver.

 However we see the same results.
 we mostly use MCS 20-23, sgi = 0, 20 MHz channels.

 The loss pattern is something like this
 (each line is an imaginary aggregated frame and each bit is the fate
 of the MPDU)

 00011
 11100011010110100
 1
 111010100
 110010101

 The interesting part is that with the start of the next frame error
 rate goes down initially
 then it goes up again in the second portion of the packet.

 Best,
 Ali


 On 25/10/2014 2:30 PM, Adrian Chadd wrote:

 On 25 October 2014 08:28, Ali Abedia2ab...@uwaterloo.ca
 mailto:a2ab...@uwaterloo.cawrote:

 Hi Adrian, We have a high end spectrum analyzer. So we are
 sure there is no background interference We run our
 experiments in the 5 GHZ spectrum. The channel conditions can
 still vary due to the movement of the people in the vicinity
 of the experiment setup. We select a rate that experiences at
 least 20% error on average. Since if the error is 100% or 0%
 it's not interesting for us. My point is if the channel
 conditions change the distribution of failed packets should be
 uniform. The first and second half of the packets have the
 same chance to be received successfully.

 Here's a little story. My first wifi contract had me spend months
 trying to figure out why an AP was losing its mind. It'd get stuck
 in a stuck beacon loop and only a hard powercycle of /all/ of
 the access points in an area would clear it. It turned out that
 the PCB design had some non-grounded / non-populated tracks that
 just happened to form a 2GHz resonator. Once we grounded those
 tracks, the APs started behaving themselves. The company in
 question spent months with high end spectrum analysis kit in the
 lab (where it never happened) and underground (where it did
 happen.) It's only after they stuck the spectrum analyser probe
 _inside the access point_ right up close to the NIC did they see
 it. Here's the spectrum analyser traces. You can see the
 peak.http://www.creative.net.au/ath/So, weirder crap has happened.
 Which NICs and which MCS rates are you using? -adrian

 ___
 ath9k-devel mailing list
 ath9k-devel@lists.ath9k.org mailto:ath9k-devel@lists.ath9k.org
 https://lists.ath9k.org/mailman/listinfo/ath9k-devel

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [Cerowrt-devel] periodic hang of ath9k

[Felix Fietkau]

On 2014-07-14 06:25, Sujith Manoharan wrote:
 Dave Taht wrote:
 cc-ing ath9k-devel for this update on http://www.bufferbloat.net/issues/442
 
 this bug, which some people (usually on macs with low signal strength)
 can get to occur fairly rapidly, but I can't, is driving me 9 kinds of
 crazy...
 
 Does stock OpenWrt also have this bug, or is this specific to Cerowrt ?
After receiving some useful debug output from Antonio Quartulli (who
was able to reproduce it easily), I believe that I have tracked down
this issue to some bugs in counting pending tx frames. When frames get
pushed through the U-APSD queue for PS responses and dropped there due
to retransmissions, the counter probably does not get decremented
properly.

I've come up with an untested patch that should fix this codepath
and make it easier to verify.

If you're affected by the bug, please test this patch:
---
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -185,7 +185,8 @@ struct ath_atx_ac {
 
 struct ath_frame_info {
struct ath_buf *bf;
-   int framelen;
+   u16 framelen;
+   s8 txq;
enum ath9k_key_type keytype;
u8 keyix;
u8 rtscts_rate;
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -147,15 +147,13 @@ static void ath_set_rates(struct ieee802
 static void ath_txq_skb_done(struct ath_softc *sc, struct ath_txq *txq,
 struct sk_buff *skb)
 {
-   int q;
-
-   q = skb_get_queue_mapping(skb);
-   if (txq == sc-tx.uapsdq)
-   txq = sc-tx.txq_map[q];
+   struct ath_frame_info *fi = get_frame_info(skb);
+   int q = fi-txq;
 
-   if (txq != sc-tx.txq_map[q])
+   if (q  0)
return;
 
+   txq = sc-tx.txq_map[q];
if (WARN_ON(--txq-pending_frames  0))
txq-pending_frames = 0;
 
@@ -1999,6 +1997,7 @@ static void setup_frame_info(struct ieee
an = (struct ath_node *) sta-drv_priv;
 
memset(fi, 0, sizeof(*fi));
+   fi-txq = -1;
if (hw_key)
fi-keyix = hw_key-hw_key_idx;
else if (an  ieee80211_is_data(hdr-frame_control)  an-ps_key  0)
@@ -2150,6 +2149,7 @@ int ath_tx_start(struct ieee80211_hw *hw
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
struct ieee80211_sta *sta = txctl-sta;
struct ieee80211_vif *vif = info-control.vif;
+   struct ath_frame_info *fi = get_frame_info(skb);
struct ath_softc *sc = hw-priv;
struct ath_txq *txq = txctl-txq;
struct ath_atx_tid *tid = NULL;
@@ -2170,11 +2170,13 @@ int ath_tx_start(struct ieee80211_hw *hw
q = skb_get_queue_mapping(skb);
 
ath_txq_lock(sc, txq);
-   if (txq == sc-tx.txq_map[q] 
-   ++txq-pending_frames  sc-tx.txq_max_pending[q] 
-   !txq-stopped) {
-   ieee80211_stop_queue(sc-hw, q);
-   txq-stopped = true;
+   if (txq == sc-tx.txq_map[q]) {
+   fi-txq = q;
+   if (++txq-pending_frames  sc-tx.txq_max_pending[q] 
+   !txq-stopped) {
+   ieee80211_stop_queue(sc-hw, q);
+   txq-stopped = true;
+   }
}
 
if (txctl-an  ieee80211_is_data_present(hdr-frame_control))
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [RFCv2 09/10] ath9k: disable dynack algorithm when coverage class is set

[Felix Fietkau]

On 2014-07-13 12:18, Lorenzo Bianconi wrote:
 Disable ack timeout estimation algorithm if the coverage class has been
 configured
 
 Signed-off-by: Lorenzo Bianconi lorenzo.biancon...@gmail.com
I think this is broken, since it doesn't allow you to re-enable dynack
through the same way as it was disabled.
I would recommend adding an 'auto' value for coverage class.

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [RFC 03/10] ath9k: add dynamic ack timeout estimation

[Felix Fietkau]

On 2014-07-07 13:41, Thomas Hühn wrote:

 +{
 +struct ath_node *an;
 +u32 to = 0;
 +struct ath_dynack *da = ah-dynack;
 +struct ath_common *common = ath9k_hw_common(ah);
 +
 
 +list_for_each_entry(an, da-nodes, list)
 +if (an-ackto  to)
 +to = an-ackto;
 +
 
 This list parsing would probably need rcu protection like:
   
   rcu_read_lock();
   list_for_each_entry(an, da-nodes, list)
   if (an-ackto  to)
   to = an-ackto;
   rcu_read_unlock();
Nope, that's already done in the calling code.

 I am not sure that you need to call the entire function with spin_lock as you 
 do it now.
 
 +if (to  da-ackto != to) {
 +u32 slottime;
 +
 +slottime = (to - 3) / 2;
 
 Should the case to  3 be covered or is it safe to have potentially slottime 
 = 0 ?
slottime should never be 0. It is not user configurable.

 +/**
 + * ath_dynack_compute_to - compute ack timeout
 + * @ah: ath hw
 + *
 + * should be called while holding qlock
 + */
 +static void ath_dynack_compute_to(struct ath_hw *ah)
 +{
 +u32 ackto, ack_ts;
 +u8 *dst, *src;
 +struct ieee80211_sta *sta;
 +struct ath_node *an;
 +struct ts_info *st_ts;
 +struct ath_dynack *da = ah-dynack;
 +
 +rcu_read_lock();
 +
 +while (da-st_rbf.h_rb != da-st_rbf.t_rb 
 +   da-ack_rbf.h_rb != da-ack_rbf.t_rb) {
 +ack_ts = da-ack_rbf.tstamp[da-ack_rbf.h_rb];
 +st_ts = da-st_rbf.ts[da-st_rbf.h_rb];
 +dst = da-st_rbf.addr[da-st_rbf.h_rb].h_dest;
 +src = da-st_rbf.addr[da-st_rbf.h_rb].h_src;
 +
 +ath_dbg(ath9k_hw_common(ah), DYNACK,
 +ack_ts %u st_ts %u st_dur %u [%u-%u]\n,
 +ack_ts, st_ts-tstamp, st_ts-dur,
 +da-ack_rbf.h_rb, da-st_rbf.h_rb);
 +
 +if (ack_ts  st_ts-tstamp + st_ts-dur) {
 +ackto = ack_ts - st_ts-tstamp - st_ts-dur;
 +
 +if (ackto  MAX_DELAY) {
 +sta = ieee80211_find_sta_by_ifaddr(ah-hw, dst,
 +   src);
 +if (sta) {
 +an = (struct ath_node *)sta-drv_priv;
 +an-ackto = DYNACK_EWMA((u32)ackto,
 +an-ackto);
 +ath_dbg(ath9k_hw_common(ah), DYNACK,
 +%pM to %u\n, dst, an-ackto);
 +if (time_is_before_jiffies(da-lto)) {
 +ath_dynack_compute_ackto(ah);
 +da-lto = jiffies + COMPUTE_TO;
 +}
 +}
 +INCR(da-ack_rbf.h_rb, ATH_DYN_BUF);
 +}
 +INCR(da-st_rbf.h_rb, ATH_DYN_BUF);
 +} else {
 +INCR(da-ack_rbf.h_rb, ATH_DYN_BUF);
 +}
 +}
 +
 +rcu_read_unlock();
 
 I think it is sufficient to have the rcu_read_unlock just around
 ieee80211_find_sta_by_ifaddr(). So the lock does not need to
 include the whole while loop under lock.
That doesn't make things any better - rcu_read_lock is not like a normal
lock. Doing it once outside of the loop is not only simpler, but also
slightly more efficient.

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH] ath9k: fix NULL-deref in hw_per_calibration() for ar9002

[Felix Fietkau]

On 2014-05-07 21:54, John W. Linville wrote:
 On Wed, May 07, 2014 at 09:22:58AM +0200, David Herrmann wrote:
 ah-caldata may be NULL if no channel is selected. Check for that before
 accessing it.
 
 Signed-off-by: David Herrmann dh.herrm...@gmail.com
 ---
 Hi
 
 This is _definitely_ only a workaround, given that no-one guarantees 
 ah-caldata
 is freed while we run in hw_per_calibration(). However, this patch fixes 
 serious
 kernel panics with wifi-P2P on my machine.
 
 I'm not sure why ah-caldata can be NULL, but it definitely is. I think the
 correct fix would be to synchronously stop any running hw-calibration before
 setting ah-caldata to NULL. I don't know whether/where that is done, so I 
 wrote
 this small workaround.
 
 Thanks
 David
 
 Is there any hope for getting a more complete fix from the ath9k guys
 in short order?
This looks easy to fix. I'll send a patch soon.

- Felix

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH 2/2] ath9k: add a recv budget

[Felix Fietkau]

On 2014-04-29 14:04, Tim Harvey wrote:
 On Tue, Apr 22, 2014 at 2:09 AM, Felix Fietkau n...@openwrt.org wrote:
 On 2014-04-22 01:14, Tim Harvey wrote:
 Implement a recv budget so that in cases of high traffic we still allow 
 other
 taskets to get processed.

 Without this, we can encounter a host of issues during high wireless traffic
 reception depending on system load including rcu stall's detected (ARM),
 soft lockups, failure to service critical tasks such as watchdog resets,
 and triggering of the tx stuck tasklet.

 The same thing was proposed previously by Ben:
  http://www.spinics.net/lists/linux-wireless/msg112891.html

 The only difference here is that I make sure only processed packets are 
 counted
 in the budget by checking at the end of the rx loop.

 Signed-off-by: Tim Harvey thar...@gateworks.com
 For both patches:
 Acked-by: Felix Fietkau n...@openwrt.org

 
 +cc ath9k-devel@lists.ath9k.org
 +cc Ben Greear
 
 Any other ack's or comments on these? These address some fairly
 long-standing bugs.
No need for further ack's or comments, since the change has been picked
up by John already.

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] extreme latency, regression in 3.13.7

[Felix Fietkau]

On 2014-04-19 10:28, Balogh Maria wrote:
 Hi,
 
 I bisected a regression in ath9k and ended up at this commit:
 179c5b22373511b9e8f73183f03d89e92278ab3e
 (558ff225de80ac95b132d3a115ddadcd64498b4f upstream): ath9k: fix ps-poll
 responses under a-mpdu sessions
 
 My Sparklan WPEA-127N card (168c:0030), which works in 802.11n AP mode with
 hostapd, works with extreme latencies after this commit and becomes
 absolutely unusable.
 
 Oddly enough, this commit is supposed to fix high latencies, but I haven't
 seen problems before this.
 
 I'd be happy to help in further investigation.
Please try applying this commit to your tree (if you don't have it already)


commit 5998be879719384af2014b79697eed6e38ee2706
Author: Helmut Schaa helmut.sc...@googlemail.com
Date:   Wed Mar 12 10:37:55 2014 +0100

ath9k: Fix sequence number assignment for non-data frames

Since commit 558ff225de80ac95b132d3a115ddadcd64498b4f (ath9k: fix
ps-poll responses under a-mpdu sessions) non-data frames would have
gotten a sequence number from a TIDs sequence counter instead of
using the global sequence counter.

This can lead to instable connections.

To fix this only select the correct TID if we are processing a
data frame. Furthermore, prevent non-data frames to get a sequence
number from a TID sequence counter by adding a check to
ath_tx_setup_buffer.

Cc: Felix Fietkau n...@openwrt.org
Signed-off-by: Helmut Schaa helmut.sc...@googlemail.com
Acked-by: Felix Fietkau n...@openwrt.org
Signed-off-by: John W. Linville linvi...@tuxdriver.com

diff --git a/drivers/net/wireless/ath/ath9k/xmit.c 
b/drivers/net/wireless/ath/ath9k/xmit.c
index f042a18..55897d5 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -2063,7 +2063,7 @@ static struct ath_buf *ath_tx_setup_buffer(struct 
ath_softc *sc,
 
ATH_TXBUF_RESET(bf);
 
-   if (tid) {
+   if (tid  ieee80211_is_data_present(hdr-frame_control)) {
fragno = le16_to_cpu(hdr-seq_ctrl)  IEEE80211_SCTL_FRAG;
seqno = tid-seq_next;
hdr-seq_ctrl = cpu_to_le16(tid-seq_next  
IEEE80211_SEQ_SEQ_SHIFT);
@@ -2186,7 +2186,7 @@ int ath_tx_start(struct ieee80211_hw *hw, struct sk_buff 
*skb,
txq-stopped = true;
}
 
-   if (txctl-an)
+   if (txctl-an  ieee80211_is_data_present(hdr-frame_control))
tid = ath_get_skb_tid(sc, txctl-an, skb);
 
if (info-flags  IEEE80211_TX_CTL_PS_RESPONSE) {

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH] ath9k: Prevent divide by zero kernel crash.

[Felix Fietkau]

On 2014-04-17 02:40, gree...@candelatech.com wrote:
 From: Ben Greear gree...@candelatech.com
 
 Make sure we cannot ever assign beacon interval to zero.
 
 Signed-off-by: Ben Greear gree...@candelatech.com
 ---
  drivers/net/wireless/ath/ath9k/beacon.c | 4 
  drivers/net/wireless/ath/ath9k/recv.c   | 3 ++-
  2 files changed, 6 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/net/wireless/ath/ath9k/beacon.c 
 b/drivers/net/wireless/ath/ath9k/beacon.c
 index 2e8bba0..5391f01 100644
 --- a/drivers/net/wireless/ath/ath9k/beacon.c
 +++ b/drivers/net/wireless/ath/ath9k/beacon.c
 @@ -443,6 +443,8 @@ static u32 ath9k_mod_tsf64_tu(u64 tsf, u32 div_tu)
  {
   u32 tsf_mod, tsf_hi, tsf_lo, mod_hi, mod_lo;
  
 + if (WARN_ON_ONCE(div_tu == 0))
 + div_tu = 100;
   tsf_mod = tsf  (BIT(10) - 1);
   tsf_hi = tsf  32;
   tsf_lo = ((u32) tsf)  10;
Why add this warning here if you already have the additions below? We
don't need multiple layers of defensive checks for the same thing.

 @@ -667,6 +669,8 @@ static void ath9k_cache_beacon_config(struct ath_softc 
 *sc,
   Caching beacon data for BSS: %pM\n, bss_conf-bssid);
  
   cur_conf-beacon_interval = bss_conf-beacon_int;
 + if (WARN_ON_ONCE(cur_conf-beacon_interval == 0))
 + cur_conf-beacon_interval = 100;
   cur_conf-dtim_period = bss_conf-dtim_period;
   cur_conf-listen_interval = 1;
   cur_conf-dtim_count = 1;
 diff --git a/drivers/net/wireless/ath/ath9k/recv.c 
 b/drivers/net/wireless/ath/ath9k/recv.c
 index b97217d..79c20c7 100644
 --- a/drivers/net/wireless/ath/ath9k/recv.c
 +++ b/drivers/net/wireless/ath/ath9k/recv.c
 @@ -538,7 +538,8 @@ static void ath_rx_ps_beacon(struct ath_softc *sc, struct 
 sk_buff *skb)
   sc-ps_flags = ~PS_BEACON_SYNC;
   ath_dbg(common, PS,
   Reconfigure beacon timers based on synchronized 
 timestamp\n);
 - ath9k_set_beacon(sc);
 + if (!(WARN_ON_ONCE(sc-cur_beacon_conf.beacon_interval == 0)))
 + ath9k_set_beacon(sc);
   }
  
   if (ath_beacon_dtim_pending_cab(skb)) {
 

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [RFC] ath9k: use more than one slot per bss for multicast in staggered mode

[Felix Fietkau]

On 2014-03-10 15:40, Michael Braun wrote:
 Before, ath9k divided time in ATH_BCBUF many equally sized slots.
 Each bss then was assigned to a single slot, leaving some or more slots empty.
 The beacons of a bss were sent at the beginning of the slot for this bss,
 and then the buffered multicast packets might be sent out.
 
 As multicast packets are sent a lowest bitrate, wireless throughput
 of multicast packets is very limited, and thus the time available
 is crucial to avoid buffer overflow, which I frequently observed.
I think in setups where you need to be able to send more multicast
packets, you should consider increasing the multicast rate.

 This patch changes the behaviour of ath9k in two ways:
  1. the time available when processing a slot is increased
 to cover all subsequent unoccupied slots as well.
 This size is tracked in the variable named slotwidth.
I think we should not allow multicast transmission to eat up too much
airtime during the beacon interval. If APs are flooded with multicast
packets, it must not drown out useful unicast traffic.

  2. during each slot, buffered packets from *all* bss are
 sent out in a round-robin fashing, skipping those
 bss where stations are currently not listing.
 That could be either due to
   - last dtim did not containt the relevant flag or
   - a multicast packet not containing the more data
 flag was sent out.
 The state is tracked in multicastWakeup, which is
 true iff the stations in this bss should already
 be woken up.
That does not seem like a good idea to me. Powersave clients waking up
to receive multicast packets should be allowed to go to sleep again as
soon as possible. Keeping them awake unnecessarily by not clearing the
more data bit at the last packet make them eat more power.

 I currently don't know whether a non-buffered multicast packet
 can slip between buffered packets (or between dtim notification
 and the first buffered packet), so that an STA receives a
 multicast packet without MOREDATA set while there a still
 buffered packets to be received and just short before being
 delivered on-air.
The CAB queue gets enabled after a beacon and then takes priority over
all other queues. No packets will slip in between once its transmission
starts.

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] Slow connection when using eduroam (AR9285)

[Felix Fietkau]

On 2014-02-23 20:44, Marco André Dinis wrote:
 Hi
 
 I started downloding a file and this is the output from ''dmesg'' (less
 than 30 sec)
 
 [  167.654939] wlp5s0: associated
 [  167.654953] IPv6: ADDRCONF(NETDEV_CHANGE): wlp5s0: link becomes ready
 [  174.900658] net_ratelimit: 47 callbacks suppressed
 [  174.900663] ath: phy0: discard current packet, more: 0
 [  175.700585] ath: phy0: discard current packet, more: 0
Please revert the last patch, and check if the connection works better
with this one:
---
diff --git a/drivers/net/wireless/ath/ath9k/recv.c 
b/drivers/net/wireless/ath/ath9k/recv.c
index a0ebdd0..82e340d 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -732,11 +732,18 @@ static struct ath_rxbuf *ath_get_next_rx_buf(struct 
ath_softc *sc,
return NULL;
 
/*
-* mark descriptor as zero-length and set the 'more'
-* flag to ensure that both buffers get discarded
+* Re-check previous descriptor, in case it has been filled
+* in the mean time.
 */
-   rs-rs_datalen = 0;
-   rs-rs_more = true;
+   ret = ath9k_hw_rxprocdesc(ah, ds, rs);
+   if (ret == -EINPROGRESS) {
+   /*
+* mark descriptor as zero-length and set the 'more'
+* flag to ensure that both buffers get discarded
+*/
+   rs-rs_datalen = 0;
+   rs-rs_more = true;
+   }
}
 
list_del(bf-list);
@@ -985,32 +992,32 @@ static int ath9k_rx_skb_preprocess(struct ath_softc *sc,
struct ath_common *common = ath9k_hw_common(ah);
struct ieee80211_hdr *hdr;
bool discard_current = sc-rx.discard_next;
-   int ret = 0;
 
/*
 * Discard corrupt descriptors which are marked in
 * ath_get_next_rx_buf().
 */
-   sc-rx.discard_next = rx_stats-rs_more;
if (discard_current)
-   return -EINVAL;
+   goto corrupt;
+
+   sc-rx.discard_next = false;
 
/*
 * Discard zero-length packets.
 */
if (!rx_stats-rs_datalen) {
RX_STAT_INC(rx_len_err);
-   return -EINVAL;
+   goto corrupt;
}
 
-/*
- * rs_status follows rs_datalen so if rs_datalen is too large
- * we can take a hint that hardware corrupted it, so ignore
- * those frames.
- */
+   /*
+* rs_status follows rs_datalen so if rs_datalen is too large
+* we can take a hint that hardware corrupted it, so ignore
+* those frames.
+*/
if (rx_stats-rs_datalen  (common-rx_bufsize - 
ah-caps.rx_status_len)) {
RX_STAT_INC(rx_len_err);
-   return -EINVAL;
+   goto corrupt;
}
 
/* Only use status info from the last fragment */
@@ -1024,10 +1031,8 @@ static int ath9k_rx_skb_preprocess(struct ath_softc *sc,
 * This is different from the other corrupt descriptor
 * condition handled above.
 */
-   if (rx_stats-rs_status  ATH9K_RXERR_CORRUPT_DESC) {
-   ret = -EINVAL;
-   goto exit;
-   }
+   if (rx_stats-rs_status  ATH9K_RXERR_CORRUPT_DESC)
+   goto corrupt;
 
hdr = (struct ieee80211_hdr *) (skb-data + ah-caps.rx_status_len);
 
@@ -1043,18 +1048,15 @@ static int ath9k_rx_skb_preprocess(struct ath_softc *sc,
if (ath_process_fft(sc, hdr, rx_stats, rx_status-mactime))
RX_STAT_INC(rx_spectral);
 
-   ret = -EINVAL;
-   goto exit;
+   return -EINVAL;
}
 
/*
 * everything but the rate is checked here, the rate check is done
 * separately to avoid doing two lookups for a rate for each frame.
 */
-   if (!ath9k_rx_accept(common, hdr, rx_status, rx_stats, decrypt_error)) {
-   ret = -EINVAL;
-   goto exit;
-   }
+   if (!ath9k_rx_accept(common, hdr, rx_status, rx_stats, decrypt_error))
+   return -EINVAL;
 
if (ath_is_mybeacon(common, hdr)) {
RX_STAT_INC(rx_beacons);
@@ -1064,15 +1066,11 @@ static int ath9k_rx_skb_preprocess(struct ath_softc *sc,
/*
 * This shouldn't happen, but have a safety check anyway.
 */
-   if (WARN_ON(!ah-curchan)) {
-   ret = -EINVAL;
-   goto exit;
-   }
+   if (WARN_ON(!ah-curchan))
+   return -EINVAL;
 
-   if (ath9k_process_rate(common, hw, rx_stats, rx_status)) {
-   ret =-EINVAL;
-   goto exit;
-   }
+   if (ath9k_process_rate(common, hw, rx_stats, rx_status))
+   return -EINVAL;
 
ath9k_process_rssi(common, hw, rx_stats, rx_status);
 
@@ 

Re: [ath9k-devel] [PATCH] ath9k: Fix ETSI compliance for AR9462 2.0

[Felix Fietkau]

On 2014-02-17 03:27, Sujith Manoharan wrote:
 Felix Fietkau wrote:
 Wouldn't it be better to do this for all AR93xx chipsets in
 ar9003_hw_apply_minccapwr_thresh instead of initvals?
 I'm pretty sure this patch will leave most other devices non-compliant.
 
 The threshold values are adjusted for each chip and are not the same
 for all chips in the AR9003 family, so this is done in the initvals.
Almost all chips are using the same values in the initvals - the
exceptions seem to be the ones that have had ETSI compliance fix
attempts already. I'm pretty sure the new values (if adjusted for
different bands) would be fully compatible.

 ar9003_hw_apply_minccapwr_thresh() will be used only for chips which
 contain the new 'MinCCApwr' field in struct ar9300_BaseExtension_1.
 This is not present in almost all the AR9003-family chips. I believe it has
 been introduced in AR955x.
I know. What I meant is that in case the EEPROM does not have any
values, we can make it use reasonable fixed defaults, thus overriding
the values from the initvals.

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] Interrupt mitigation for USB Atheros dongles

[Felix Fietkau]

On 2014-02-14 02:45, Dimosthenis Pediaditakis wrote:
 Hi all,
 I am using a capacity and available bandwidth measurement software that
 compute estimates based on the gaps among packet trains/pairs.
 
 For that reason I need to disable RX/TX interrupt mitigation for the
 devices that I take the measurement form, because it introduces skew,
 and renders unmeasurable the fast links ( 54Kbps).
 The less latencies the drivers+kernel introduces, the better.
 
 I have so far managed to disable all together the RX mitigation for
 mini-PCIe devices by hard-coding  the following line in
  linux/drivers/net/wireless/ath/ath9k/ hw.c
 ah-config.rx_intr_mitigation = false;
It seems to me that a better way to do this would be to drop your
fragile software based time measurement of rx interrupts, and instead
use the hardware timestamp (measured in microseconds).

 While the above trick improves my results, it doesn't change the
 behaviour of the Atheros-based USB WiFi dongles.
 AFAIK my TP-Link TL-WN722N USB dongle uses the ath9k_htc driver, but I
 haven't found anything relevant in the respective sources ( htc_*.{c, h} )
There is no interrupt mitigation here.

 Apart from that, I suspect that the USB-net driver itself might also
 introduce some fixed delays which affect the minimum time-spacing
 measurement that my software can perceive at the receiver side.
USB in general adds too much latency for what you want to do.
Use hardware timestamps here as well.

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH] ath9k: Fix ETSI compliance for AR9462 2.0

[Felix Fietkau]

On 2014-02-14 03:45, Sujith Manoharan wrote:
 From: Sujith Manoharan c_man...@qca.qualcomm.com
 
 The minimum CCA power threshold values have to be adjusted
 for existing cards to be in compliance with new regulations.
 Newer cards will make use of the values obtained from EEPROM,
 support for this was added earlier. To make sure that cards
 that are already in use and don't have proper values in EEPROM,
 do not violate regulations, use the initvals instead.
 
 Cc: sta...@vger.kernel.org
 Reported-by: Jeang Daniel dyje...@qca.qualcomm.com
 Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
Wouldn't it be better to do this for all AR93xx chipsets in
ar9003_hw_apply_minccapwr_thresh instead of initvals?
I'm pretty sure this patch will leave most other devices non-compliant.

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH 05/13] ath9k_htc: add rx header converter to make it usable by ath9k

[Felix Fietkau]

On 2014-02-03 12:22, Oleksij Rempel wrote:
 Am 03.02.2014 03:09, schrieb Sujith Manoharan:
 Oleksij Rempel wrote:
 +   rx_stats = kzalloc(sizeof(struct ath_rx_status), GFP_KERNEL);
 +   if (unlikely(rx_stats == NULL)) {
 +   ath_err(common, rx_stats allocation filed!\n);
 +   goto err_nofree;
 +   }
 +   rx_status_htc_to_ath(rx_stats, rxbuf-rxstatus);
 +
 
 This seems a little expensive, since this would happen for every packet,
 and a memcpy is already done earlier, for storing the RX status in
 rxbuf-rxstatus. Instead of using 'struct ath_htc_rx_status' in
 'struct ath9k_htc_rxbuf', why can't 'struct ath_rx_status' be used ?
 The values can be converted and stored directly, avoiding this alloc.
 
 Do you mean kzalloc or converter?
 then memcpy is removed by patch 12/13. Converter is not effective but it
 should prevent from confusions. At least until FW use same flags and
 struct ath_rx_status do.
 But i'm open for other ideas too.
You should at least keep rx_stats on stack instead of using kzalloc,
that would make it much faster.

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH] ath9k: Fix uninitialized variable in ath9k_has_tx_pending()

[Felix Fietkau]

On 2014-01-26 11:53, Geert Uytterhoeven wrote:
 drivers/net/wireless/ath/ath9k/main.c: In function ‘ath9k_has_tx_pending’:
 drivers/net/wireless/ath/ath9k/main.c:1869: warning: ‘npend’ may be used 
 uninitialized in this function
 
 Introduced by commit 10e2318103f5941aa70c318afe34bc41f1b98529 (ath9k:
 optimize ath9k_flush).
 
 Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org
Acked-by: Felix Fietkau n...@openwrt.org
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [Cerowrt-devel] Wireless failures 3.10.17-3

[Felix Fietkau]

On 2013-12-13 10:48, Sebastian Moeller wrote:
 Hi Sujith,
 
 On Dec 13, 2013, at 10:27 , Sujith Manoharan suj...@msujith.org wrote:
 
 Sebastian Moeller wrote:
 It is a net gear WNDR3700 v2, so according to:
 http://wiki.openwrt.org/toh/netgear/wndr3700 it is a Atheros AR7161 rev 2 
 680
 MHz soc with the following wireless parts: Atheros AR9223 802.11bgn / 
 Atheros
 AR9220 802.11an.
 
 Sure, I hope I got the right one. Now this is not from the same boot as the
 one with the errors, but I assume that does not make a difference… Since I 
 am
 located in Germany I set the regulatory domain to DE. please let me know if 
 I
 you need any additional information or testing (note I am not set up to 
 build
 cerowrt myself, so I would need Dave Täht's help to build a modified 
 firmware)
 
 Can you try this patch ?
 
   I will, but it will take some time, as I cannot build the firmware for 
 this device myself, but need help. So I let you know once I tested the 
 patched kernel.
On OpenWrt/CeroWrt you should not patch it into the kernel. You need to
add it as a patch for package/kernel/mac80211.

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [OpenWrt-Devel] ath9k (ad-hoc?) problems in compat-wireless trunk as of sept 6/2

[Felix Fietkau]

On 2013-09-09 1:29 PM, Nicolás Echániz wrote:
 I have kept testing this and was able to reproduce the same problem
 every time.
 The performance perception when the network is at rush hour is very
 unstable so I tried to reproduce traffic conditions during late night.
 I sent multiple netperfs through different routes and while the netperfs
 were running turned of one node. Latency climbed to the thousands and it
 took a while for it to stabilize again.
 
 Then I turned off another node, latency went sky high again for some
 seconds until I lost conectivity and could monitor no more.
 
 I waited more than 15 minutes for the net to be reachable again from my
 local node. (Nodes are automatically reset when they cannot reach the
 network gateway for more than 15 minutes)
 
 All ping tests are done on fe80 local IPv6 addresses so no routing
 protocol is involved in case someone's wondering. Also, from what I see
 (iw station dump), routers are associated but can send no data.
I've committed some fixes that might be related to this issue. Please
test current OpenWrt trunk.

Thanks,

- Felix

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH 2/2] ath9k: Run the LNA combining algorithm properly

[Felix Fietkau]

On 2013-08-07 8:59 AM, Sujith Manoharan wrote:
 From: Sujith Manoharan c_man...@qca.qualcomm.com
 
 The LNA combining algorithm has to be run for cards
 that support the required diversity features, make
 sure that that correct conditions are met before
 enabing this algorithm.
 
 Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
 ---
  drivers/net/wireless/ath/ath9k/recv.c | 46 
 ++-
  1 file changed, 29 insertions(+), 17 deletions(-)
 
 diff --git a/drivers/net/wireless/ath/ath9k/recv.c 
 b/drivers/net/wireless/ath/ath9k/recv.c
 index 865e043..e359557 100644
 --- a/drivers/net/wireless/ath/ath9k/recv.c
 +++ b/drivers/net/wireless/ath/ath9k/recv.c
 @@ -1156,7 +1156,8 @@ int ath_rx_tasklet(struct ath_softc *sc, int flush, 
 bool hp)
   struct ath_buf *bf;
   struct sk_buff *skb = NULL, *requeue_skb, *hdr_skb;
   struct ieee80211_rx_status *rxs;
 - struct ath_hw *ah = sc-sc_ah;
 + struct ath_hw *ah = sc-sc_ah
 +;struct ath9k_hw_capabilities *pCap = ah-caps;
   struct ath_common *common = ath9k_hw_common(ah);
   struct ieee80211_hw *hw = sc-hw;
   struct ieee80211_hdr *hdr;
Misplaced semicolon
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] ath9k AR9380 packets take long to be sent

[Felix Fietkau]

On 2013-08-06 6:04 PM, Michael Braun wrote:
 On Tue, Aug 06, 2013 at 01:18:51PM +0200, Michael Braun wrote:
   Also, can you please test
   with the latest one (I just committed some more fixes).
 
 those have been running for for some hours and I could not reproduce the 
 problem anymore, although before it used to reproduce quickly.
Great, thanks for testing. Let me know if any other issues show up.

- Felix

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] sensitivity control for ath9k with mac80211

[Felix Fietkau]

On 2013-07-19 4:58 PM, Sergey Ryazanov wrote:
 2013/7/19 Ben Greear gree...@candelatech.com:
 On 07/19/2013 06:36 AM, Flavio Leonel wrote:
 Ok i know that but the command iw not permited set sensitivity limit

 how i can seting this limit on atth9k , this question..

 I tried messing with this some months ago and got nowhere.  I could
 not figure any way to make the NIC ignore fainter signals, and I am
 not sure it is possible to make the hardware do this...

 
 At least 5k chips have a special register for CCA threshold
 configuration. Modern 9k chips have not inherited this register?
The CCA threshold is not the same as the threshold for signal detection.
In many ways, 5k and 9k cards have a somewhat similar set of registers
to configure various aspects of detection sensitivity. Some of those are
set in the initvals, some are controlled by ANI.
The main issue is that the driver does not expose any convenient knobs
to control this.

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] AR9331 ath9k driver init fails when using mtd

[Felix Fietkau]

On 2013-07-16 2:46 PM, Gerrit van der Bij wrote:
  
 
 Hi,
 
 I have a small project where I used a 32 Mbyte flash in a TP-Link MR-11U
 running OpenWrt AA. The device is based on the AR9331 chip. The kernel
 disables the SPI interface of the AR9331, so the flash is no longer
 memory mapped.
 
 To compensate for this, I added a function in ar9003_eeprom.c for
 restoring the ar9300_eeprom struct from an mtd partition named 'art'.
 The struct is at offset 0x1000 in that partition. That seems to work,
 because the driver now loads with no complaints, and all fields of the
 struct match the expected values read from flash.
 
 The function gets called instead of ar9003_hw_eeprom_restore_from_flash()
 
 However, radio refuses to be enabled and 'ifconfig -a' shows a MAC of
 'ff:ff:ff:ff:ff:ff'. 
 
 I found one item with similar properties on this mailing list that
 suggests that rx_chainmask is set wrong
 (http://www.mail-archive.com/ath9k-devel@lists.ath9k.org/msg06354.html),
 but its a different SoC and my old flash chip (containing stock openWRT
 with AA) was capable of using the WiFi with the correct MAC address. So
 I am assuming this would not apply to my issue? 
 
 Some help in the right direction for fixing this would be highly
 appreciated, I'm not an expert on the artheros drivers ...
Accessing mtd partitions from within the driver is the wrong approach.
OpenWrt fills the platform data with the partition contents in the
platform setup. You should be able to do something like that without
changing the driver at all.

- Felix

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] AP Limitation because of ATH9K_HTC_MAX_STA

[Felix Fietkau]

On 2013-07-09 10:50 AM, Oleksij Rempel wrote:
 How replacing AP with about MESH or AdHock+BATMAN?
Why? That sounds like a recipe for disaster to me (at least for
conference networks). The ath9k_htc stuff can't handle more peers in
mesh/ad-hoc than clients in AP mode.
In setting up a conference network, you have to think about what the
primary bottleneck is. When using consumer APs, the bottleneck isn't
CPU/RAM, it's usually limited channel airtime!

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] AP Limitation because of ATH9K_HTC_MAX_STA

[Felix Fietkau]

On 2013-07-09 11:34 AM, Oleksij Rempel wrote:
 Am 09.07.2013 11:18, schrieb Felix Fietkau:
 On 2013-07-09 10:50 AM, Oleksij Rempel wrote:
 How replacing AP with about MESH or AdHock+BATMAN?
 Why? That sounds like a recipe for disaster to me (at least for
 conference networks). The ath9k_htc stuff can't handle more peers in
 mesh/ad-hoc than clients in AP mode.
 In setting up a conference network, you have to think about what the
 primary bottleneck is. When using consumer APs, the bottleneck isn't
 CPU/RAM, it's usually limited channel airtime!

 - Felix

 
 Not with ath9k_htc. AdHock+BATMAN can be split in different groups on 
 different channels. ath9k_htc can be used as STA to  primer AP and 
 second interface on some laptops. But sure -- it is worst case scenario 
 with no extra cost.
What does this have to do with handling wifi clients of 200-300
participants?

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] performance with ath9k, sparklan WPEA-127N, and Macbook pro

[Felix Fietkau]

On 2013-06-20 6:05 PM, Adam Allred wrote:
 Hello,
 
 I am attempting to build an AP that can support airplay streaming
 between various mac devices. My current test bed is as follows:
 
 Macbook Pro 10,2 (13 Retina), with an Airport Extreme (0x14E4, 0x10F)
 card, which is using the BCM43xx driver (according to system report).
 Apple TV Gen 3 (no idea what the wireless hardware in it is)
 
 A Jetway Mini-top:
 
 http://www.newegg.com/Product/Product.aspx?Item=N82E16856107081
 
 It's running fully patched debian stable (wheezy), amd64.
 
 I have replaced the stock PCI Express wireless card with a SparkLan WPEA-127N:
 
 http://www.sparklan.com/product.php?func=viewprod_id=181
 
 and added two antennas to the top of the case utilizing these:
 
 http://www.embeddedworks.net/pdetail.php?mn=assyprod=assy085
 http://www.embeddedworks.net/pdetail.php?mn=anteprod=ante542
 
 The darn WPEA-127N came world-roaming burned in to the EEPROM, so I
 modified the ath9k driver from the stock debian wheezy driver using:
 
 https://patchwork.kernel.org/patch/2249511/
 
 (thanks Ben)
 
 and for good measure, also updated regulatory.bin for crda to map
 regdomain 0 to the US (where I'm at).
 
 Finally, my modprobe settings for ath9k are:
 
 options ath9k override_eeprom_regdomain=0
 options ath9k nohwcrypt=1
Using nohwcrypt=1 is a bad idea and might explain your performance
issues. Where did you get that from?

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] performance with ath9k, sparklan WPEA-127N, and Macbook pro

[Felix Fietkau]

On 2013-06-20 6:49 PM, Adam Allred wrote:
 I picked it up off of
 
 http://ubuntuforums.org/showthread.php?t=1746326
 
 and only tried it after I had a working connection, just to see if it
 would make a difference, since it's ubuntu and a AR92xx series card in
 that post. Performance is the same both with and without this option.
OK. Better leave it out from now on, it's not a good idea to use random
workarounds for old issues on a different wifi chip :)

I think you should start by using more recent drivers, Linux 3.2 is a
bit old. Pick up a recent compat-drivers release -
https://backports.wiki.kernel.org/index.php/Releases

Also, how exactly are you measuring performance?

Once you have the new release installed and are running some performance
tests, it would be helpful to post the contents of
/sys/kernel/debug/ieee80211/phy0/netdev\:wlan0/stations/*/rc_stats

It'll show how well the individual 802.11n rates are working.

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] Is there a way to connect pairs of wifi cards to achieve full duplex

[Felix Fietkau]

On 2013-06-20 12:26 PM, David Goodenough wrote:
 On Wednesday 19 Jun 2013, Ben Greear wrote:
 On 06/19/2013 03:56 PM, Adrian Chadd wrote:
  .. just keep in mind that adjacent high power transmitters can
  actually leak enough RF to trigger ADC saturation and thus the device
  may actually not try to decode anything.
  
  Thus, whilst your TX is TXing, the RX side may be unhappy. :-)
 
 We've had decent multi-NIC throughput when there is a mostly-solid
 aluminium chassis plate between the NICs, and when one is on 2.4
 and the other is on 5Ghz.
 
 Pretty much anything else is pushing your luck though :)
 
 Ben
 The only place I have noticed that do this with wifi kit is Microtik
 who say they can do setups like this - but as usual with them there is
 no indication of how it is done under the covers.
They're doing it with hacked up proprietary protocol modifications.

So I get why you would want to do combine two links to get full-duplex.
But why would you want to mess around with things like ACKs?

- Felix

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] Is there a way to connect pairs of wifi cards to achieve full duplex

[Felix Fietkau]

On 2013-06-20 8:13 PM, David Goodenough wrote:
 On Thursday 20 Jun 2013, Felix Fietkau wrote:
 On 2013-06-20 12:26 PM, David Goodenough wrote:
  On Wednesday 19 Jun 2013, Ben Greear wrote:
  On 06/19/2013 03:56 PM, Adrian Chadd wrote:
   .. just keep in mind that adjacent high power transmitters can
   actually leak enough RF to trigger ADC saturation and thus the device
   may actually not try to decode anything.
   
   Thus, whilst your TX is TXing, the RX side may be unhappy. :-)
  
  We've had decent multi-NIC throughput when there is a mostly-solid
  aluminium chassis plate between the NICs, and when one is on 2.4
  and the other is on 5Ghz.
  
  Pretty much anything else is pushing your luck though :)
  
  Ben
  
  The only place I have noticed that do this with wifi kit is Microtik
  who say they can do setups like this - but as usual with them there is
  no indication of how it is done under the covers.
 
 They're doing it with hacked up proprietary protocol modifications.
 
 So I get why you would want to do combine two links to get full-duplex.
 But why would you want to mess around with things like ACKs?
 
 - Felix
 Most of my links are quite long, so removing any turnaround had got to
 be a good thing (hasn't it?).  I presume that every time the link turns
 around you have to turn off the receive path (or at least disconnect it)
 and then power up the transmitter, and allow time for the receiver at 
 the other end to sync.  Then at the receiving end if it was transmitting
 before (this is point to point) it has to shut down the transmit path
 in an orderly fashion so that it remains loaded while active. Surely that has 
 to take a significant time?
The rx/tx switching time is very short, short enough to be
insignificant. The inter-frame duration, slot time, etc. are
significantly longer, but aggregation effectively cuts it down to a
fraction relative to the number of packets.
With a lot of changes to the software it would be possible to disable
the on-chip ACK functionality, retransmission, etc.
However, I think the disadvantages outweigh the advantages, mainly due
to the extra latency of processing lots of things in software that are
currently accelerated by the hardware.
The increase in complexity is not particularly nice either.

- Felix

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] Disable BAW sliding

[Felix Fietkau]

On 2013-06-14 3:51 PM, shinnazar wrote:
 Hi all,
 
 Is there anybody who worked on BAW(Block Ack Window) sliding mechanism
 in ath9k? Is it possible to disable this mechanism?
What would you want to do that for? It seems to me that all this would
accomplish is to get the tx path stuck after a number of packets were sent.

- Felix

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH] mac80211: Use RCU protection in ieee80211_get_tx_rates()

[Felix Fietkau]

On 2013-06-12 10:00 AM, Calvin Owens wrote:
 Copying the rate table should be done in an RCU read-side critical
 section.
I think this approach is wrong. The sta entry is also under RCU
protection (no locking for read access in that part of the code.
In a normal driver tx path, no extra rcu_read_lock/rcu_read_unlock is
needed. Only if the driver does some scheduling outside of the tx
function (which ath9k does), this RCU warning appears.

How about this change instead:
---
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -1570,6 +1570,8 @@ void ath_txq_schedule(struct ath_softc *
txq-axq_ampdu_depth = ATH_AGGR_MIN_QDEPTH)
return;
 
+   rcu_read_lock();
+
ac = list_first_entry(txq-axq_acq, struct ath_atx_ac, list);
last_ac = list_entry(txq-axq_acq.prev, struct ath_atx_ac, list);
 
@@ -1608,8 +1610,10 @@ void ath_txq_schedule(struct ath_softc *
 
if (ac == last_ac ||
txq-axq_ampdu_depth = ATH_AGGR_MIN_QDEPTH)
-   return;
+   break;
}
+
+   rcu_read_unlock();
 }
 
 /***/

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH 7/7] ath10k: detect htt pending tx limit at runtime

[Felix Fietkau]

On 2013-05-16 11:09 AM, Michal Kazior wrote:
 The real limit for sending htt tx is either
 msdu_id storage type (u16 - 65536 different
 values) or the HIF tx pipe queue length (2047 in
 case of our PCI HIF).
 
 The htt tx pipe does not use interrupts - it must
 be polled. It is polled either on RX
 unconditionally or on TX if HIF tx pipe has used
 over 50% of the resources.
 
 With this patch we should finally trigger the TX
 polling properly. What this really means we should
 have a smoother tx. Not because the tx limit is
 greater, but simply because we'll be triggering
 the polling properly in case of heavy tx.
 
 Signed-off-by: Michal Kazior michal.kaz...@tieto.com
I think a queue length of 2047 is completely excessive. It causes way
too much buffering and latency under load, and I suspect it may be
significantly hurting TCP throughput as well (if TCP manages to get the
queue filled up).
As long as there is no way to dynamically determine a *reasonable* queue
size, introducing an arbitrary limit is *much* better than just letting
the firmware gobble up as much as it wants.
For reference: ath9k limits the number of pending tx packets to 128 per
WMM queue, and even at the highest MCS rates with 3x3 and HT40 this is
much more than what's actually needed.

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] minstrel_ht: problems with HT40

[Felix Fietkau]

On 2013-05-09 3:42 PM, Oleksij Rempel wrote:
 Hallo Felix,
 
 i found your patches for moving ath9k to minstrel_ht and decided to do 
 some testing.
 For some reason, minstrel_ht exclude all HT40 rates in my network. With 
 native ath9k rate controller I'm able to use HT40.
 Do you have any idea where to start digging?
Do the rates not even show up in the debugfs rate control stats? If so,
check the value of sta-bandwidth at the time minstrel_ht_update_caps()
is called.

- Felix

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] minstrel_ht: problems with HT40

[Felix Fietkau]

On 2013-05-09 5:09 PM, Oleksij Rempel wrote:
 Am 09.05.2013 16:41, schrieb Felix Fietkau:
 On 2013-05-09 3:42 PM, Oleksij Rempel wrote:
 Hallo Felix,

 i found your patches for moving ath9k to minstrel_ht and decided to do
 some testing.
 For some reason, minstrel_ht exclude all HT40 rates in my network. With
 native ath9k rate controller I'm able to use HT40.
 Do you have any idea where to start digging?
 Do the rates not even show up in the debugfs rate control stats?
 
 correct
 
 If so,
 check the value of sta-bandwidth at the time minstrel_ht_update_caps()
 is called.
 
 hmm... for some reasons sta-bandwidth is always 0.
OK, maybe it's a mac80211 issue then. Maybe ath9k rate control checks
this field even between HT capability updates.
Check when/where this is updated in mac80211.

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] AR9380 frequent disconnect and stucks in AP mode.

[Felix Fietkau]

On 2013-05-07 2:03 PM, Bhavesh Kamani wrote:
 
 Hi Ben,
 
 I tried compat-drivers-3.9-rc4-2-su, then also same problem I faced.
 I also tried compat-wireless-2.6.39-1 and compat-wireless-3.6.8-1, but
 facing the same issue.
 
 In a day more than one clients are facing the same issue.
 
 In the locked state, ping from client to AP not working and tcpdump on AP
 shows the echo response sent on wlan interface. Only few clients are facing
 this issue frequently, but those clients don't have identical WiFi hardware.
 
 Is it possible for hardware/firmware to drop the tx packets for particular
 client? For me look like only data packets are getting dropped.
 My environment is noisy, will it affect this situation?
You should also upgrade hostapd to something recent. It's relevant for
AP mode stability as well.

- Felix

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH 1/2] ath9k_htc: add STBC TX support

[Felix Fietkau]

On 2013-05-04 8:50 AM, Oleksij Rempel wrote:
 Am 02.05.2013 22:15, schrieb Adrian Chadd:
 Well, let's dig into the firmware a bit more and tidy up how STBC is handled.
 
 Does it mean, i should change this patch and provide a patch for 
 firmware too?
 I still do not think, changing peer caps i a good idea in any case.
 I mena this part of patch:
 +   if (sta-ht_cap.cap  IEEE80211_HT_CAP_TX_STBC)
 +   caps |= WLAN_RC_TX_STBC_FLAG;
 
 
 Behaviour with this patch will be fallowing:
 - peer provide caps, even if it is RX-STBC12
 - we pass this information to firmware and ratecontroller of FW, do 
 right decision based on hardware it has.
 
 You suggestion, if i understand it correctly, is to filter caps:
 - if peer provide more than we can, we should tell firmware the value 
 what we can. So, if peer say it can RX-STBC12, we should tell firmware 
 that peer is RX-STBC1.
 In my opinion, this kind of filter is a source for hidden errors.
I think the discussion regarding RX-STBC12 vs RX-STBC1 is purely
hypothetical. The hardware that this firmware was designed for only
supports sending STBC for MCS0-7. This will not change.

Also, there's no reason to tell the firmware about both rx and tx STBC
capabilities, the only thing it needs to know is what tells the rate
control part to enable/disable STBC.

In addition to that, using the WLAN_RC_* flags is wrong, you need to use
the ATH_RC_* flags, as this is what ath_rate_newassoc_11n checks for in
the firmware. The only STBC related flag that actually gets used (when
passed from the driver) is ATH_RC_RX_STBC_FLAG.

- Felix

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH 1/2] ath9k_htc: add STBC TX support

[Felix Fietkau]

On 2013-05-04 1:08 PM, Oleksij Rempel wrote:
 Am 04.05.2013 12:02, schrieb Felix Fietkau:
 On 2013-05-04 8:50 AM, Oleksij Rempel wrote:
 Am 02.05.2013 22:15, schrieb Adrian Chadd:
 Well, let's dig into the firmware a bit more and tidy up how STBC is 
 handled.

 Does it mean, i should change this patch and provide a patch for
 firmware too?
 I still do not think, changing peer caps i a good idea in any case.
 I mena this part of patch:
 +   if (sta-ht_cap.cap  IEEE80211_HT_CAP_TX_STBC)
 +   caps |= WLAN_RC_TX_STBC_FLAG;


 Behaviour with this patch will be fallowing:
 - peer provide caps, even if it is RX-STBC12
 - we pass this information to firmware and ratecontroller of FW, do
 right decision based on hardware it has.

 You suggestion, if i understand it correctly, is to filter caps:
 - if peer provide more than we can, we should tell firmware the value
 what we can. So, if peer say it can RX-STBC12, we should tell firmware
 that peer is RX-STBC1.
 In my opinion, this kind of filter is a source for hidden errors.
 I think the discussion regarding RX-STBC12 vs RX-STBC1 is purely
 hypothetical. The hardware that this firmware was designed for only
 supports sending STBC for MCS0-7. This will not change.

 Also, there's no reason to tell the firmware about both rx and tx STBC
 capabilities, the only thing it needs to know is what tells the rate
 control part to enable/disable STBC.
 
 As you can see, in version 2 of this path there was no more discussion 
 about it. I just did it.
 
 In addition to that, using the WLAN_RC_* flags is wrong, you need to use
 the ATH_RC_* flags, as this is what ath_rate_newassoc_11n checks for in
 the firmware.
 
 Renamed.
 
 The only STBC related flag that actually gets used (when
 passed from the driver) is ATH_RC_RX_STBC_FLAG.
 
 Well, may be it is not used at the end. But it is present on some places 
 in the firmware.
 For example here:
 void
 rcSibUpdate_11n(struct ath_softc_tgt *sc, struct ath_node_target *pSib,
  A_UINT32 capflag, A_BOOL keepState, struct 
 ieee80211_rate  *pRateSet)
 {
  rcSibUpdate_ht(sc,
 pSib,
 ((capflag  ATH_RC_DS_FLAG)   ? WLAN_RC_DS_FLAG 
   : 0) |
 ((capflag  ATH_RC_HT40_SGI_FLAG)  ? 
 WLAN_RC_HT40_SGI_FLAG : 0) |
 ((capflag  ATH_RC_HT_FLAG)   ? WLAN_RC_HT_FLAG 
   : 0) |
 ((capflag  ATH_RC_CW40_FLAG) ? WLAN_RC_40_FLAG 
   : 0) |
 ((capflag  ATH_RC_TX_STBC_FLAG)   ? 
 WLAN_RC_STBC_FLAG  : 0),
 keepState,
 pRateSet);
 
 
 
 So, should i remove ATH_RC_TX_STBC_FLAG from my patch?
I extensively reviewed this part, and it's really crazy. Here's what
happens:

ath_rate_newassoc_11n takes ATH_RC_* flags, converts them to WLAN_RC_*.
rcSibUpdate_11n interprets the WLAN_RC_* flags as ATH_RC_* and converts
them to WLAN_RC_* again. For most flags this is pretty much a no-op
because the definitions are identical.
For STBC the result 'accidentally' still contains WLAN_RC_STBC_FLAG, but
only because ath_rate_newassoc_11n converts ATH_RC_RX_STBC_FLAG to
WLAN_RC_STBC_FLAG and WLAN_RC_STBC_FLAG overlaps with ATH_RC_TX_STBC_FLAG.
In the end it doesn't matter anymore, because nothing in the code takes
the STBC info from the capflags.

STBC is used if ATH_NODE_ATHEROS(an)-stbc is non-zero, and this gets
set by ath_rate_newassoc_11n before all of those incredibly moronic
conversions happen.

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH 1/2] ath9k_htc: add STBC TX support

[Felix Fietkau]

On 2013-05-02 7:32 PM, Oleksij Rempel wrote:
 Am 02.05.2013 18:55, schrieb Adrian Chadd:
 On 2 May 2013 01:11, Oleksij Rempel li...@rempel-privat.de wrote:

 +#define WLAN_RC_TX_STBC_FLAG 0x20 /* TX STBC */
 +#define WLAN_RC_RX_STBC_FLAG 0xC0 /* RX STBC ,2 bits */

 I thought we covered this; why are you marking two bits here?
 
 becouse firmware checks for two bits (and then use it as bool ;)), so i 
 pass what firmware can handle.
 
 Atheros 11n hardware only supports 1-stream STBC RX.
 
 Did you got my email with lots of assumptions and questions?
 What do you mean by 1-stream STBC RX? After i did some home work on STBC 
 i see that it encoded from at least two spatial streams.
 Is
 1-stream STBC RX = 2 spatial streams with mirrored data?
 and
 2-stream STBC RX = 4 spatial streams with mirrored data?
 
 or
 
 1-stream STBC RX = compatibility mode for one stream hardware(so only of 
 two streams received)?
When you're talking about 'streams', please specify where you're talking
about Spatial Streams (Nss, defined by the MCS), or Space-Time Streams
(Nsts). STBC is useful whenever the number of possible Space-Time
streams exceeds the number of Spatial streams, i.e. if the number of tx
chains is bigger than the number of spatial streams.
There's an asymmetry between Rx and Tx here. If a receiver has 1 chain
and the transmitter has 2 chains, tx can use 2 Space-Time streams to
encode 1 Spatial stream to improve the reliability of the signal.
The HT STBC capability field indicates the maximum number of Spatial
Streams, not Space-Time streams. Atheros hardware only supports STBC
with Nss = 1, so announcing 2-stream STBC is definitely wrong.

 That would make sense for 1x1:1 hardware, but if you say all atheros N 
 hardware support only 1-stream STBC RX, will mean that STBC is useless 
 on this hardware.
Only STBC With Nss=1, Nsts=2 is supported, but this does not make it
useless at all. It helps, even if the receiver only has one antenna.

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] 3.9.0-rc8+ (hacked) splat.

[Felix Fietkau]

On 2013-05-01 6:01 PM, Ben Greear wrote:
 On 04/30/2013 11:05 AM, Ben Greear wrote:
 On 04/28/2013 08:05 AM, Ben Greear wrote:
 On 04/27/2013 01:58 AM, Felix Fietkau wrote:
 On 2013-04-27 1:46 AM, Ben Greear wrote:
 Was running around 200 stations against a VAP on this system, and
 then changed the channel from 1 to 36 (by restarting hostapd with new
 config).

 Looks like null-pointer de-ref...  Anyone seen anything similar?
 I've never seen this one. Please use gdb to figure out the source code
 line that the NULL pointer deref happens in.
 As for the 'keycache entry 228 out of range' stuff, I'm going to send a
 patch for that now.

 Thanks.

 I'm away from the office for a bit, but will build a debugging kernel
 and crank on this early next week.

 Ok, this is against a modified 3.9.0 tree.  My patches are here:

 http://dmz2.candelatech.com/git/gitweb.cgi?p=linux-3.9.dev.y/.git;a=summary

 I'm going to try reproducing against upstream 3.9.0 (using a smaller number 
 of
 stations since upstream doesn't have needed optimizations to make it work on
 my hardware...)
 
 With the wpa_supplicant optimizations I posted yesterday, I can
 reproduce the crash on a standard 3.9.0 kernel with the regdomain
 patch AND the mac80211: Add per-sdata station hash, and sdata hash.
 
 https://patchwork.kernel.org/patch/2482351/
 
 I was not able to reproduce this without the hash optimization patch,
 so either it's buggy, or it just makes things a lot faster and that
 triggers bugs in ath9k more easily.
It's buggy. Take a look at this part:

 diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
 index 238a0cc..6b0fe74 100644
 --- a/net/mac80211/sta_info.c
 +++ b/net/mac80211/sta_info.c
 @@ -965,6 +1018,13 @@ struct ieee80211_sta 
 *ieee80211_find_sta_by_ifaddr(struct ieee80211_hw *hw,
  {
   struct sta_info *sta, *nxt;
  
 + if (localaddr) {
 + sta = sta_info_get_by_vif(hw_to_local(hw), localaddr, addr);
 + if (sta  !sta-uploaded)
 + return NULL;
 + return sta-sta;
 + }
If sta is NULL, it'll return sta-sta, which is non-NULL. It matches
the null-pointer crash on dereferencing the driver's tid struct inside
sta-drv_priv.

- Felix

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH RFC] ath9k: collect statistics about Rx-Dup and Rx-STBC packets

[Felix Fietkau]

On 2013-04-27 5:25 PM, Oleksij Rempel wrote:
 Collect statistics about recived duplicate and STBC packets.
 This information should help see if STBC is actually working.
 
 Tested on ar9285;
 
 Signed-off-by: Oleksij Rempel li...@rempel-privat.de
I thought about this patch some more, and I'm wondering what's the point
in doing this? These statistics are going to be completely useless for
most people and they'll waste some memory/cpu cycles, especially on
small-cache devices. I think it's much more useful to simply pass the
information to mac80211 via rx flags and get them added to the radiotap
header.
I'd like to keep the number of 'poor man's debug hacks' in the driver to
a minimum, and there are some other things that I think should be
removed: rx_frags and rx_beacons in struct ath_rx_stats, the tx/rx MAC
sampling hack, and pretty much anything else that can be just as easily
accessed from mac80211 through regular interfaces.

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH RFC] ath9k: collect statistics about Rx-Dup and Rx-STBC packets

[Felix Fietkau]

On 2013-04-28 4:54 PM, Ben Greear wrote:
 On 04/28/2013 05:51 AM, Felix Fietkau wrote:
 On 2013-04-27 5:25 PM, Oleksij Rempel wrote:
 Collect statistics about recived duplicate and STBC packets.
 This information should help see if STBC is actually working.

 Tested on ar9285;

 Signed-off-by: Oleksij Rempel li...@rempel-privat.de
 I thought about this patch some more, and I'm wondering what's the point
 in doing this? These statistics are going to be completely useless for
 most people and they'll waste some memory/cpu cycles, especially on
 small-cache devices. I think it's much more useful to simply pass the
 information to mac80211 via rx flags and get them added to the radiotap
 header.
 I'd like to keep the number of 'poor man's debug hacks' in the driver to
 a minimum, and there are some other things that I think should be
 removed: rx_frags and rx_beacons in struct ath_rx_stats, the tx/rx MAC
 sampling hack, and pretty much anything else that can be just as easily
 accessed from mac80211 through regular interfaces.
 
 Does that mean we can just put the stats in mac80211, or do we have
 to be running a sniffer to gather the stats?
Right now you'd have to use a sniffer, but if you really care about
getting specific stats it might make sense to write a kernel module that
attaches to a monitor interface and gathers them (maybe even with
support for gathering arbitrary stats by attaching bpf filters).

The problem I have with the current stats is they're just an arbitrary
collection of random stuff that is probably useless for 99% of all
users. In many cases the way the stats are collected also makes the data
completely meaningless (e.g. because the source/destination address is
not taken into account).

Why care about the number of packets on the air that were sent with a
specific rate flag? Why care about the number of beacons on the air
(with no filter on a set of APs or anything)? Or what about the number
of fragments received? To me it just looks like an incoherent set of
useless facts.

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH RFC] ath9k: collect statistics about Rx-Dup and Rx-STBC packets

[Felix Fietkau]

On 2013-04-28 5:15 PM, Ben Greear wrote:
 On 04/28/2013 08:08 AM, Felix Fietkau wrote:
 On 2013-04-28 4:54 PM, Ben Greear wrote:
 On 04/28/2013 05:51 AM, Felix Fietkau wrote:
 On 2013-04-27 5:25 PM, Oleksij Rempel wrote:
 Collect statistics about recived duplicate and STBC packets.
 This information should help see if STBC is actually working.

 Tested on ar9285;

 Signed-off-by: Oleksij Rempel li...@rempel-privat.de
 I thought about this patch some more, and I'm wondering what's the point
 in doing this? These statistics are going to be completely useless for
 most people and they'll waste some memory/cpu cycles, especially on
 small-cache devices. I think it's much more useful to simply pass the
 information to mac80211 via rx flags and get them added to the radiotap
 header.
 I'd like to keep the number of 'poor man's debug hacks' in the driver to
 a minimum, and there are some other things that I think should be
 removed: rx_frags and rx_beacons in struct ath_rx_stats, the tx/rx MAC
 sampling hack, and pretty much anything else that can be just as easily
 accessed from mac80211 through regular interfaces.

 Does that mean we can just put the stats in mac80211, or do we have
 to be running a sniffer to gather the stats?
 Right now you'd have to use a sniffer, but if you really care about
 getting specific stats it might make sense to write a kernel module that
 attaches to a monitor interface and gathers them (maybe even with
 support for gathering arbitrary stats by attaching bpf filters).
 
 I'd like ongoing stats w/out a monitor interface or sniffer, though
 it would be fine to add it to the sniffer path as well.  Maybe we can
 have compile-time flag to enable the extra and mostly useless
 stats so only the 1% that cares pays the overhead.
I'd like to have proper justification for stats added to the code and
kick out stuff not worth keeping. It's not just about runtime overhead,
but keeping the number of lines of code down is important for
maintenance as well. Adding extra compile time flags just makes the
maintenance part worse.

 The problem I have with the current stats is they're just an arbitrary
 collection of random stuff that is probably useless for 99% of all
 users. In many cases the way the stats are collected also makes the data
 completely meaningless (e.g. because the source/destination address is
 not taken into account).

 Why care about the number of packets on the air that were sent with a
 specific rate flag? Why care about the number of beacons on the air
 (with no filter on a set of APs or anything)? Or what about the number
 of fragments received? To me it just looks like an incoherent set of
 useless facts.
 
 I think having lots of stats allows for the possibility of seeing a pattern
 that might otherwise be missed, and when testing in an isolated environment,
 you don't have to care about who is sending what being reported..you already
 know.
The stats I pointed out seem mostly useless for that purpose. When
testing in an isolated environment you might as well run a capture on a
monitor mode interface and do some more sophisticated analysis afterwards.

 One thing I'd like to do, for instance, is to figure out how to get some
 average MPDU lengths calculated in hopes that would correlate with decreased
 performance in cases were we have lots of stations
Please don't throw hooks for such stacks all over the ath9k or mac80211
data path. Making a module for analyzing such stuff on a monitor mode
interface might be a bit more work than spraying hacks onto the code,
but at least it doesn't push the maintenance/performance overhead burden
onto everybody else.

Something like a BPF based statistics gathering module would be useful
for more people as well - I'd probably help with the code myself as
well. I made a proof of concept of such a module several years ago. It
was based on madwifi back then, but the code is mostly generic. You can
find it here:
http://git.openwrt.org/?p=packages.git;a=tree;f=net/wprobe/src

When implemented properly, such am module would even make things a lot
easier for you by letting you add new stats at runtime without changing
kernel code or reloading modules.

So let's stop wasting time on keeping lots of tiny useless hacks around
and instead build something more useful. :)

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH RFC] ath9k: collect statistics about Rx-Dup and Rx-STBC packets

[Felix Fietkau]

On 2013-04-28 9:19 PM, Oleksij Rempel wrote:
 Am 28.04.2013 17:03, schrieb Oleksij Rempel:
 Am 28.04.2013 16:13, schrieb Oleksij Rempel:
 Am 28.04.2013 14:51, schrieb Felix Fietkau:
 On 2013-04-27 5:25 PM, Oleksij Rempel wrote:
 Collect statistics about recived duplicate and STBC packets.
 This information should help see if STBC is actually working.

 Tested on ar9285;

 Signed-off-by: Oleksij Rempel li...@rempel-privat.de
 I thought about this patch some more, and I'm wondering what's the point
 in doing this? These statistics are going to be completely useless for
 most people and they'll waste some memory/cpu cycles, especially on
 small-cache devices. I think it's much more useful to simply pass the
 information to mac80211 via rx flags and get them added to the radiotap
 header.

 Sure.
 
 Now i need some help.
 Why there is no traces of  radiotap in ath9k. Some other drivers have 
 them? Do it communicate in some different way or there is just no 
 radiotap support in ath9k?
radiotap is generated in mac80211, so there's no need for the driver to
do it.

- Felix

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] 3.9.0-rc8+ (hacked) splat.

[Felix Fietkau]

On 2013-04-27 1:46 AM, Ben Greear wrote:
 Was running around 200 stations against a VAP on this system, and
 then changed the channel from 1 to 36 (by restarting hostapd with new
 config).
 
 Looks like null-pointer de-ref...  Anyone seen anything similar?
I've never seen this one. Please use gdb to figure out the source code
line that the NULL pointer deref happens in.
As for the 'keycache entry 228 out of range' stuff, I'm going to send a
patch for that now.

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH v2] ath9k: collect statistics about Rx-Dup and Rx-STBC packets

[Felix Fietkau]

On 2013-04-27 9:06 PM, Adrian Chadd wrote:
 On 27 April 2013 11:53, Oleksij Rempel li...@rempel-privat.de wrote:
 
 (And then go and re-align things inside that struct so you don't waste
 space.)


 hmm.. what do you mean here?
 
 Structure alignment? Well, you typically want to have everything be
 dword aligned (32 bits) or word (16 bits) aligned. Otherwise the
 compiler may insert extra padding between fields in order to meet
 alignment requirements on platforms that need it (MIPS, older ARM) or
 platforms that perform slower (newer ARM.)
I think in struct ath_rx_status alignment does not matter much, it's
only kept on the stack anyway. But yes, in other cases it makes sense to
pay attention to padding to keep structs small. I also agree that making
rs_flags u16 is a good idea.

 Now, i don't know what 'bool' is, whether it's a byte, word or dword.
bool is a byte.

 That is_mybeacon field should probably be just another flag in
 rx_status, then just extend 'rs_flags' to 16 bits and include it. That
 way the alignment is easy to see - all the fields in rx_status and the
 htc rx_status structs have explicit sizes. :-)
 
 Felix, what do you think?
Sounds good :)

- Felix

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH] ath9k: apply coverage class on slottime too

[Felix Fietkau]

On 2013-04-22 12:08 PM, Simon Wunderlich wrote:
 Hey Felix,
 
 just wanted to bump on this issue again, as it has not been applied
 yet - the patch seems still valid, and Mathias results appear to show
 that as well. What do you think?
Looks ok to me, let's get it merged.

- Felix

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] ath9k-issue with stop RX/TX DMA - correlation with WMM traffic classes?

[Felix Fietkau]

On 2013-04-12 10:27 AM, Rougu wrote:
 Hi everyone,
 
 while I might be totally wrong with my observation, I still would like 
 to share it, because this issue is lingering for years now and many 
 users are waiting to a solid grip on it to fix it.
 
 I'm running several freifunk-nodes in Cologne, Germany, where the 
 firmware contains a ath9k-watchdog that restarts the node, once the 
 failure occurs. One of my nodes is affected in varying intervals of 200 
 .. 1 seconds uptime, depending on WLAN activity.
 
 (openwrt, attitude adjustment, kernel 3.3.8)
Please also run a test with OpenWrt trunk and compare stability.

 Looking at /sys/kernel/debug/ieee80211/phy0/ath9k/xmit, it seems that
 MPDUs in the highest priority queue VO have a lower rate of 
 completion (90,5%) than those in BE (99,9%).
 
  From my laymen's perspective I would expect VO to have an even better 
 completion rate than BE.
What you're missing in that perspective is the fact that not all traffic
is created equal :)
The VO queue carries management traffic. Probe responses frequently end
up in XRetry because the number of retries is intentionally limited to 1
(some clients are often either too far away to ACK the probe response,
or do not stick around long enough to receive it).

 Any chance to see a correlation between WMM priority queue handling and 
 DMA access problems?
No, the data is too limited for that.

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] ath9k-issue with stop RX/TX DMA - correlation with WMM traffic classes?

[Felix Fietkau]

On 2013-04-12 6:57 PM, Jan Lühr wrote:
 Hallo Felix,
 
 Am 12.04.2013 um 17:41 schrieb Felix Fietkau:
 On 2013-04-12 10:27 AM, Rougu wrote:
 while I might be totally wrong with my observation, I still would like 
 to share it, because this issue is lingering for years now and many 
 users are waiting to a solid grip on it to fix it.
 
 I'm running several freifunk-nodes in Cologne, Germany, where the 
 firmware contains a ath9k-watchdog that restarts the node, once the 
 failure occurs. One of my nodes is affected in varying intervals of 200 
 .. 1 seconds uptime, depending on WLAN activity.
 
 (openwrt, attitude adjustment, kernel 3.3.8)
 Please also run a test with OpenWrt trunk and compare stability.
 
 thanks for providing feedback on this issue. Please keep in mind
 that using OpenWRT-trunk is not that easy for node operators of freifunk
 networks. I hope Rouge is able to do so - at least we will provide help
 in our Freifunk-Community (kbu).
I'm also considering backporting mac80211 from trunk to AA after the
release (meant for people that build the branch from source, not for a
follow-up release).

 I'd really like to discuss this issue at the upcoming Wireless
 Community Weekend in Berlin - will I meet you there?
Yes, definitely.

 At the moment we really do suffer from excessive driver-woos -
 causing the need to reboot nodes:
 ~ 1450 incidents have been reported within one month
 (http://register.kbu.freifunk.net/watchdog_bites). Some nodes are almost
 DoS'ed by certain - yet undiscovered - clients.
I'm really interested how such a setup behaves with either trunk or a
mac80211 backport to AA. Many fixes were added that could not easily be
backported to AA because they were too intrusive for the release.

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [RFC] ath9k: Respect current txpower setting

[Felix Fietkau]

On 2013-04-11 1:20 AM, Adrian Chadd wrote:
 On 10 April 2013 15:03, Tobias Steinicke
 tobias.steini...@net.t-labs.tu-berlin.de wrote:
 In routine ath_tx_fill_desc(), the txpower is only set to
 MAX_RATE_POWER. Now it respects the txpower from bss_conf and set it if it
 is (txpower * 2)  MAX_RATE_POWER else set to MAX_RATE_POWER.
 
 This doesn't do anything unless TPC is enabled.
 
 And if TPC is enabled, you have to jump through hoops to set the
 correct target TX power, as it's not always 1:1 between dBm value
 programmed in and dBm value transmitted.
I think TPC power value mappings were only problematic in pre-802.11n
chipsets, all chipsets supported by ath9k should be fine. There may be
some minor changes missing to enable it on some older chipsets, but
other than that it should be functional.

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH] ath9k: Re-enable interrupts after a channel change failure

[Felix Fietkau]

On 2013-04-02 2:03 PM, Robert Shade wrote:
 On Mon, Apr 1, 2013 at 1:40 PM, Felix Fietkau n...@openwrt.org wrote:
 Your patch is badly whitespace damaged.
 
 Ouch, must be the gmail web client.  I'll resubmit a fixed one.
 
 Why the call to ath9k_hw_set_interrupts here?
 
 Simply because that's what ath_complete_reset does
OK. You can leave it out, because it's not required for
interrupt-disable refcounting, and it will be called again after a
successful reset.

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH] ath9k: Re-enable interrupts after a channel change failure

[Felix Fietkau]

On 2013-04-01 4:22 PM, Robert Shade wrote:
 Re-enable interrupts after a channel change failure, since
 ath_complete_reset will not be called.  Also schedule a reset as a
 best effort method to recover the chip from whatever state caused the
 channel change failure.
 
 Signed-off-by: Robert Shade robert.sh...@gmail.com
Your patch is badly whitespace damaged.

 ---
  drivers/net/wireless/ath/ath9k/main.c |6 ++
  1 files changed, 6 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/net/wireless/ath/ath9k/main.c
 b/drivers/net/wireless/ath/ath9k/main.c
 index 24650fd..0567ac9 100644
 --- a/drivers/net/wireless/ath/ath9k/main.c
 +++ b/drivers/net/wireless/ath/ath9k/main.c
 @@ -280,6 +280,12 @@ static int ath_reset_internal(struct ath_softc
 *sc, struct ath9k_channel *hchan)
   if (r) {
   ath_err(common,
   Unable to reset channel, reset status %d\n, r);
 +
 + ath9k_hw_set_interrupts(ah);
Why the call to ath9k_hw_set_interrupts here?

 + ath9k_hw_enable_interrupts(ah);
 +
 + ath9k_queue_reset(sc, RESET_TYPE_BB_HANG);
 +
   goto out;
   }

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] Fixing the rate and rate relationship to OFDM

[Felix Fietkau]

On 2013-03-27 7:49 PM, John Clark wrote:
 Many people seem to desire the bit rate to be the 'highest possible',
 and have that automagically set.
What's wrong with the current behavior of picking the rate that causes
the least wasted airtime?

 For some applications, I like to be able to set a specific bit rate,
 and have that bit rate used no matter the resulting errors.
That can be quite problematic with 802.11n aggregation. Any frame
transmission that has failed after too many retries causes a BlockAck
Request to be sent, which can cause other (potentially unrelated) frames
to be dropped on the receiver side.
Why do you want to do this at all?

 I have looked a the code briefly, and it seems that there is the
 possibility for setting up several retries, with changes in bit
 rate.
 
 So, the questions are:
 
 1) how to 'fix' a rate, disable adjustments on retries, etc?
To do this per application, you'd have to put some ugly hacks into
various layers.

 2) What is the relationship between the bit rate selected at this OS level,
 and the subcarrier modulation of the RF signal?
The standard describes what modulations are used for specific bitrates.

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] WiFi Failure with AR9280

[Felix Fietkau]

On 2013-03-24 5:26 PM, Pannirselvam Kanagaratnam wrote:
 Hello,
 
 My WiFi connection drops while running the AR9280 on a Freescale 
 MPC8315E platform in AP mode with hostapd. I get the following error 
 within 15 seconds and the WiFi connection drops. However, I do not 
 observe any issues when using the AR9382. Can you let me know what could 
 be causing this and if there is a workaround for this. I am using 
 Compat-Wireless-3.5.4.1.
I suggest updating to a more recent version of compat-wireless - 3.5.4.1
is quite old.
If a similar failure still occurs there, make sure you turn on
CONFIG_KALLSYMS so that the trace is not just a long list of meaningless
numbers.

- Felix

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] Questions in 802.11 n timestamps traces for aggregated frames ?

[Felix Fietkau]

On 2013-03-16 9:19 PM, abhinav narain wrote:
 
  guess aggr of 1462 bytes ?),
  but why are those seq. numbers never re-used ?
 Your traces don't give you the full picture, because looking at this as
 a per-frame thing is wrong.
 If both IEEE80211_TX_CTL_AMPDU and IEEE80211_TX_STAT_AMPDU are set, it
 means that the contained rate retry information and time stamp refer to
 the whole A-MPDU, not just that one frame. Information about software
 retry of frames is not passed on to mac80211 at the moment.
 If you want accurate timestamp, rate and retry information, do it per
 A-MPDU, not per MPDU.
 
 Hi Felix, 
 I think I have understood you correctly, but let me know if I have got
 you wrong.
 
 
 
 *594 *is the*first* frame of the aggregate and the *rate* information
 from its descriptor has to be used *for the whole aggregate frame* 594-603.
 Since the frames *595-603* seq. no. have the flag IEEE80211_TX_CTL_AMPDU
 set and flag  IEEE80211_TX_STAT_AMPDU not set, they are a part of the
 AMPDU starting at 594 and all the rate/retx information is ignored.
That's correct.

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [RFC] ath9k: Detect and work-around tx-queue hang.

[Felix Fietkau]

On 2013-03-12 7:16 PM, Ben Greear wrote:
 On 02/22/2013 04:55 AM, Ben Greear wrote:
 On 02/22/2013 04:38 AM, Felix Fietkau wrote:
 On 2013-02-22 1:25 PM, Sujith Manoharan wrote:
 Felix Fietkau wrote:
 Please also check if the station(s) that the frames are queued for are
 in powersave state for some reason. That would prevent the tx path from
 throwing them in the hw queue, yet they'd still take up pending-frame
 slots. I was planning on fixing this eventually by expiring frames that
 stay in the queue for too long, but haven't decided on the exact
 approach yet.

 PS is disabled for multi-VIF.
 What about off-channel PS due to scans, etc.

 Scan is always locked to the same channel in this setup (once
 a single station is associated).

 The stations stay associated while this problem happens (the
 high-priority queue seems to work just fine, which may be
 the reason they stay associated just fine.)

 In some cases, I see packets delivered around 30 seconds late...
 aside from PS and off-channel..any idea what could make a packet
 stick around that long in the tx queues?
 
 One of our customers on a 3.5.7+ kernel hit the problem without
 using any RF attenuator...just over-the-air communication to
 their AP.  It happened on both 2.4 and 5Ghz bands.  Seems rx
 signal is around 40 in their environment. It took them around
 24 hours to hit the problem on average.
 
 Last we checked, we could fairly easily reproduce this in
 our lab using an attenuator and a certain setup, so if there
 is any debugging we could add to help narrow down what
 might be causing this, we can give that a try.
 
 For instance, is there any good way to know for certain
 if packets in the queue are in power-save or not?  I know
 we at least attempt to disable power-save, but possibly
 it gets re-enabled somehow?
The ath_node struct tracks if a node is sleeping or not. If a node is
sleeping, its tid queues can still hold some frames but will not be
serviced by ath_txq_schedule.

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] Questions in 802.11 n timestamps traces for aggregated frames ?

[Felix Fietkau]

On 2013-03-13 12:48 AM, abhinav narain wrote:
 Hi Felix, Adrian,
 
 /* This packet was aggregated but doesn't carry status info */
 if ((info-flags  IEEE80211_TX_CTL_AMPDU) 
 !(info-flags  IEEE80211_TX_STAT_AMPDU))
 return;
 
 Any packet with IEEE80211_TX_CTL_AMPDU and not IEEE80211_TX_STAT_AMPDU
 does not carry valid rate/retry information. Did you filter your debug
 stuff accordingly?
 
 
 
 I thought* rate_control_tx_status()[hook to
 minstrel_rate_ht]* in *ieee80211_tx_status()* will return back to driver
 (using the condition you told above) without reaching the radiotap code,
 but I don' t know why it does not.
 I continued and printed the flag, and have found the following : 
 
 I added another flag(first entry) in radiotap header to indicate 1 if
  IEEE80211_TX_CTL_AMPDU is set and IEEE80211_TX_STAT_AMPDU is not (the
 above condition) eg. [1,0,0,0,1] first is above cond, last flag is for
 aggregation. 
 The driver code indicates, this will be true if the frame passes
 through ath_tx_rc_status() [which is only twice].
 I had noticed that if I do this, I won't probably get the timestamp of
 rest of the frames given back to mac80211.
 
 [...]
  This suggests that first frame (594,606,611) are valid and aggregated
 but the following frames are invalid.
 
 I will be very grateful to you if you can please tell how to interpret
 the frames which have 
 the *aggregation *bit(last flag in tx_status flags ) *set* but *do not
 carry status info *and are delivered to monitor interface.
 The*sequence number *are* increasing* and never repeating ever again in
 trace
 If I remove these frames, it looks like there was no aggregation (I
 guess aggr of 1462 bytes ?), 
 but why are those seq. numbers never re-used ? 
Your traces don't give you the full picture, because looking at this as
a per-frame thing is wrong.
If both IEEE80211_TX_CTL_AMPDU and IEEE80211_TX_STAT_AMPDU are set, it
means that the contained rate retry information and time stamp refer to
the whole A-MPDU, not just that one frame. Information about software
retry of frames is not passed on to mac80211 at the moment.
If you want accurate timestamp, rate and retry information, do it per
A-MPDU, not per MPDU.

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] Questions in 802.11 n timestamps traces for aggregated frames ?

[Felix Fietkau]

On 2013-03-11 7:20 PM, abhinav narain wrote:
 
 Is this being recorded on transmit, or transmit completion? I'm
 guessing this is transmit completion on the transmit side.
 
 Is this information coming from the driver, or from some completion
 status going up to mac80211?
 
 Partly from the driver (timestamp and tx aggr flag) and partly from the
 status going to mac80211 (the bitrate array, retx count) and partly from
 the mac header ( sequence number)
 All of them are stored in the radiotap or mac header for each frame
 delivered in userspace in monitor mode.
 
 The data is recorded from transmit status(You might be referring to it
 as transmit complete)
 i.e net/mac80211/status.c 
 
 The *attempted rates *array is extracted from *struct ieee80211_tx_info *
 which is part of skb control buffer.I don't really get how is this
 populated/copied from.
 The*timestamp* is got from *ath_tx_status*, which is later stored in the
 ieee80211_tx_info struct to be given to mac80211. Population of
 timestamp is done in driver (ath_tx_complete_buf() ) 
 The *aggr flag *is populated using struct ath_buf
 field  bf-bf_state.bf_type.
One reason I told you to look into rate control is these lines in
minstrel_ht_tx_status:

/* This packet was aggregated but doesn't carry status info */
if ((info-flags  IEEE80211_TX_CTL_AMPDU) 
!(info-flags  IEEE80211_TX_STAT_AMPDU))
return;

Any packet with IEEE80211_TX_CTL_AMPDU and not IEEE80211_TX_STAT_AMPDU
does not carry valid rate/retry information. Did you filter your debug
stuff accordingly?

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH] ath9k: Allow over-riding reg-domain.

[Felix Fietkau]

On 2013-03-11 8:51 PM, Ben Greear wrote:
 On 03/11/2013 12:05 PM, John W. Linville wrote:
 On Mon, Mar 11, 2013 at 09:45:06AM -0700, gree...@candelatech.com wrote:
 From: Ben Greear gree...@candelatech.com

 Otherwise, can't get the Sparklan AR9380 NICs to be
 5Ghz APs, since they are in world-roaming domain by
 default.  Add this to /etc/modprobe.d/ath9k.conf:

 options ath9k override_eeprom_regdomain=0

 Signed-off-by: Ben Greear gree...@candelatech.com

 Why =0 to enable it?  Just to make it more confusing?
 
 You are just setting the country code...and country-code 0 seems
 to at least open up the US regulatory domain so we use it
 by default.
 
 You can use any country code you wish here.
I'd like to have less fugly module parameter hackery please. How about
either using CONFIG_CFG80211_CERTIFICATION_ONUS the way it was intended,
or adding another config option that makes it bail out of
ath_regd_init_wiphy() early, thus still processing the EEPROM regdomain
hint and not making it binding.

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH] ath9k: Allow over-riding reg-domain.

[Felix Fietkau]

On 2013-03-11 10:01 PM, Ben Greear wrote:
 On 03/11/2013 01:17 PM, Felix Fietkau wrote:
 On 2013-03-11 8:51 PM, Ben Greear wrote:
 On 03/11/2013 12:05 PM, John W. Linville wrote:
 On Mon, Mar 11, 2013 at 09:45:06AM -0700, gree...@candelatech.com wrote:
 From: Ben Greear gree...@candelatech.com

 Otherwise, can't get the Sparklan AR9380 NICs to be
 5Ghz APs, since they are in world-roaming domain by
 default.  Add this to /etc/modprobe.d/ath9k.conf:

 options ath9k override_eeprom_regdomain=0

 Signed-off-by: Ben Greear gree...@candelatech.com

 Why =0 to enable it?  Just to make it more confusing?

 You are just setting the country code...and country-code 0 seems
 to at least open up the US regulatory domain so we use it
 by default.

 You can use any country code you wish here.
 I'd like to have less fugly module parameter hackery please. How about
 either using CONFIG_CFG80211_CERTIFICATION_ONUS the way it was intended,
 or adding another config option that makes it bail out of
 ath_regd_init_wiphy() early, thus still processing the EEPROM regdomain
 hint and not making it binding.
 
 I am not sure what you are suggesting.  I enabled this override
 only when ONUS is selected because I wanted it clear that users
 were taking their regulatory compliance into their own hands.
And as far as I understand, CONFIG_CFG80211_CERTIFICATION_ONUS already
enables some code in cfg80211 that allows a special type of regulatory
change request from user space that bypasses intersection.

 I always want the module option at least visible so that
 you don't have to muck with modprobe.conf just to get ath9k.ko
 to load when it's compiled differently.
 
 For the second part, you want the ability to set the regdomain
 be a compile-time option like CONFIG_ATH9K_OVERRIDE_REGDOMAIN
 or something like that?
Something like that, yes. It should depend on
CONFIG_CFG80211_CERTIFICATION_ONUS and should contain a help text that
strongly discourages any distribution from enabling it in their kernel
builds.

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH] ath9k: Allow over-riding reg-domain.

[Felix Fietkau]

On 2013-03-11 10:44 PM, Ben Greear wrote:
 On 03/11/2013 02:36 PM, Felix Fietkau wrote:
 On 2013-03-11 10:01 PM, Ben Greear wrote:
 On 03/11/2013 01:17 PM, Felix Fietkau wrote:
 
 I am not sure what you are suggesting.  I enabled this override
 only when ONUS is selected because I wanted it clear that users
 were taking their regulatory compliance into their own hands.
 And as far as I understand, CONFIG_CFG80211_CERTIFICATION_ONUS already
 enables some code in cfg80211 that allows a special type of regulatory
 change request from user space that bypasses intersection.

 I always want the module option at least visible so that
 you don't have to muck with modprobe.conf just to get ath9k.ko
 to load when it's compiled differently.

 For the second part, you want the ability to set the regdomain
 be a compile-time option like CONFIG_ATH9K_OVERRIDE_REGDOMAIN
 or something like that?
 Something like that, yes. It should depend on
 CONFIG_CFG80211_CERTIFICATION_ONUS and should contain a help text that
 strongly discourages any distribution from enabling it in their kernel
 builds.
 
 It seems to me that this doesn't gain much.  The ONUS configuration is already
 strongly discouraged from vendor kernels.  If you are already compiling
 with ONUS set, is there any reason you'd care to disable the override
 module option?  When you don't set the module option, nothing happens
 anyway...
I'd like to avoid accumulating more hackish driver specific module
options for working around a generic issue.

- Felix

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH] ath9k: Allow over-riding reg-domain.

[Felix Fietkau]

On 2013-03-11 11:00 PM, Ben Greear wrote:
 On 03/11/2013 02:51 PM, Felix Fietkau wrote:
 On 2013-03-11 10:44 PM, Ben Greear wrote:
 On 03/11/2013 02:36 PM, Felix Fietkau wrote:
 On 2013-03-11 10:01 PM, Ben Greear wrote:
 On 03/11/2013 01:17 PM, Felix Fietkau wrote:

 I am not sure what you are suggesting.  I enabled this override
 only when ONUS is selected because I wanted it clear that users
 were taking their regulatory compliance into their own hands.
 And as far as I understand, CONFIG_CFG80211_CERTIFICATION_ONUS already
 enables some code in cfg80211 that allows a special type of regulatory
 change request from user space that bypasses intersection.

 I always want the module option at least visible so that
 you don't have to muck with modprobe.conf just to get ath9k.ko
 to load when it's compiled differently.

 For the second part, you want the ability to set the regdomain
 be a compile-time option like CONFIG_ATH9K_OVERRIDE_REGDOMAIN
 or something like that?
 Something like that, yes. It should depend on
 CONFIG_CFG80211_CERTIFICATION_ONUS and should contain a help text that
 strongly discourages any distribution from enabling it in their kernel
 builds.

 It seems to me that this doesn't gain much.  The ONUS configuration is 
 already
 strongly discouraged from vendor kernels.  If you are already compiling
 with ONUS set, is there any reason you'd care to disable the override
 module option?  When you don't set the module option, nothing happens
 anyway...
 I'd like to avoid accumulating more hackish driver specific module
 options for working around a generic issue.
 
 I don't think I'm up for any significant re-write of the
 regdomain logic, and I'm not sure it's worth the effort
 of anyone doing this for code that will be compiled out
 of all vendor kernels anyway...
Who said anything about rewriting the regdomain logic? The code is
already there. If you make it a compile time option that gets rid of the
code in ath_regd_init_wiphy, it doesn't need a module parameter - iw reg
set will do the job, and the default still comes from EEPROM.

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] Enabling tx-power-per-vif in ath9k?

[Felix Fietkau]

On 2013-03-04 11:28 PM, Ben Greear wrote:
 It seems there is some mac80211 framework for handling per VIF tx-power
 settings now, but from what I can tell, this is not supported in ath9k.
Correct.

 Any idea how feasible it is to do per-vif tx-power in ath9k?  I think
 it would come down to putting the desired tx-power into each packet
 (as the VIF sends it towards the driver) and then changing the power
 as packets were transmitted in the NIC...
No need for 'changing the power as packets were transmitted', that would
be horribly messy and unreliable anyway. The hardware is capable of
proper per-packet TPC, configurable via the tx descriptor.

 The goal is to have multiple virtual APs, each with different tx-powers
 in order to roughly affect rx-signal quality for the stations that
 are scanning for APs...
Interesting.

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] ts_tstamp field in ath_tx_status is set

[Felix Fietkau]

On 2013-02-27 9:58 AM, abhinav narain wrote:
 
 Thanks Felix, I think I wasn't clear in asking my question.
 Sorry about that, is it possible you can answer one below ?
 On Tue, Feb 26, 2013 at 6:03 PM, Felix Fietkau n...@openwrt.org
 mailto:n...@openwrt.org wrote:
 
 On 2013-02-26 7:51 PM, abhinav narain wrote:
  Thanks for the response, Felix !
  I have some questions to ask :
 
  (1) So I should interpret the ath_tx_status descriptor as :
  14 retransmissions occurred while transmission of 1542*4 bytes.
  Its not 14*4 retransmissions.
 Aggregates are formed by the driver before being passed to the hardware.
 The hardware makes no attempt to split them up and deal with individual
 subframes separately - this is the driver's job (in the software retry
 stage).
 
 (1) The one thing I wanted to clarify was the size of ampdu : is
 it 1542*4  ?
 As the timestamp of 4 frames are the same or or the sum of bytes of 4
 frames is 1542 bytes as the descriptor gives 1542 ? I thought ampdu
1500 bytes (4K or 8K) 
 Is it because frames are split up ( before ath_tx_complete_buf()) on
 their way back to mac80211.
Frames are variable length, so obviously A-MPDUs are as well. An A-MPDU
is simply a bunch of MPDUs sent together with one PHY header, separated
by delimiters.

 (2) Another scenerio that intrigued me was the following : 
 [timestamp,retx count,rate,seq no. , framesize ]
 [315065076,0, 65.0, [], *710*, 1542]
 [315065076,14, 65.0,[[65.0, 4], [58.5, 5], [65.0, 5]], *711*, 1542]
 [315065599,,0, 65.0,[], *712*, 1542]
 If these two (710,711) were sent at the same time : are they ampdu ? I
 guess not !
 But there are two different values of rates in ath_rx_status descriptor,
 which I can't reconcile with.
 
 Please throw some light on the above two cases.
There's code in current ath9k that passes the A-MPDU rx status to
mac80211 for inclusion in radiotap. I suggest you rely on hardware
information instead of guesswork.

- Felix

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] ts_tstamp field in ath_tx_status is set

[Felix Fietkau]

On 2013-02-27 4:26 PM, abhinav narain wrote:
 
  As the timestamp of 4 frames are the same or or the sum of bytes of 4
  frames is 1542 bytes as the descriptor gives 1542 ? I thought ampdu
 1500 bytes (4K or 8K)
  Is it because frames are split up ( before ath_tx_complete_buf()) on
  their way back to mac80211.
 Frames are variable length, so obviously A-MPDUs are as well. An A-MPDU
 is simply a bunch of MPDUs sent together with one PHY header, separated
 by delimiters.
 
 I know the above basics :-)
 I was asking in the specific case I have shown in the email,
 how to interpret the ath_tx_status entries in this case.  
 *[315063930, 14,[[65.0, 4], [58.5, 5], [65.0, 5]], 706,1542]*
 *[315063930, 14,[[65.0, 4], [58.5, 5], [65.0, 5]], 707,1542]*
 *[315063930, 14,[[65.0, 4], [58.5, 5], [65.0, 5]], 708,1542]*
 *[315063930, 14,[[65.0, 4], [58.5, 5], [65.0, 5]], 709,1542]*
 
 Is the ampdu size=1542 ? consisting of 4 frames with seq.no
 http://seq.no. 706-709 ? or size=1542*4.
I'd say, probably. I have no clue where/how you're dumping the data. The
code has enough hints that show how A-MPDU status is processed (take a
look at minstrel_ht to see how it's effectively interpreted).

  (2) Another scenerio that intrigued me was the following :
  [timestamp,retx count,rate,seq no. , framesize ]
  [315065076,0, 65.0, [], *710*, 1542]
  [315065076,14, 65.0,[[65.0, 4], [58.5, 5], [65.0, 5]], *711*, 1542]
  [315065599,,0, 65.0,[], *712*, 1542]
  If these two (710,711) were sent at the same time : are they ampdu ? I
  guess not !
  But there are two different values of rates in ath_rx_status
 descriptor,
  which I can't reconcile with.
 
  Please throw some light on the above two cases.
 There's code in current ath9k that passes the A-MPDU rx status to
 
 
 I am talking here about *tx* status in ath9k/xmit.c.
 Please notice that I am finding difficulty In the xmit path.
Ah, ok, so ath_rx_status was a typo.

 In recv.c, I see there is a rs_moreaggr  flag in ath_*rx*_status which I
 can look for aggregation.
 
 mac80211 for inclusion in radiotap. I suggest you rely on hardware
 information instead of guesswork.
 
 I am still confused what the hardware feedback is in ath_*tx*_status in
 xmit.c
I already pointed out to you that the tx status is reported for an
entire aggregate, not individual subframes. If you take a look at the
part where it reports the status to mac80211 and look at minstrel_ht to
see how it's interpreted, you should be able to figure it out - I'm not
going to do that work for you.

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] ts_tstamp field in ath_tx_status is set

[Felix Fietkau]

On 2013-02-26 7:51 PM, abhinav narain wrote:
 Thanks for the response, Felix !
 I have some questions to ask :
 
 (1) So I should interpret the ath_tx_status descriptor as :
 14 retransmissions occurred while transmission of 1542*4 bytes.
 Its not 14*4 retransmissions.
Aggregates are formed by the driver before being passed to the hardware.
The hardware makes no attempt to split them up and deal with individual
subframes separately - this is the driver's job (in the software retry
stage).

 (2) I was timestamping the frame in ath_tx_txqaddbuf() and in
 ath_tx_complete buf()
 to get the (queuing + contention) delay. Can I somehow get just the
 contention 
 delay in ath9k ?
No.

 (3) I am assuming struct ath_tx_buf keeps track of only one frame(skb).
 Is that true ? or am I missing any detail ? 
It's for one buffer. Multiple buffers can be linked to form one frame
(though the driver only uses one buffer per frame at the moment, and
multiple frames can be linked to form an aggregate.

 (4) Were the different parts of the frames tried at 3 different rates or 
 was the whole frame of 1542*4 bytes tried with different rates ?
 I should check IEEE80211_TX_CTL_AMPDU for knowing tx aggregation ?
See above (1)

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] ts_tstamp field in ath_tx_status is set

[Felix Fietkau]

On 2013-02-25 9:53 PM, abhinav narain wrote:
 You are right in that case, Adrian.
 
 *tsf ,retx count, rates and transmit attempts, sequence no, frame size*
 *[315063930, 14,[[65.0, 4], [58.5, 5], [65.0, 5]], 706,1542]*
 *[315063930, 14,[[65.0, 4], [58.5, 5], [65.0, 5]], 707,1542]*
 *[315063930, 14,[[65.0, 4], [58.5, 5], [65.0, 5]], 708,1542]*
 *[315063930, 14,[[65.0, 4], [58.5, 5], [65.0, 5]], 709,1542]*
 
 I have the above trace of transmitted frames from status.c file.
 You can see the frame sequence no. is increasing 706,707 ...
 but the timestamps are all the same.
 Apart from it, every frame is suffering retransmissions.
 
 I had found the timestamp value using ath_tx_status descriptor's
 ts_tstamp  field in 
 ath_tx_complete_buf() in xmit.c 
 
 Since ath_tx_status is per frame and hence its time field, how is it
 that the timestamp is not unique.
 
 Can you guess whats going wrong, by any chance ?
With aggregation, you get a single tx status for a whole aggregate.

- Felix

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [RFT] ath9k_htc - please test new images

[Felix Fietkau]

On 2013-02-23 9:13 PM, Oleksij Rempel wrote:
 Am 23.02.2013 12:41, schrieb Adrian Chadd:
 On 23 February 2013 01:54, Oleksij Rempel bug-tr...@fisher-privat.net 
 wrote:

 Hi Adrian,

 current driver has this check:
 htc_drv_init.c: priv-fw_version_minor != MINOR_VERSION_REQ) {
 htc_drv_init.c: MAJOR_VERSION_REQ, MINOR_VERSION_REQ);

 so it wont accept 1.4. Currently i compiling kernel without this
 restriction. Then i'll be able to test it.

 Oops! Guess I shouldn't have bumped the version numbers :-)
 
 Now results:
 - Current wireless-testing.git is broken for my htc_* devices. none of 
 firmwares is working.
 - I use 3.8.0-rc7 from wireless-testing.git for testing.
 - htc_7010.fw is working.
 - htc_9271.fw do not working. it fails on authentication:
Same here (AR9271).

- Felix

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [RFC] ath9k: Detect and work-around tx-queue hang.

[Felix Fietkau]

On 2013-02-22 6:26 AM, Ben Greear wrote:
 On 02/21/2013 08:49 PM, Sujith Manoharan wrote:
 Ben Greear wrote:
 I'll be happy to test patches, but I'm not sure how to go about
 debugging the real problem on my own.  Maybe some stats could
 be added to the xmit debugfs file to help diagnose the problem,
 or maybe some other debugfs info will help?

 I can't reproduce the problem with ath9k debugging set at the
 previous suggested level, so it would have to be something
 less invasive.

 As for just stations going out of range, it remains locked up
 even with signal level goes back to -20, so it's not just a simple
 station-out-of range issues..

 Sure, but I think that filtered frames are not handled properly,
 especially with aggregation, since the debugfs stats from your earlier email
 showed a large counter (from a private patch ?):

 TXERR Filtered:224  0 0 0
 
 Yeah, guess that patch never made it upstream.  The pertinent bit is:
Please also check if the station(s) that the frames are queued for are
in powersave state for some reason. That would prevent the tx path from
throwing them in the hw queue, yet they'd still take up pending-frame
slots. I was planning on fixing this eventually by expiring frames that
stay in the queue for too long, but haven't decided on the exact
approach yet.

- Felix

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [RFC] ath9k: Detect and work-around tx-queue hang.

[Felix Fietkau]

On 2013-02-22 1:25 PM, Sujith Manoharan wrote:
 Felix Fietkau wrote:
 Please also check if the station(s) that the frames are queued for are
 in powersave state for some reason. That would prevent the tx path from
 throwing them in the hw queue, yet they'd still take up pending-frame
 slots. I was planning on fixing this eventually by expiring frames that
 stay in the queue for too long, but haven't decided on the exact
 approach yet.
 
 PS is disabled for multi-VIF.
What about off-channel PS due to scans, etc.

- Felix

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH] ath9k_htc: update RSSI values only when the device is associated

[Felix Fietkau]

On 2013-02-01 1:50 PM, Bernhard Urban wrote:
 add an if-guard, otherwise iw(8) reports weird signal strengths.
 
 The behaviour was fine before this commit:
   7c277349ecbd66e19fad3d949fa6ef6c131a3b62
 Therefore, this patch is a partially revert of it.
I think your commit message is a bit misleading. The main problem with
signal strength reporting is not that it's missing some checks for if
the device is associated, or if the received frame is a local beacon.

The main problem is in these lines below:
 + if (likely(last_rssi != ATH_RSSI_DUMMY_MARKER)) {
 + s8 rssi = ATH_EP_RND(last_rssi, ATH_RSSI_EP_MULTIPLIER);
 + rxbuf-rxstatus.rs_rssi = rssi;
 + }
It does not make any sense to update the per-frame RSSI value with any
sort of average. ath9k filters out invalid RSSI values by ignoring rssi
for ANI when rx_stats-rs_moreaggr is set. In that case it also sets the
RX_FLAG_NO_SIGNAL_VAL flag to tell mac80211 to ignore the value for its
own signal strength averages.

- Felix

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [RFC 3/3] ath9k: add spectral scan feature

[Felix Fietkau]

On 2012-12-05 11:40 AM, Simon Wunderlich wrote:
 I suggest experimenting around with those particular parameters. You
 should be able to coax out specific numbers of spectral scan events
 when you set the COUNT parameter to something other than 8. But
 polling that bit isn't needed. It should be asynchronous.
 
 As I said, on AR9220 it appears I get 8 samples when doing setting 
 AR_PHY_SPECTRAL_SCAN_COUNT to 8 (plus maybe some other stuff/non-samples).
 On AR9380 I'm not so sure. Probably need to play with it a little
 more. Also, I don't know what SHORT REPEAT is supposed to mean, etc.
 
 About polling, you mean the SCAN_ACTIVE bit? It is probably only
 needed when I want to trigger for few samples and want to be informed when
 it's finished -  which is a good thing when doing spectral scan (change 
 channel,
 start and wait for samples, change again). But we probably don't need to wait
 for the background spectral scanning mode, that's right. If someone wants
 to implement detection for interfering radio users, that mode would be useful.
 I don't need it, but can prepare the neccesary functions.
 
 So I'd repost then:
  * ath9k/debugfs only patch for now, as Johannes suggested - I think we
should concentrate on this for now (their are still a lot of open
questions in my initial mail regarding sample interpretation etc)
  * split commands into enable/disable/configure/trigger
  * maybe add some defines for magic values (if I find any)
 
 I'd like this patchset to make the graphical spectral scan possible (as
 a Ubiquiti Airview), and give others the opportunity to add own features
 (pattern matching etc) on top of it. However I (currently) don't plan to
 do the latter myself.
How about using relay (Documentation/filesystems/relay.txt) to stream
sample data to user space via the debugfs file?
That way you don't have to keep a linked list of small struct fft_sample
buffers in the kernel and you can stream much more data efficiently with
little kernel side overhead.
It also makes pushing the streaming data to a network socket via
sendfile much more efficient.

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] ath9k_tasklet() can be interrupted by a hardware IRQ

[Felix Fietkau]

On 2012-11-20 11:05 AM, Felix Liao wrote:
 Hi Felix F, I'm Felix Liao from WatchGuard, I think we should 
 spin_lock_irqsave and spin_unlock_irqrestore on sc_pcu_lock 
 in the ath9k_tasklet() instead of spin_lock/spin_unlock, just to avoid the 
 tasklet being interrupted by the hardware IRQ,
 do you think so?
Using an IRQ spinlock in the tasklet is not the correct solution. If the
IRQ fires while the tasklet is running, it means that the driver does
not properly disable IRQs in the handler. They're supposed to get
disabled there and re-enabled only after the tasklet has completed.

- Felix

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH] ath9k_htc: update RSSI values only when the device is associated

[Felix Fietkau]

On 2012-11-09 6:09 PM, Bernhard Urban wrote:
 add an if-guard, otherwise iw(8) reports weird signal strengths.
 
 The behaviour was fine before this commit:
 7c277349ecbd66e19fad3d949fa6ef6c131a3b62
 This patch is therefore a partially revert of it.
 
 Tested with TP-Link TL-WN722N
 
 Thanks to indoo.rs http://indoo.rs/ for sponsoring
 
 Reported-by: Markus Krainz mar...@indoo.rs
 Tested-by: Markus Krainz mar...@indoo.rs
 Signed-off-by: Bernhard Urban lew...@gmail.com
 ---
  drivers/net/wireless/ath/ath9k/htc_drv_txrx.c |   27 
 ++---
  1 file changed, 15 insertions(+), 12 deletions(-)
 
 diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c 
 b/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
 index 47e61d0..d0d329c 100644
 --- a/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
 +++ b/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
 @@ -1060,22 +1060,25 @@ static bool ath9k_rx_prepare(struct ath9k_htc_priv 
 *priv,
   ath9k_process_rate(hw, rx_status, rxbuf-rxstatus.rs_rate,
  rxbuf-rxstatus.rs_flags);
  
 - if (rxbuf-rxstatus.rs_rssi != ATH9K_RSSI_BAD 
 - !rxbuf-rxstatus.rs_moreaggr)
 - ATH_RSSI_LPF(priv-rx.last_rssi,
 -  rxbuf-rxstatus.rs_rssi);
 + if (priv-num_sta_assoc_vif != 0) {
 + if (rxbuf-rxstatus.rs_rssi != ATH9K_RSSI_BAD 
 + !rxbuf-rxstatus.rs_moreaggr)
 + ATH_RSSI_LPF(priv-rx.last_rssi,
 +  rxbuf-rxstatus.rs_rssi);
  
 - last_rssi = priv-rx.last_rssi;
 + last_rssi = priv-rx.last_rssi;
  
 - if (likely(last_rssi != ATH_RSSI_DUMMY_MARKER))
 - rxbuf-rxstatus.rs_rssi = ATH_EP_RND(last_rssi,
 -  ATH_RSSI_EP_MULTIPLIER);
 + if (likely(last_rssi != ATH_RSSI_DUMMY_MARKER)) {
 + s8 rssi = ATH_EP_RND(last_rssi, ATH_RSSI_EP_MULTIPLIER);
 + rxbuf-rxstatus.rs_rssi = rssi;
 + }
  
 - if (rxbuf-rxstatus.rs_rssi  0)
 - rxbuf-rxstatus.rs_rssi = 0;
 + if (rxbuf-rxstatus.rs_rssi  0)
 + rxbuf-rxstatus.rs_rssi = 0;
  
 - if (ieee80211_is_beacon(fc))
 - priv-ah-stats.avgbrssi = rxbuf-rxstatus.rs_rssi;
 + if (ieee80211_is_beacon(fc))
 + priv-ah-stats.avgbrssi = rxbuf-rxstatus.rs_rssi;
 + }
  
   rx_status-mactime = be64_to_cpu(rxbuf-rxstatus.rs_tstamp);
   rx_status-band = hw-conf.channel-band;
 
Please check how RSSI is handled in ath9k, and use that as reference.
The per-packet RSSI should not be set from some internal average, it
should contain the real RSSI value of the packet. This change disables
RSSI reporting for anything but station mode, which is not a good idea.

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH] ath9k: [DFS] add pulse width tolerance for ETSI

[Felix Fietkau]

On 2012-10-31 2:32 PM, Hauke Mehrtens wrote:
 On 10/31/2012 12:23 PM, Zefir Kurtisi wrote:
 Add 5% width tolerance for radar patterns defined by ETSI.
 
 Signed-off-by: Zefir Kurtisi zefir.kurt...@neratec.com
 ---
  .../net/wireless/ath/ath9k/dfs_pattern_detector.c  |7 ++-
  1 files changed, 6 insertions(+), 1 deletions(-)
 
 diff --git a/drivers/net/wireless/ath/ath9k/dfs_pattern_detector.c 
 b/drivers/net/wireless/ath/ath9k/dfs_pattern_detector.c
 index 3b12914..24877b0 100644
 --- a/drivers/net/wireless/ath/ath9k/dfs_pattern_detector.c
 +++ b/drivers/net/wireless/ath/ath9k/dfs_pattern_detector.c
 @@ -42,10 +42,15 @@ struct radar_types {
  #define MIN_PPB_THRESH  50
  #define PPB_THRESH(PPB) ((PPB * MIN_PPB_THRESH + 50) / 100)
  #define PRF2PRI(PRF) ((100 + PRF / 2) / PRF)
 +/* percentage of pulse width tolerance */
 +#define WIDTH_TOLERANCE 5
 +#define WIDTH_LOWER(X) ((X*(100-WIDTH_TOLERANCE)+50)/100)
 +#define WIDTH_UPPER(X) ((X*(100+WIDTH_TOLERANCE)+50)/100)
^^^
 Why are you adding 50 there? If you want to just add 5% tolerance, then
 the +50 is wrong there, but I do not know anything about radar patterns
 defined by ETSI.
I think the 50 is correct here. It's not the tolerance (which is already
included via WIDTH_TOLERANCE in that macro), it's to account for
rounding issues.
Having said that, I wonder if it shouldn't be -50 instead of +50 in
WIDTH_LOWER().

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH] ath9k: apply coverage class on slottime too

[Felix Fietkau]

On 2012-10-30 1:07 PM, Simon Wunderlich wrote:
 From: Mathias Kretschmer mathias.kretsch...@fokus.fraunhofer.de
 
 According to 802.11-2007 17.3.8.6 (slot time), the slot time should
 be increased by 3 us * coverage class. The code only increased the
 ack timeout, which is fixed by this patch.
 
 We have noticed in our long shot scenario that we see less collisions
 with this patch.
At some point I had the slot time increase in the driver, but noticed a
massive throughput degradation on 10-20 km links. Leaving the slot time
alone and changing only the ACK timeout fixed this. What distances did
you test?

- Felix

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH] ath9k: apply coverage class on slottime too

[Felix Fietkau]

On 2012-10-30 2:00 PM, Mathias Kretschmer wrote:
 On 10/30/2012 01:43 PM, Felix Fietkau wrote:
 On 2012-10-30 1:07 PM, Simon Wunderlich wrote:
 From: Mathias Kretschmer mathias.kretsch...@fokus.fraunhofer.de

 According to 802.11-2007 17.3.8.6 (slot time), the slot time should
 be increased by 3 us * coverage class. The code only increased the
 ack timeout, which is fixed by this patch.

 We have noticed in our long shot scenario that we see less collisions
 with this patch.
 At some point I had the slot time increase in the driver, but noticed a
 massive throughput degradation on 10-20 km links. Leaving the slot time
 alone and changing only the ACK timeout fixed this. What distances did
 you test?
 
 about 11km. did you test UDP (unidirectional) or TCP (bidirectional) 
 throughput ?
I always use TCP, because UDP tests are too unrealistic to estimate real
performance.

 The larger slot time will increase the channel access overhead which should 
 impact 
 unidirectional throughput.
 
 With bidirectional traffic, the larger slottime should help to minimize 
 collisions 
 on loaded links. Overall this seems to increase the net throughput for us, 
 especially in higher access categories (smaller backoff windows).
When I ran the test, the throughput degradation was so big that the
links became almost useless. It was a long time ago, so maybe this was
caused by another bug that has been fixed since. I will run another test
with this patch in a current version...

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH] ath9k: Test for TID only in BlockAcks while checking tx status

[Felix Fietkau]

On 2012-10-29 1:25 PM, Sven Eckelmann wrote:
 The ath9k xmit functions for AMPDUs can send frames as non-aggregate in case
 only one frame is currently available. The client will then answer using a
 normal Ack instead of a BlockAck. This acknowledgement has no TID stored and
 therefore the hardware is not able to provide us the corresponding TID.
 
 The TID set by the hardware in the tx status descriptor has to be seen as
 undefined and not as a valid TID value for normal acknowledgements. Doing
 otherwise results in a massive amount of retransmissions and stalls of
 connections.
 
 Users may experience low bandwidth and complete connection stalls in
 environments with transfers using multiple TIDs.
 
 This regression was introduced in b11b160defc48e4daa283f785192ea3a23a51f8e
 (ath9k: validate the TID in the tx status information).
 
 Signed-off-by: Sven Eckelmann s...@narfation.org
 Signed-off-by: Simon Wunderlich s...@hrz.tu-chemnitz.de
Nice catch, thanks!
Acked-by: Felix Fietkau n...@openwrt.org
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH] ath9k: Test for TID only in BlockAcks while checking tx status

[Felix Fietkau]

On 2012-10-29 1:34 PM, Felix Fietkau wrote:
 On 2012-10-29 1:25 PM, Sven Eckelmann wrote:
 The ath9k xmit functions for AMPDUs can send frames as non-aggregate in case
 only one frame is currently available. The client will then answer using a
 normal Ack instead of a BlockAck. This acknowledgement has no TID stored and
 therefore the hardware is not able to provide us the corresponding TID.
 
 The TID set by the hardware in the tx status descriptor has to be seen as
 undefined and not as a valid TID value for normal acknowledgements. Doing
 otherwise results in a massive amount of retransmissions and stalls of
 connections.
 
 Users may experience low bandwidth and complete connection stalls in
 environments with transfers using multiple TIDs.
 
 This regression was introduced in b11b160defc48e4daa283f785192ea3a23a51f8e
 (ath9k: validate the TID in the tx status information).
 
 Signed-off-by: Sven Eckelmann s...@narfation.org
 Signed-off-by: Simon Wunderlich s...@hrz.tu-chemnitz.de
 Nice catch, thanks!
 Acked-by: Felix Fietkau n...@openwrt.org
One more thing: I think this deserves a
Cc: sta...@vger.kernel.org

- Felix

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel