pre-calibration is meant for qca4019 which contains only caldata
whereas calibration file is used by ar9888 and qca99x0 that contains
both board data and caldata. So by definition both pre-cal-file and
cal-file can not coexist. Keeping them in shared memory (union), is
breaking boot sequence of qca99x0. Fix it by storing both binaries
in separate memories. This issue is reported in ipq8064 platform which
includes caldata in flash memory.
Reported-by: Sebastian Gottschall <[email protected]>
Signed-off-by: Rajkumar Manoharan <[email protected]>
---
drivers/net/wireless/ath/ath10k/core.h | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index b6c157e..a7d04bc 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -725,10 +725,8 @@ struct ath10k {
const void *firmware_data;
size_t firmware_len;
- union {
- const struct firmware *pre_cal_file;
- const struct firmware *cal_file;
- };
+ const struct firmware *pre_cal_file;
+ const struct firmware *cal_file;
struct {
const void *firmware_codeswap_data;
--
2.7.4
On 03/30/2016 08:42 AM, Rajkumar Manoharan wrote:
> qca99x0 and qca4019 solutions limit probe responses transmissions.
> Logging warning message for each probe response drop is flooding
> kernel log unnecessary with " failed to increase tx mgmt pending
> count: -16, dropping". Hence reducing log level to debug.
Is there any realistic way to see this message if we are not running
many vAP on one radio?
I guess many probe requests or other management frames could also
cause this problem?
Thanks,
Ben
> Reported-by: Sebastian Gottschall <[email protected]>
> Signed-off-by: Rajkumar Manoharan <[email protected]>
> ---
> drivers/net/wireless/ath/ath10k/mac.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
> index ed00853..a7aafb35c 100644
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -3994,8 +3994,8 @@ static void ath10k_mac_op_tx(struct ieee80211_hw *hw,
>
> ret = ath10k_htt_tx_mgmt_inc_pending(htt, is_mgmt, is_presp);
> if (ret) {
> - ath10k_warn(ar, "failed to increase tx mgmt pending count: %d, dropping\n",
> - ret);
> + ath10k_dbg(ar, ATH10K_DBG_MAC, "failed to increase tx mgmt pending count: %d, dropping\n",
> + ret);
> ath10k_htt_tx_dec_pending(htt);
> spin_unlock_bh(&ar->htt.tx_lock);
> ieee80211_free_txskb(ar->hw, skb);
>
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
qca99x0 and qca4019 solutions limit probe responses transmissions.
Logging warning message for each probe response drop is flooding
kernel log unnecessary with " failed to increase tx mgmt pending
count: -16, dropping". Hence reducing log level to debug.
Reported-by: Sebastian Gottschall <[email protected]>
Signed-off-by: Rajkumar Manoharan <[email protected]>
---
drivers/net/wireless/ath/ath10k/mac.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index ed00853..a7aafb35c 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3994,8 +3994,8 @@ static void ath10k_mac_op_tx(struct ieee80211_hw *hw,
ret = ath10k_htt_tx_mgmt_inc_pending(htt, is_mgmt, is_presp);
if (ret) {
- ath10k_warn(ar, "failed to increase tx mgmt pending count: %d, dropping\n",
- ret);
+ ath10k_dbg(ar, ATH10K_DBG_MAC, "failed to increase tx mgmt pending count: %d, dropping\n",
+ ret);
ath10k_htt_tx_dec_pending(htt);
spin_unlock_bh(&ar->htt.tx_lock);
ieee80211_free_txskb(ar->hw, skb);
--
2.7.4
On 03/30/2016 08:42 AM, Rajkumar Manoharan wrote:
> Decrement num_mpdus_ready only when rx amsdu is processed successfully.
> Not doing so, will result in leak and impact stabilty under low memory
> cases.
Should this patch be rebased on top of the "ath10k: process htt rx indication as batch mode" patch?
Thanks,
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
Decrement num_mpdus_ready only when rx amsdu is processed successfully.
Not doing so, will result in leak and impact stabilty under low memory
cases.
Signed-off-by: Rajkumar Manoharan <[email protected]>
---
drivers/net/wireless/ath/ath10k/htt_rx.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 96a7417..9696c2e 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -2412,14 +2412,12 @@ static void ath10k_htt_txrx_compl_task(unsigned long ptr)
struct ath10k_htt *htt = (struct ath10k_htt *)ptr;
struct ath10k *ar = htt->ar;
struct htt_tx_done tx_done = {};
- struct sk_buff_head rx_q;
struct sk_buff_head rx_ind_q;
struct sk_buff_head tx_ind_q;
struct sk_buff *skb;
unsigned long flags;
int num_mpdus;
- __skb_queue_head_init(&rx_q);
__skb_queue_head_init(&rx_ind_q);
__skb_queue_head_init(&tx_ind_q);
@@ -2448,11 +2446,13 @@ static void ath10k_htt_txrx_compl_task(unsigned long ptr)
ath10k_mac_tx_push_pending(ar);
num_mpdus = atomic_read(&htt->num_mpdus_ready);
- atomic_sub(num_mpdus, &htt->num_mpdus_ready);
- while (num_mpdus--) {
+ while (num_mpdus) {
if (ath10k_htt_rx_handle_amsdu(htt))
break;
+
+ num_mpdus--;
+ atomic_dec(&htt->num_mpdus_ready);
}
while ((skb = __skb_dequeue(&rx_ind_q))) {
--
2.7.4
Rajkumar Manoharan <[email protected]> writes:
> On 2016-04-01 00:22, Ben Greear wrote:
>> On 03/30/2016 08:42 AM, Rajkumar Manoharan wrote:
>>> Decrement num_mpdus_ready only when rx amsdu is processed
>>> successfully.
>>> Not doing so, will result in leak and impact stabilty under low memory
>>> cases.
>>
>> Should this patch be rebased on top of the "ath10k: process htt rx
>> indication as batch mode" patch?
>>
> It should be on top of "ath10k: speedup htt rx descriptor processing
> for rx_ind". Instead of sending next version of original series, i
> sent it as follow up.
Should this commit log have a fixes line like this:
Fixes: 59465fe46ef1 ("ath10k: speedup htt rx descriptor processing for tx completion")
--
Kalle Valo
On 2016-03-31 22:27, Ben Greear wrote:
> On 03/30/2016 08:42 AM, Rajkumar Manoharan wrote:
>> qca99x0 and qca4019 solutions limit probe responses transmissions.
>> Logging warning message for each probe response drop is flooding
>> kernel log unnecessary with " failed to increase tx mgmt pending
>> count: -16, dropping". Hence reducing log level to debug.
>
> Is there any realistic way to see this message if we are not running
> many vAP on one radio?
>
As of now this message can be seen only with qca99x0 which has 24 as
max_probe_resp_desc_thres. Only possible way in single vAP is that in
congested environment when DUT is receiving probe requests more
frequently.
> I guess many probe requests or other management frames could also
> cause this problem?
>
Exactly.
-Rajkumar
On 2016-04-05 18:18, Valo, Kalle wrote:
> Rajkumar Manoharan <[email protected]> writes:
>
>> Decrement num_mpdus_ready only when rx amsdu is processed
>> successfully.
>> Not doing so, will result in leak and impact stabilty under low memory
>> cases.
>>
>> Signed-off-by: Rajkumar Manoharan <[email protected]>
>> ---
>> drivers/net/wireless/ath/ath10k/htt_rx.c | 8 ++++----
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c
>> b/drivers/net/wireless/ath/ath10k/htt_rx.c
>> index 96a7417..9696c2e 100644
>> --- a/drivers/net/wireless/ath/ath10k/htt_rx.c
>> +++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
>> @@ -2412,14 +2412,12 @@ static void
>> ath10k_htt_txrx_compl_task(unsigned long ptr)
>> struct ath10k_htt *htt = (struct ath10k_htt *)ptr;
>> struct ath10k *ar = htt->ar;
>> struct htt_tx_done tx_done = {};
>> - struct sk_buff_head rx_q;
>> struct sk_buff_head rx_ind_q;
>> struct sk_buff_head tx_ind_q;
>> struct sk_buff *skb;
>> unsigned long flags;
>> int num_mpdus;
>>
>> - __skb_queue_head_init(&rx_q);
>> __skb_queue_head_init(&rx_ind_q);
>> __skb_queue_head_init(&tx_ind_q);
>
> I guess you are removing the unused rx_q just as a cleanup? It's good
> practise to mention that in the commit log (or better yet in a separate
> patch).
update the commit log and send next version.
-Rajkumar
Rajkumar Manoharan <[email protected]> writes:
> pre-calibration is meant for qca4019 which contains only caldata
> whereas calibration file is used by ar9888 and qca99x0 that contains
> both board data and caldata. So by definition both pre-cal-file and
> cal-file can not coexist. Keeping them in shared memory (union), is
> breaking boot sequence of qca99x0. Fix it by storing both binaries
> in separate memories. This issue is reported in ipq8064 platform which
> includes caldata in flash memory.
>
> Reported-by: Sebastian Gottschall <[email protected]>
> Signed-off-by: Rajkumar Manoharan <[email protected]>
I added the fixes line in the pending branch:
Fixes: 3d9195ea19e4 ("ath10k: incorporate qca4019 cal data download sequence")
--
Kalle Valo
On 2016-04-05 18:10, Valo, Kalle wrote:
> Rajkumar Manoharan <[email protected]> writes:
>
>> pre-calibration is meant for qca4019 which contains only caldata
>> whereas calibration file is used by ar9888 and qca99x0 that contains
>> both board data and caldata. So by definition both pre-cal-file and
>> cal-file can not coexist. Keeping them in shared memory (union), is
>> breaking boot sequence of qca99x0. Fix it by storing both binaries
>> in separate memories. This issue is reported in ipq8064 platform which
>> includes caldata in flash memory.
>>
>> Reported-by: Sebastian Gottschall <[email protected]>
>> Signed-off-by: Rajkumar Manoharan <[email protected]>
>
> I added the fixes line in the pending branch:
>
> Fixes: 3d9195ea19e4 ("ath10k: incorporate qca4019 cal data download
> sequence")
Thanks.
-Rajkumar
On 2016-04-01 00:22, Ben Greear wrote:
> On 03/30/2016 08:42 AM, Rajkumar Manoharan wrote:
>> Decrement num_mpdus_ready only when rx amsdu is processed
>> successfully.
>> Not doing so, will result in leak and impact stabilty under low memory
>> cases.
>
> Should this patch be rebased on top of the "ath10k: process htt rx
> indication as batch mode" patch?
>
It should be on top of "ath10k: speedup htt rx descriptor processing for
rx_ind". Instead of sending next version of original series, i sent it
as follow up.
-Rajkumar
Rajkumar Manoharan <[email protected]> writes:
> Decrement num_mpdus_ready only when rx amsdu is processed successfully.
> Not doing so, will result in leak and impact stabilty under low memory
> cases.
>
> Signed-off-by: Rajkumar Manoharan <[email protected]>
> ---
> drivers/net/wireless/ath/ath10k/htt_rx.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
> index 96a7417..9696c2e 100644
> --- a/drivers/net/wireless/ath/ath10k/htt_rx.c
> +++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
> @@ -2412,14 +2412,12 @@ static void ath10k_htt_txrx_compl_task(unsigned long ptr)
> struct ath10k_htt *htt = (struct ath10k_htt *)ptr;
> struct ath10k *ar = htt->ar;
> struct htt_tx_done tx_done = {};
> - struct sk_buff_head rx_q;
> struct sk_buff_head rx_ind_q;
> struct sk_buff_head tx_ind_q;
> struct sk_buff *skb;
> unsigned long flags;
> int num_mpdus;
>
> - __skb_queue_head_init(&rx_q);
> __skb_queue_head_init(&rx_ind_q);
> __skb_queue_head_init(&tx_ind_q);
I guess you are removing the unused rx_q just as a cleanup? It's good
practise to mention that in the commit log (or better yet in a separate
patch).
--
Kalle Valo