Hi Marek,
>> I tried to capture logs but when enable DYNAMIC_DEBUG I cannot
>> reproduce issue (running test > 30 minutes without allocation
>> failure).
Thanks for the testing. Yes. Sometimes timing issues won't get reproduced with
debug messages enabled.
>Any update on this? Should I provide some other logs?
What's the size of Rx data packets? Is the Rx data AMSDU aggregated?(You can
check if "if (rx_pkt_type == PKT_TYPE_AMSDU)" check is passed in mwifiex code)
If so, disable AMSDU option in AP and try to reproduce the issue.
As you suspected earlier, we might have missed to free skbs allocated for Rx
data which leads to SKB allocation failure. There is very less probability for
this. But we can try below experiment.
1) I observed that debug variable "adapter->rx_pending" doesn;t get decremented
when packet is submitted to kernel. Add below code change(valid only for AMSDU
disabled case. Because multiple packets are submitted to kernel when AMSDU is
enabled)
----------
--- a/drivers/net/wireless/mwifiex/util.c
+++ b/drivers/net/wireless/mwifiex/util.c
@@ -218,6 +218,7 @@ int mwifiex_recv_packet(struct mwifiex_private *priv,
struct sk_buff *skb)
priv->stats.rx_bytes += skb->len;
priv->stats.rx_packets++;
+ atomic_dec(&priv->adapter->rx_pending);
if (in_interrupt())
netif_rx(skb);
----------
2) Add BUG_ON when first time SKB allocation is failed and print "rx_pending".
If it's a huge number, we have missed freeing allocated SKB.
3) Also, get rx_pending info when Rx traffic works fine with 40M bandwidth
option.
Btw, could you move to the firmware image (14.68.29.p38)
shared recently?
By any means(redirecting the log to serial console etc.), could you please
capture and share kernel trace logs when system becomes unresponsive. It may
give some clue and help us debug further.
Best Regards,
Amit--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
