Re: [3.2.y] Re: Brcmsmac driver woes, possible regression?

["Arend van Spriel" <arend@broadcom.com>]

On 06/11/2012 05:15 AM, Jonathan Nieder wrote:

Decided to lookup this message and reply. Noticed it, but forgot to
follow up.

> Hi Arend et al,
> 
> Quick puzzle for you.  You like puzzles, right? ;-)

>From time to time, I do. When I get enough sleep ;-)

> As discussed at [1], Camaleón has been experiencing unwanted random
> wireless reconnects with various 3.2.y kernels up to and including
> 3.2.19:
> 
> Camaleón wrote[3]:
> 
>>      What I get is the Network Manager window requesting for the
>> password confirm, randomly. If I delay the password confirmation, the
>> wireless connection drops.
> 
> Newer kernels seemed to work better than old, so I asked her to apply
> the following patches agains the 3.2.y tree (the exact patches used
> are at [2]):
> 
>   6b1a89afbf97 brcm80211: smac: drop "40MHz intolerant" flag from HT
>                capability info
>   c261bdf8acad brcm80211: smac: indicate severe problems to Mac80211
>   0bf1f883fd0a brcm80211: smac: removed MPC related code
>   4412953061de brcm80211: smac: removed MPC related variables
>   28237002e726 brcm80211: smac: removed down-on-watchdog MPC functionality
>   43ac09722f8e brcm80211: smac: removed down-on-rf-kill functionality
>   a8bc4917ed6b brcm80211: smac: bugfix for tx mute in brcms_b_init()
>   c6c44893c864 brcm80211: smac: fixed inconsistency in transmit mute
>   2646c46d5679 brcm80211: smac: modified Mac80211 callback interface
>   dc460127898c brcm80211: smac: mute transmit on ops_start
>   1525662ac280 brcm80211: smac: changed check to confirm STA only support
>   b7eec4233c34 brcm80211: smac: replace own access category definitions with
>                mac80211 enum
>   e9ca530a7b18 brcm80211: smac: don't modify sta parameters when adding sta
>   8906c43cb160 brcm80211: smac: fix channel frequency
>   02a588a2e3b9 brcm80211: smac: combine promiscuous mode functionality
>   be667669ec01 brcm80211: smac: added support for mac80211 filter flags
>  [d3f311349add brcm80211: fix usage of set tx power] --- unrelated, my mistake
>   aa1f2f0a3218 brcm80211: smac: precendence bug in wlc_phy_attach()
>   1570e53c14ff brcm80211: smac: fix unintended fallthru in
>                wlc_phy_radio_init_2057()
>   137dabed34a1 brcm80211: smac: remove smatch warnings from brcmsmac code
>   2b0a53d51b5f brcm80211: smac: only print block-ack timeout message at
>                trace level
>   6b8da423315b brcm80211: smac: do not use US as fallback regulatory hint
>   94a2ca311cf4 brcm80211: smac: only provide valid regulatory hint
> 
> The result was very nice --- the random reconnects went away.

If I remember correctly the random reconnects were caused by mac80211
flush callback.

> Here comes the puzzle --- which of those patches are responsible for
> the improvement?

My hunch based on what I found so far is that the patches mentioning the
word 'mute' could be key here.

> If it is not too invasive, we would like to test the responsible patch
> separately and submit it for inclusion in stable trees, hence the
> question.  Incidentally, if any unrelated patches also seem like good
> stable candidates, that would be interesting to hear, too.  (In other
> words, a brief description of the symptoms addressed by _any_ of the
> listed patches would be welcome.)

I really need to dive into the patches individually so it may take some
time.

Gr. AvS