Dear Amitkumar Karwar,
On Mon, Oct 13, 2014 at 3:41 PM, Amitkumar Karwar <akarwar@xxxxxxxxxxx> wrote:
> Hi Marek,
>
>>>
>>> That's good :) Actually kernel will take care of freeing skb when
>>driver submits received packet using netif_rx(). Could you please share
>>your hack?
>>Yes it should be freed when netif_rx() is processed but I have feeling
>>that sometimes (my case) during high load (-b 100m) packets are not send
>>to kernel (not free skb) until skb allocation fails. I need to better
>>understand 11n reordering code :).
>
> Rx reorder logic can buffer upto 32 packets, if they aren't received in correct order. You are right. Your platform may run out of memory in this case.
> Could you please check if the problem fixes with any of the attached changes?
> 1) Change Rx window size from 32 to 8.
> 2) Disable AMPDU feature.
Thanks for patches.
I tried both (slightly modified as we're in 3.9 kernel) but issue is
still reproducible. My patch against 3.9 sources:
diff --git a/drivers/net/wireless/mwifiex/decl.h
b/drivers/net/wireless/mwifiex/decl.h
index e8a569a..916924c 100644
--- a/drivers/net/wireless/mwifiex/decl.h
+++ b/drivers/net/wireless/mwifiex/decl.h
@@ -42,7 +42,7 @@
#define MWIFIEX_MAX_RX_BASTREAM_SUPPORTED 16
#define MWIFIEX_AMPDU_DEF_TXWINSIZE 32
-#define MWIFIEX_AMPDU_DEF_RXWINSIZE 16
+#define MWIFIEX_AMPDU_DEF_RXWINSIZE 8
#define MWIFIEX_DEFAULT_BLOCK_ACK_TIMEOUT 0xffff
#define MWIFIEX_RATE_BITMAP_MCS0 32
diff --git a/drivers/net/wireless/mwifiex/sta_event.c
b/drivers/net/wireless/mwifiex/sta_event.c
index 41aafc7..05a36f0 100644
--- a/drivers/net/wireless/mwifiex/sta_event.c
+++ b/drivers/net/wireless/mwifiex/sta_event.c
@@ -378,10 +378,7 @@ int mwifiex_process_sta_event(struct mwifiex_private *priv)
HostCmd_ACT_GEN_GET, 0, NULL);
break;
case EVENT_ADDBA:
- dev_dbg(adapter->dev, "event: ADDBA Request\n");
- mwifiex_send_cmd_async(priv, HostCmd_CMD_11N_ADDBA_RSP,
- HostCmd_ACT_GEN_SET, 0,
- adapter->event_body);
+ dev_dbg(adapter->dev, "event: ADDBA Request ignoring\n");
break;
case EVENT_DELBA:
dev_dbg(adapter->dev, "event: DELBA Request\n");
diff --git a/drivers/net/wireless/mwifiex/wmm.c
b/drivers/net/wireless/mwifiex/wmm.c
index 2670676..3d0aa02 100644
--- a/drivers/net/wireless/mwifiex/wmm.c
+++ b/drivers/net/wireless/mwifiex/wmm.c
@@ -415,8 +415,8 @@ mwifiex_wmm_init(struct mwifiex_adapter *adapter)
for (i = 0; i < MAX_NUM_TID; ++i) {
priv->aggr_prio_tbl[i].amsdu = tos_to_tid_inv[i];
- priv->aggr_prio_tbl[i].ampdu_ap = tos_to_tid_inv[i];
- priv->aggr_prio_tbl[i].ampdu_user = tos_to_tid_inv[i];
+ priv->aggr_prio_tbl[i].ampdu_ap = BA_STREAM_NOT_ALLOWED;
+ priv->aggr_prio_tbl[i].ampdu_user =
BA_STREAM_NOT_ALLOWED;
}
priv->aggr_prio_tbl[6].amsdu
One thing which is not yet still clear to me why kernel console is
completely unresponsive when
receiving packets in high rates. When use iperf (on client) with -b40m
it is OK but when increase to -b100m then console
is completely unresponsive until iperf finish. Any other ideas what to
change to check? Thanks.
>
>>
>>Hack (it's dirty I know but packets of that size are send only during
>>iperf session):
>>
>>diff --git a/drivers/net/wireless/mwifiex/usb.c
>>b/drivers/net/wireless/mwifiex/usb.c
>>index f90fe21..cc548a1 100644
>>--- a/drivers/net/wireless/mwifiex/usb.c
>>+++ b/drivers/net/wireless/mwifiex/usb.c
>>@@ -178,6 +178,12 @@ static void mwifiex_usb_rx_complete(struct urb
>>*urb)
>> dev_dbg(adapter->dev, "info: recv_length=%d,
>>status=%d\n",
>> recv_length, status);
>> if (status == -EINPROGRESS) {
>>+
>>+ if (skb->len >= 1574) {
>>+ dev_kfree_skb_any(skb);
>>+ goto setup_for_next;
>>+ }
>>+
>
> The change doesn't look correct. The skb is being processed/used. We cannot free it here. This may create problem.
>
> Regards,
> Amit
BR,
marek
--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer
Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
