Rate control algorithms are supposed to stop processing when they
encounter a rate with the index -1. Checking for rate->count not being
zero is not enough.
Allowing a rate with negative index leads to memory corruption in
ath_debug_stat_rc().
One consequence of the bug is discussed at
https://bugzilla.redhat.com/show_bug.cgi?id=768639
Signed-off-by: Pavel Roskin <proski@gnu.org>
Cc: stable@vger.kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add ATH_DBG_ to macros to shorten the uses and
reduce the line count.
Coalesce ath_dbg formats.
Add missing spaces to coalesced formats.
Add missing newline terminations to ath_dbg formats.
Align ath_dbg arguments where appropriate.
Standardize ath_dbg formats without periods.
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The stations always chooses 1Mbps for all trasmitting frames,
whenever the AP is configured to lock the supported rates.
As the max phy rate is always set with the 4th from highest phy rate,
this assumption might be wrong if we have less than that. Fix that.
Cc: stable@kernel.org
Cc: Paul Stewart <pstew@google.com>
Reported-by: Ajay Gummalla <agummalla@google.com>
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
These were getting the macros from an implicit module.h
include via device.h, but we are planning to clean that up.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
drivers/net: Add export.h to wireless/brcm80211/brcmfmac/bcmsdh.c
This relatively recently added file uses EXPORT_SYMBOL and hence
needs export.h included so that it is compatible with the module.h
split up work.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Fill the ampdu_[ack]_len for both aggregation and normal frames.
So that we could avoid unnecesary conditional at tx status.
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In congested network, having all rate reties at MCS rates
is failing to transmit the frame offenly. By the time reaching
the success rate set, the application gets timed out. One such
scenario is that authentication time out during 4-Way handshake.
This patch uses a legacy rate as last retry sequnce for
unaggregated frames or if the first selected rate's PER is ~80%
of max limit. And also observed from the tx status that the frame
was trasmitted successfully by using legacy rates.
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
for the ease of debugging, we display only the rate control statistics
for currently operating mode and bandwidth
Cc: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
Cc: "Balasubramanian, senthilkumar" <senthilb@qca.qualcomm.com>
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Whenever there is a channel width change from 40 Mhz to 20 Mhz,
the hardware is reconfigured to ht20. Meantime before doing
the rate control updation, the packets are being transmitted are
selected rate with IEEE80211_TX_RC_40_MHZ_WIDTH.
While transmitting ht40 rate packets in ht20 mode is causing
baseband panic with AR9003 based chips.
==== BB update: BB status=0x02001109 ====
ath: ** BB state: wd=1 det=1 rdar=0 rOFDM=1 rCCK=1 tOFDM=0 tCCK=0 agc=2
src=0 **
ath: ** BB WD cntl: cntl1=0xffff0085 cntl2=0x00000004 **
ath: ** BB mode: BB_gen_controls=0x000033c0 **
ath: ** BB busy times: rx_clear=99%, rx_frame=0%, tx_frame=0% **
ath: ==== BB update: done ====
Cc: stable@kernel.org
Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Check whether index is within bounds before testing the element
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
With the recent tx status optimization in mac80211, we bail out as
and and when invalid rate index is found. So the behavior of resetting
rate idx to -1 and count to 0 has changed for the rate indexes that
were not part of the driver's retry series.
This has resulted in ath9k using incorrect rate table index which
caused the system to panic. Ideally ath9k need to loop only for the
indexes that were part of the retry series and so simply use hw->max_rates
as the loop counter.
Pasted the stack trace of the panic issue for reference.
[ 754.093192] BUG: unable to handle kernel paging request at ffff88046a9025b0
[ 754.093256] IP: [<ffffffffa02eac49>] ath_tx_status+0x209/0x2f0 [ath9k]
[ 754.094888] Call Trace:
[ 754.094903] <IRQ>
[ 754.094928] [<ffffffffa051f883>] ieee80211_tx_status+0x203/0x9e0 [mac80211]
[ 754.094975] [<ffffffffa053e305>] ? __ieee80211_wake_queue+0x125/0x140 [mac80211]
[ 754.095017] [<ffffffffa02e66c9>] ath_tx_complete_buf+0x1b9/0x370 [ath9k]
[ 754.095054] [<ffffffffa02e6fcf>] ath_tx_complete_aggr+0x51f/0xb50 [ath9k]
[ 754.095098] [<ffffffffa05382a3>] ? ieee80211_prepare_and_rx_handle+0x173/0xab0 [mac80211]
[ 754.095148] [<ffffffff81350e62>] ? _raw_spin_unlock_irqrestore+0x32/0x40
[ 754.095186] [<ffffffffa02e9735>] ath_tx_tasklet+0x365/0x4b0 [ath9k]
[ 754.095224] [<ffffffff8107a2a2>] ? clockevents_program_event+0x62/0xa0
[ 754.095261] [<ffffffffa02e2628>] ath9k_tasklet+0x168/0x1c0 [ath9k]
[ 754.095298] [<ffffffff8105599b>] tasklet_action+0x6b/0xe0
[ 754.095331] [<ffffffff81056278>] __do_softirq+0x98/0x120
[ 754.095361] [<ffffffff8100cd5c>] call_softirq+0x1c/0x30
[ 754.095393] [<ffffffff8100efb5>] do_softirq+0x65/0xa0
[ 754.095423] [<ffffffff810563fd>] irq_exit+0x8d/0x90
[ 754.095453] [<ffffffff8100ebc1>] do_IRQ+0x61/0xe0
[ 754.095482] [<ffffffff81351413>] ret_from_intr+0x0/0x15
[ 754.095513] <EOI>
[ 754.095531] [<ffffffff81014375>] ? native_sched_clock+0x15/0x70
[ 754.096475] [<ffffffffa02bcfa6>] ? acpi_idle_enter_bm+0x24d/0x285 [processor]
[ 754.096475] [<ffffffffa02bcf9f>] ? acpi_idle_enter_bm+0x246/0x285 [processor]
[ 754.096475] [<ffffffff8127fab2>] cpuidle_idle_call+0x82/0x100
[ 754.096475] [<ffffffff8100a236>] cpu_idle+0xa6/0xf0
[ 754.096475] [<ffffffff81339bc1>] rest_init+0x91/0xa0
[ 754.096475] [<ffffffff814efccd>] start_kernel+0x3fd/0x408
[ 754.096475] [<ffffffff814ef347>] x86_64_start_reservations+0x132/0x136
[ 754.096475] [<ffffffff814ef451>] x86_64_start_kernel+0x106/0x115
[ 754.096475] RIP [<ffffffffa02eac49>] ath_tx_status+0x209/0x2f0 [ath9k]
Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Remove some obvious looking dead code and rename few functions
Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Allow drivers or rate control algorithms to specify BlockAck session
timeout when initiating an ADDBA transaction. This is useful in cases
where maintaining persistent BA sessions does not incur any overhead.
The current timeout value of 5000 TUs is retained for all non ath9k/ath9k_htc
drivers.
Signed-off-by: Sujith Manoharan <Sujith.Manoharan@atheros.com>
Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Remove ath/debug.h and the includes of these files.
Coalesce long formats.
Correct a few misspellings and missing "\n"s from these logging messages.
Remove unnecessary trailing space before a newline.
Remove ARRAY_SIZE casts, use printf type %zu
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
So these errors are always emitted at KERN_ERR level.
Remove ARRAY_SIZE casts, use printf type %zu
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This should help with latency issues which can happen when
using aggregation.
Cc: Matt Smith <matt.smith@atheros.com>
Cc: Senthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This takes care that boolean types are properly assigned
Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
With the current rate control selection method the median function is
nowhere used, so remove it.
Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The index variable to access the rate flags should be obtained from the
inner loop counter which corresponds to the rate table structure.This
fixes the invalid rate selection i.e when the supported basic rate is
invalid on a particular band and also the following warning message.
Thanks to Raj for finding this out.
Call Trace:
[<ffffffff8104ee4a>] warn_slowpath_common+0x7a/0xb0
[<ffffffff8104ee95>] warn_slowpath_null+0x15/0x20
[<ffffffffa0583c45>] ath_get_rate+0x595/0x5b0 [ath9k]
[<ffffffff811a0636>] ? cpumask_next_and+0x36/0x50
[<ffffffffa0405186>] rate_control_get_rate+0x86/0x160 [mac80211]
[<ffffffffa040dfac>] invoke_tx_handlers+0x81c/0x12d0 [mac80211]
[<ffffffffa040eae9>] ieee80211_tx+0x89/0x2b0 [mac80211]
[<ffffffff812891bc>] ? pskb_expand_head+0x1cc/0x1f0
[<ffffffffa040edc5>] ieee80211_xmit+0xb5/0x1c0 [mac80211]
[<ffffffffa041026f>] ieee80211_tx_skb+0x4f/0x60 [mac80211]
[<ffffffffa03fe016>] ieee80211_send_nullfunc+0x46/0x60 [mac80211]
[<ffffffffa03f91d7>] ieee80211_offchannel_stop_station+0x107/0x150
[mac80211]
[<ffffffff812891bc>] ? pskb_expand_head+0x1cc/0x1f0
[<ffffffffa040edc5>] ieee80211_xmit+0xb5/0x1c0 [mac80211]
[<ffffffffa041026f>] ieee80211_tx_skb+0x4f/0x60 [mac80211]
[<ffffffffa03fe016>] ieee80211_send_nullfunc+0x46/0x60 [mac80211]
[<ffffffffa03f91d7>] ieee80211_offchannel_stop_station+0x107/0x150
[mac80211]
[<ffffffffa03f8896>] ieee80211_scan_work+0x146/0x600 [mac80211]
[<ffffffff8133a375>] ? schedule+0x2f5/0x8e0
[<ffffffffa03f8750>] ? ieee80211_scan_work+0x0/0x600 [mac80211]
[<ffffffff81064fcf>] process_one_work+0x10f/0x380
[<ffffffff81066bc2>] worker_thread+0x162/0x340
[<ffffffff81066a60>] ? worker_thread+0x0/0x340
Cc: stable@kernel.org
Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The wireless mode bitfield was only used to detect 2.4 and 5 GHz support,
which can be simplified by using ATH9K_HW_CAP_* capabilities.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Set the rate table in the rc module properly based on band and
HT capabilities instead, which was already partially done, but
not for every mode.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Move them to the same debugfs file that the other rc modules use.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This fix updates the documenation in Rate Control Table structure
Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch attempts to ensure that ath9k's built-in rate control algorithm
does not rely on the value of the ampdu_len and ampdu_ack_len tx status
fields unless the IEEE80211_TX_STAT_AMPDU flag is set.
This patch has not been tested.
Cc: <stable@kernel.org>
Signed-off-by: Björn Smedman <bjorn.smedman@venatech.se>
Acked-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
It is not used anywhere else and can be made static
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
base index is not used anymore and so remove it.
Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The user ratekbs of MCS15 ShortGI is incorrect and can not be lesser
than MCS15 rate. This incorrect rate may affect switching to higher
rates as the rate control algorithm always finds MCS15 is better
than MCS15 ShortGI and results in lower throughput. Fix this by
feeding the correct user ratekbs for MCS15 ShortGI rate.
This issue affects 3 stream case very badly as the 3 stream rates are
not used at all once we scale down to MCS15 from 3 stream rates.
Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch adds 3 stream rate control support for AR938X family
chipsets which supports 3 streams.
Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
replace valid and valid_single_stream in rate table with bit masks
and reorganize the code so adding 3x3 rate control would be easier.
Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
mac80211 already masks the HT sta capabilities based on hardware support
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The following commit added an entry in 11na and 11ng rate
table but missed to update its rate count field. This
inconsistency between the rate count and the actual number
of rates in the table will leave out the final rate entry
(mcs15 with half gi in ht40) while forming the valid
rate indices. Not having mcs15+shortGI in ht40 will have
a performance impact (on max throughput) of about 10% both
in nght40 and naht40 mode.
Author: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Date: Thu May 13 18:42:38 2010 -0700
ath9k: Enable Short GI in 20 Mhz for ar9287 and later chips
This patch enables short GI rx at all rates and tx at mcs15
for 20 Mhz channel width also.
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch enables short GI rx at all rates and tx at mcs15
for 20 Mhz channel width also.
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
LDPC is enabled by the rate control if the its determined
that the target peer supports LDPC. We would have already
intersected the HT capabilities so if our peer supports
LDPC so do we.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
