Re: [ath9k-devel] [PATCH 0/5] eliminate some ath9k_htc code
Please do not apply this patch set, it will need some changes. Am 20.01.2014 19:48, schrieb Oleksij Rempel: Ath9k_htc has too match outdated copy/paste from ath9k. This patch set trying to remove some of it and make some function common to both drivers. Oleksij Rempel (5): ath: add last_rssi to ath_common ath9k: move ath9k_process_rssi to common.c ath9k: move ath9k_process_rate to common.c ath9k: move ath9k_rx_accept to common.c ath9k_htc: rework ath9k_rx_prepare and make use of common funcs drivers/net/wireless/ath/ath.h| 2 + drivers/net/wireless/ath/ath9k/ath9k.h| 1 - drivers/net/wireless/ath/ath9k/common.c | 192 +++ drivers/net/wireless/ath/ath9k/common.h | 14 ++ drivers/net/wireless/ath/ath9k/htc.h | 1 - drivers/net/wireless/ath/ath9k/htc_drv_init.c | 1 + drivers/net/wireless/ath/ath9k/htc_drv_main.c | 1 + drivers/net/wireless/ath/ath9k/htc_drv_txrx.c | 149 ++ drivers/net/wireless/ath/ath9k/init.c | 2 +- drivers/net/wireless/ath/ath9k/mac.h | 9 +- drivers/net/wireless/ath/ath9k/main.c | 2 +- drivers/net/wireless/ath/ath9k/recv.c | 211 ++ 12 files changed, 270 insertions(+), 315 deletions(-) -- Regards, Oleksij signature.asc Description: OpenPGP digital signature ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH] ath9k: Fix uninitialized variable in ath9k_has_tx_pending()
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
---
This doesn't look like a false positive to me
drivers/net/wireless/ath/ath9k/main.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/main.c
b/drivers/net/wireless/ath/ath9k/main.c
index 5924f72dd493..f08d5051c13f 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -1866,7 +1866,7 @@ static void ath9k_set_coverage_class(struct ieee80211_hw
*hw, u8 coverage_class)
static bool ath9k_has_tx_pending(struct ath_softc *sc)
{
- int i, npend;
+ int i, npend = 0;
for (i = 0; i ATH9K_NUM_TX_QUEUES; i++) {
if (!ATH_TXQ_SETUP(sc, i))
--
1.7.9.5
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] How to lock AMPDU length at a specific value?
Hi, Thank you for your reply. This fixed half of the problem. If the link quality is good all A-MPDUs are at the maximum length, however if the link quality is not good (high error) many A-MPDUs are smaller than the maximum A-MPDU length. As mentioned before it has something to do with the block ack window. If I set retry limit to 1 shouldn't this fix the problem? This way we don't care what happens to the frame, as we wont retransmit anyways. I have modified the minstrel_ht to lock the retry at 1 (i.e., ar[0].count = 1, and ar[1].idx=-1 ar[1].count=0). However the printk in tx_status sometimes shows attempts higher than 1. Why is that? Thank you, Ali On 23/01/2014 00:06, Shinnazar wrote: Hi Ali, Iperf has some strange behavior like this. Now you try to run 2 or 3 parallel iperf threads, for example smth like this: iperf -c Receiver address -u -t 10 -i 1 -b 50m -p 2. Hope this will help. BE, Shinnazar --- Original Message --- *From : *Ali Abedi a2ab...@uwaterloo.ca *To : *ath9k-devel ath9k-de...@venema.h4ckr.net *CC : *Kamran Nishat kamran.nis...@gmail.com ,Shinnazar seytnazarov...@ynu.ac.kr *Sent : *2014-01-23 00:51:23 *Subject : *Re: [ath9k-devel] How to lock AMPDU length at a specific value? Thanks for all the replies. Sorry for not mentioning that I actually saturate the link. I use iperf and I set the application data rate to something way more that the mac throughput. The strange thing is that not all A-MPDUs are at the maximum size. Here is some results I got from the driver for different max A-MPDU sizes (High app data rate). left column is #frames and the column is #bad-frames Mac data rate = 65 Mbps fixed. App data rate = 100 Mbps I directly print these stats from xmit.c in ath_tx_complete_agg(), after the call to function ath_tx_count_frames(). I print nframes and nbad variables. max A-mpdu size = 10 * 1550 B 10 0 10 0 10 0 10 0 10 0 10 0 10 0 10 0 10 0 Everything is fine all A-MPDUs have 10 frames --- max A-mpdu size = 20 * 1550 B 20 0 20 0 20 0 9 0 20 0 20 0 1 0 20 0 20 0 8 0 20 0 Sometimes a-mpdus with fewer frames than 20 --- Max A-mpdu size = 32 * 1550 B 8 0 32 0 2 0 32 32 3 0 32 0 1 0 32 0 4 4 1 0 32 32 It happens even more frequently. Is there a solution to this problem? Thank you, Ali On 14-01-22 02:08 AM, Kamran Nishat wrote: Yeah, My initial premise was that u have saturated traffic from upper layers. But now I think u have some application level requirements (data rate is less than max PHY rate). In this case I would advise you to add wait in mac80211. Because as far as I know ath9k driven by its calls and calls by driver. Regards, kamran On Wed, Jan 22, 2014 at 10:19 AM, Shinnazar seytnazarov...@ynu.ac.kr mailto:seytnazarov...@ynu.ac.kr wrote: Hi Ali, If I were you, I would try to make the Software queue always full of frames and then specify ampdu lenfth in ath_tx_form_aggr(). BR, Shinnazar --- Original Message --- *From : *Ali Abedi a2ab...@uwaterloo.ca mailto:a2ab...@uwaterloo.ca *To : *ath9k-de...@venema.h4ckr.net mailto:ath9k-de...@venema.h4ckr.net *CC : * *Sent : *2014-01-22 06:40:18 *Subject : *Re: [ath9k-devel] Fwd: How to lock AMPDU length at a specific value? ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org mailto:ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel Using a constant rate does not help (I am already doing this). When I set the limit to 20 for example, I get any number between 1 to 20 for the number of aggregated frames. This is probably because when we want to start the transmission we don't always have 20 frames to aggregate so the card aggregates all it already has in the queue ready for transmission. So how can we wait to have 20 frames ready for transmission so that all aggregate frames carry exactly 20 frames (constant rate)? Thank you, Ali On 21/01/2014 15:59, Kamran Nishat wrote: do it at a fix rate (1st check if duration of packet is less tahn 4ms for ur MCS) and with nearly zero noise losses. Kamran On Wed, Jan 22, 2014 at 1:54 AM, Ali Abedi a2ab...@uwaterloo.ca
Re: [ath9k-devel] How to lock AMPDU length at a specific value?
Thank you. I checked ath_tx_form_aggr() and the condition that checks: do not step over block-ack window causes the A-MPDU length limitation. So is there anything to do to force max A-MPDU length? Does setting retry to 1 solves this problem? My understanding is that if retry is 1 then we move the BA window anyway (regardless of frame error) by 32 each time. Is this right? Thanks, Ali On 22/01/2014 11:02, Kamran Nishat wrote: Check if they are probe or not. Probes can have different size. other thing but prints in ath_tx_form_aggr() as i mentioned before check which condition is stopping the loop. One more thing there are some losses. In case of losses BlockAck window BAW will stop aggregate from growing. kamran On Wed, Jan 22, 2014 at 8:51 PM, Ali Abedi a2ab...@uwaterloo.ca mailto:a2ab...@uwaterloo.ca wrote: Thanks for all the replies. Sorry for not mentioning that I actually saturate the link. I use iperf and I set the application data rate to something way more that the mac throughput. The strange thing is that not all A-MPDUs are at the maximum size. Here is some results I got from the driver for different max A-MPDU sizes (High app data rate). left column is #frames and the column is #bad-frames Mac data rate = 65 Mbps fixed. App data rate = 100 Mbps I directly print these stats from xmit.c in ath_tx_complete_agg(), after the call to function ath_tx_count_frames(). I print nframes and nbad variables. max A-mpdu size = 10 * 1550 B 100 100 100 100 100 100 100 100 100 Everything is fine all A-MPDUs have 10 frames --- max A-mpdu size = 20 * 1550 B 200 200 200 90 200 200 10 200 200 80 200 Sometimes a-mpdus with fewer frames than 20 --- Max A-mpdu size = 32 * 1550 B 80 320 20 3232 30 320 10 320 44 10 3232 It happens even more frequently. Is there a solution to this problem? Thank you, Ali On 14-01-22 02:08 AM, Kamran Nishat wrote: Yeah, My initial premise was that u have saturated traffic from upper layers. But now I think u have some application level requirements (data rate is less than max PHY rate). In this case I would advise you to add wait in mac80211. Because as far as I know ath9k driven by its calls and calls by driver. Regards, kamran On Wed, Jan 22, 2014 at 10:19 AM, Shinnazar seytnazarov...@ynu.ac.kr mailto:seytnazarov...@ynu.ac.kr wrote: Hi Ali, If I were you, I would try to make the Software queue always full of frames and then specify ampdu lenfth in ath_tx_form_aggr(). BR, Shinnazar --- Original Message --- *From : *Ali Abedi a2ab...@uwaterloo.ca mailto:a2ab...@uwaterloo.ca *To : *ath9k-de...@venema.h4ckr.net mailto:ath9k-de...@venema.h4ckr.net *CC : * *Sent : *2014-01-22 06:40:18 *Subject : *Re: [ath9k-devel] Fwd: How to lock AMPDU length at a specific value? ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org mailto:ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel Using a constant rate does not help (I am already doing this). When I set the limit to 20 for example, I get any number between 1 to 20 for the number of aggregated frames. This is probably because when we want to start the transmission we don't always have 20 frames to aggregate so the card aggregates all it already has in the queue ready for transmission. So how can we wait to have 20 frames ready for transmission so that all aggregate frames carry exactly 20 frames (constant rate)? Thank you, Ali On 21/01/2014 15:59, Kamran Nishat wrote: do it at a fix rate (1st check if duration of packet is less tahn 4ms for ur MCS) and with nearly zero noise losses. Kamran On Wed, Jan 22, 2014 at 1:54 AM, Ali Abedi a2ab...@uwaterloo.ca mailto:a2ab...@uwaterloo.ca wrote: These mostly determine the MAX AMPDU length. I also want to determine the minimum length, so that I can set min=max and lock the AMPDU length. Thank you, Ali On 21/01/2014 15:07, Kamran Nishat wrote: As far as i know AMPDU length is determined by 3 constraints. Firs maximum AMPDU
[ath9k-devel] ath9k ARM build error with v3.13-8330-g4ba9920
Hi All, This commit: commit 4dc78c437a0a2ac152a2b2c5e91a814a6ef3599e Author: Sujith Manoharan c_man...@qca.qualcomm.com Date: Wed Dec 18 09:53:26 2013 +0530 ath9k: Fix RTC reset delay The delay that is required after issuing a RTC reset varies for each chip. Handle this properly. Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com Signed-off-by: John W. Linville linvi...@tuxdriver.com adds a udelay(1) call to the ath9k driver. This will cause a build error on various ARM configs because the value passed to udelay is too large: ERROR: __bad_udelay [drivers/net/wireless/ath/ath9k/ath9k_hw.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 Is the 1 microsecond udelay really required? I believe the limit on ARM is 2000. Perhaps something else could be done in this case? josh ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] How to lock AMPDU length at a specific value?
Thank you. I checked ath_tx_form_aggr() and the condition that checks: do not step over block-ack window causes the A-MPDU length limitation. So is there anything to do to force max A-MPDU length? *YES! we told you earlier if link is lossy then this limit will not let AMPDU to increase.* Does setting retry to 1 solves this problem? My understanding is that if retry is 1 then we move the BA window anyway (regardless of frame error) by 32 each time. Is this right? *As far as we know HW does the AMPDU retries. while SW retries are done if **ATH_MAX_SW_RETRIES is not achieved( ath_tx_complete_aggr in xmit.c**) * On Sun, Jan 26, 2014 at 9:25 PM, Ali Abedi a2ab...@uwaterloo.ca wrote: Thank you. I checked ath_tx_form_aggr() and the condition that checks: do not step over block-ack window causes the A-MPDU length limitation. So is there anything to do to force max A-MPDU length? Does setting retry to 1 solves this problem? My understanding is that if retry is 1 then we move the BA window anyway (regardless of frame error) by 32 each time. Is this right? Thanks, Ali On 22/01/2014 11:02, Kamran Nishat wrote: Check if they are probe or not. Probes can have different size. other thing but prints in ath_tx_form_aggr() as i mentioned before check which condition is stopping the loop. One more thing there are some losses. In case of losses BlockAck window BAW will stop aggregate from growing. kamran On Wed, Jan 22, 2014 at 8:51 PM, Ali Abedi a2ab...@uwaterloo.ca wrote: Thanks for all the replies. Sorry for not mentioning that I actually saturate the link. I use iperf and I set the application data rate to something way more that the mac throughput. The strange thing is that not all A-MPDUs are at the maximum size. Here is some results I got from the driver for different max A-MPDU sizes (High app data rate). left column is #frames and the column is #bad-frames Mac data rate = 65 Mbps fixed. App data rate = 100 Mbps I directly print these stats from xmit.c in ath_tx_complete_agg(), after the call to function ath_tx_count_frames(). I print nframes and nbad variables. max A-mpdu size = 10 * 1550 B 100 100 100 100 100 100 100 100 100 Everything is fine all A-MPDUs have 10 frames --- max A-mpdu size = 20 * 1550 B 200 200 200 90 200 200 10 200 200 80 200 Sometimes a-mpdus with fewer frames than 20 --- Max A-mpdu size = 32 * 1550 B 80 320 20 3232 30 320 10 320 44 10 3232 It happens even more frequently. Is there a solution to this problem? Thank you, Ali On 14-01-22 02:08 AM, Kamran Nishat wrote: Yeah, My initial premise was that u have saturated traffic from upper layers. But now I think u have some application level requirements (data rate is less than max PHY rate). In this case I would advise you to add wait in mac80211. Because as far as I know ath9k driven by its calls and calls by driver. Regards, kamran On Wed, Jan 22, 2014 at 10:19 AM, Shinnazar seytnazarov...@ynu.ac.krwrote: Hi Ali, If I were you, I would try to make the Software queue always full of frames and then specify ampdu lenfth in ath_tx_form_aggr(). BR, Shinnazar --- Original Message --- *From : *Ali Abedi a2ab...@uwaterloo.ca *To : *ath9k-de...@venema.h4ckr.net *CC : * *Sent : *2014-01-22 06:40:18 *Subject : *Re: [ath9k-devel] Fwd: How to lock AMPDU length at a specific value? ___ ath9k-devel mailing listath9k-devel@lists.ath9k.orghttps://lists.ath9k.org/mailman/listinfo/ath9k-devel Using a constant rate does not help (I am already doing this). When I set the limit to 20 for example, I get any number between 1 to 20 for the number of aggregated frames. This is probably because when we want to start the transmission we don't always have 20 frames to aggregate so the card aggregates all it already has in the queue ready for transmission. So how can we wait to have 20 frames ready for transmission so that all aggregate frames carry exactly 20 frames (constant rate)? Thank you, Ali On 21/01/2014 15:59, Kamran Nishat wrote: do it at a fix rate (1st check if duration of packet is less tahn 4ms for ur MCS) and with nearly zero noise losses. Kamran On Wed, Jan 22, 2014 at 1:54 AM, Ali Abedi a2ab...@uwaterloo.cawrote: These mostly determine the MAX AMPDU length. I also want to determine the minimum length, so that I can set min=max and lock the AMPDU length. Thank you, Ali On 21/01/2014 15:07, Kamran Nishat wrote: As far as i know AMPDU length is determined by 3 constraints. Firs maximum AMPDU length. second blockAck window (if there were losses then this will play a role). Third is Max air time of the AMPDU which is 4ms for some domain constraints. this comes into play
Re: [ath9k-devel] ath9k ARM build error with v3.13-8330-g4ba9920
Josh Boyer wrote: adds a udelay(1) call to the ath9k driver. This will cause a build error on various ARM configs because the value passed to udelay is too large: ERROR: __bad_udelay [drivers/net/wireless/ath/ath9k/ath9k_hw.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 Is the 1 microsecond udelay really required? I believe the limit on ARM is 2000. Perhaps something else could be done in this case? The delay is a workaround for a HW issue. Does this patch fix the problem ? diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c index fbf43c0..11eab9f 100644 --- a/drivers/net/wireless/ath/ath9k/hw.c +++ b/drivers/net/wireless/ath/ath9k/hw.c @@ -1316,7 +1316,7 @@ static bool ath9k_hw_set_reset(struct ath_hw *ah, int type) if (AR_SREV_9300_20_OR_LATER(ah)) udelay(50); else if (AR_SREV_9100(ah)) - udelay(1); + mdelay(10); else udelay(100); @@ -2051,9 +2051,8 @@ static bool ath9k_hw_set_power_awake(struct ath_hw *ah) REG_SET_BIT(ah, AR_RTC_FORCE_WAKE, AR_RTC_FORCE_WAKE_EN); - if (AR_SREV_9100(ah)) - udelay(1); + mdelay(10); else udelay(50); Sujith ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] IBSS can't beacon after rejoin / regression in TSF syncing code?
Simon Wunderlich wrote:
we have found a regression in the IBSS creation/joining part of mac80211
which
is appearently connected to the TSF-syncing patches introduced last year[1].
It prevents beaconing of an adhoc member after rejoining a cell when this
cell
is currently empty. The problem is present in at least 3.10 and 3.13.
To reproduce, use two adhoc peers and let them join/leave in the following
order:
station 1: join
station 2: join
station 2: leave
station 1: leave
station 1: join
now we would expect that station 1 sends beacons, but it doesn't. After
inspecting the code, station 1 actually selected the old ibss network and
waits for a beacon to sync the tsf which is never received, as all members
already left the network. An easy workaround is to set the IBSS creator
always
to true.
The race condition is that station-1 (the creator) removes station-2 only
after a while, based on the expiration/inactive timer.
The small window that IEEE80211_IBSS_MERGE_INTERVAL introduces when
ieee80211_ibss_disconnect() is called causes the race, since we assume that
station-2 is still active and do not remove the BSS from cfg80211.
I am not sure why we have to keep the BSS around when we are leaving the
network.
Is this patch the right approach ?
diff --git a/net/mac80211/ibss.c b/net/mac80211/ibss.c
index 771080e..e1688cd 100644
--- a/net/mac80211/ibss.c
+++ b/net/mac80211/ibss.c
@@ -688,17 +688,18 @@ static int ieee80211_sta_active_ibss(struct
ieee80211_sub_if_data *sdata)
return active;
}
-static void ieee80211_ibss_disconnect(struct ieee80211_sub_if_data *sdata)
+static void ieee80211_ibss_disconnect(struct ieee80211_sub_if_data *sdata,
bool leave)
{
struct ieee80211_if_ibss *ifibss = sdata-u.ibss;
struct ieee80211_local *local = sdata-local;
struct cfg80211_bss *cbss;
struct beacon_data *presp;
struct sta_info *sta;
- int active_ibss;
+ int active_ibss = 0;
u16 capability;
- active_ibss = ieee80211_sta_active_ibss(sdata);
+ if (!leave)
+ active_ibss = ieee80211_sta_active_ibss(sdata);
if (!active_ibss !is_zero_ether_addr(ifibss-bssid)) {
capability = WLAN_CAPABILITY_IBSS;
@@ -765,7 +766,7 @@ static void ieee80211_csa_connection_drop_work(struct
work_struct *work)
sdata_lock(sdata);
- ieee80211_ibss_disconnect(sdata);
+ ieee80211_ibss_disconnect(sdata, false);
synchronize_rcu();
skb_queue_purge(sdata-skb_queue);
@@ -1721,7 +1722,7 @@ int ieee80211_ibss_leave(struct ieee80211_sub_if_data
*sdata)
{
struct ieee80211_if_ibss *ifibss = sdata-u.ibss;
- ieee80211_ibss_disconnect(sdata);
+ ieee80211_ibss_disconnect(sdata, true);
ifibss-ssid_len = 0;
memset(ifibss-bssid, 0, ETH_ALEN);
Sujith
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
