[OpenWrt-Devel] Submitting PATCH for rtl8192cu HTmode deadlock

[Daniel Golle]

Hi!

I did quite some testing on the lamobo-r1 aka. bpi-r1 a couple of
weeks ago and didn't encounter any such issue -- however, I must
admit that I probably never had more than one client associated
and generating serious traffic simultanously.... (did you? i.e.
was there more than one client involved to trigger the deadlock
scenario?)

If needed for the board to work properly, I reckon the patch should
be temporarily included in package/kernel/mac80211/patches/.

Cheers


Daniel


On Wed, Apr 08, 2015 at 12:29:20PM -0400, Derek Werthmuller wrote:
> In reference to bug # 18539
> https://dev.openwrt.org/ticket/18539#comment:4
> The deadlock appears that when the adapter is in AP mode and client
> negotiates into the HT modes.  I don't know if this effects the adapter
> used in client modes.  But without the patch the adapter is not usable in
> ap mode.  This adapter is integrated in the sunxi based bpi-r1 board.
> I'd be interested in conversations to get this adapter up to some level of
> 802.11n HT mode.
> 
> The below patch I'd like to submit for evaluation for inclusion.
> Cheers
>    Derek
> 
> 
> DEBUGing and patch done by sbrown
> Comment (by sbrown):
> 
>  I found that the problem only occurs at HT rates.
> 
>  After looking at some more wireshark output, the problem seems to be
>  that the aggregation sessions deadlock when a second one starts before
>  the first one completes. That would explain why it only occurs in HT
>  mode.
> 
>  The sequence on the air before the deadlock is:
> 
>  STA->AP block ack req
>  STA->AP ping req
>  AP->STA block ack resp
>  AP->STA ping resp
>  AP->STA block ack req
>  STA->AP block ack resp
> 
>  The sequence on the air after the deadlock is:
> 
>  AP->STA block ack req
>  STA->AP block ack req
>  AP->STA block ack resp
>  STA->AP block ack resp
>  STA->AP ping req
>  ...
>  STA->AP ping req (repeats)
> 
>  If I disable aggregation in the driver with the attached patch, the
>  problem goes away with a performance loss.
> 
>  {{{
>   diff -rupN a/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
> b/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
> --- a/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c    2015-04-03
> 07:10:19.343543253 -0400
> +++ b/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c    2015-04-03
> 07:11:51.323999358 -0400
> @@ -59,7 +59,9 @@ static int rtl92cu_init_sw_vars(struct i
>  {
>      struct rtl_priv *rtlpriv = rtl_priv(hw);
>      int err;
> -
> + /* disable aggregation until the deadlock is fixed */
> +        hw->flags &= ~IEEE80211_HW_AMPDU_AGGREGATION;
> +
>      rtlpriv->dm.dm_initialgain_enable = true;
>      rtlpriv->dm.dm_flag = 0;
>      rtlpriv->dm.disable_framebursting = false;
> 
>  }}}

> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel